8.5.11 Backing up Exadata Database Servers Before Planned Maintenance

Oracle recommends making a backup of the Exadata database servers before making any changes when updating to a next release.

This means running the update utility in backup-only mode before making any other (manual) changes to make the prerequisite / dependency check pass. The backup-only action backs up the active root and /boot file system only and is sufficient for rolling back (failed) updates.

Note:

The update utility’s built-in backup (dbserver_backup.sh) is insufficient for recovering from non-booting system failures. It is recommend having additional (validated) backup/restore procedures in place to recover the entire database server from failures such as double disk failures.

For regular and virtualized Exadata database servers (domU), when the active system image is running from a file system on /dev/mapper/VGExaDb-LVDbSys1, the backup is made onto /dev/mapper/VGExaDb-LVDbSys2 (and vice versa). For Exadata database servers running dom0 with /dev/mapper/VGExaDb-LVDbSys2 as the active image, the backup goes to /dev/mapper/VGExaDb-LVDbSys3 (and vice versa).

This means that upon rollback of an update the active system image for regular database servers and domU will become /dev/mapper/VGExaDb-LVDbSys2, and for dom0 will become /dev/mapper/VGExaDb-LVDbSys3.

The process of backing up an active system partition requires the default LVM scheme for the Sys* LVM’s and both LVM’s to be the same size. This is because it is impossible to back up a larger LVM partition to a smaller LVM partition. Resizing LVM VGExaDb-LVDbSys1 partition is allowed as long as VGExaDb-LVDbSys2 is resized to the same size.

While the backup is running, an LVM snapshot takes care of a consistent view of the file system. This LVM snapshot is maintained by the backup script and will always claim 1G of free VG space in VGExaDb.

Space for the snapshot is guaranteed by Oracle by using a placeholder LVM called /dev/VGExaDb/LVDoNotRemoveOrUse. When the backup script runs, it removes this placeholder, making sure there is always 1G of free space available for a snapshot. After the backup is completed, the snapshot is removed and the /dev/VGExaDb/LVDoNotRemoveOrUse LVM is re-created.

The time it takes to run the backup depends on how busy the system is and on the size and type of data that is backed up. For example, backing up millions of small files can take significantly longer than backing up a couple of larger files. For this reason it is recommended to make sure directories holding database .aud files are not found on the root file system. Note the following:

  • You can have only one backup. Running a new backup means overwriting the existing backup.

  • Re-running the update utility with the --backup flag (or in default updating mode) will overwrite existing backups.

  • All files in /boot and found on the active Sys LVM’s are backed up. Files in, for example, /u01, are not backed up.

Examples for “Backup Only”

The following example shows running “backup only” as root:

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --allow_active_network_mounts
  • --dbnodes specifies the list of database nodes to be updated.

  • --backup specifies the “backup only” action.

  • --repo specifies the location of the compressed ISO file containing the update repository. If you specify a compressed ISO file, the file path must be accessible on the node running the updating utility. Alternatively, you can provide a URL to a YUM repository.

  • --target_version specifies the target release for which the backup is run.

  • --allow_active_network_mounts ensures active network mounts remain active while performing the backup operation.

The following example shows a “backup only” action run as a non-root user:

[oracle@pmserver ]$ ./patchmgr --dbnodes ~/dbs_group -backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --log_dir auto --allow_active_network_mounts --smtp_from "sender@somedomain.com" --smtp_to "recipient@example.com"