JavaScript must be enabled to correctly display this content

Chapter 12 Backing up and Restoring Oracle VM Components

This chapter gives you the basic information required to back up and restore Oracle VM Manager, the database repository, and virtual machines.

Oracle does not recommend backing up Oracle VM Servers as no critical data is contained on them. Instead of backing up and recovering an Oracle VM Server, in the event of a failure, simply delete it from Oracle VM Manager, reinstall the Oracle VM Server software if required, and rediscover it.

For a more thorough discussion on backing up and restoring the various entities that comprise Oracle VM, see the Oracle VM 3: Backup and Recovery Best Practices Guide at:

http://www.oracle.com/technetwork/server-storage/vm/overview/index.html

12.1 Backing up and Restoring Oracle VM Manager

This section contains information about how to manually back up and restore Oracle VM Manager, including the database repository.

From a high level, the steps to manually backup Oracle VM Manager are as follows:

Make a copy of the Oracle VM Manager configuration file.

See Section 12.1.1, “Backing up the Oracle VM Manager Configuration File” for more information on backing up the Oracle VM Manager configuration file.
Back up the Oracle VM Manager database.

Note that the Oracle VM Manager database is backed up automatically every 24 hours using the MySQL Enterprise Backup utility, but it is also possible to perform a manual backup.

See Section 12.1.2, “Backing up the MySQL Database Repository” for more information on Oracle VM Manager MySQL database backup and restore facilities.

12.1.1 Backing up the Oracle VM Manager Configuration File

To back up Oracle VM Manager, you should make a copy of the Oracle VM Manager configuration file located at:

/u01/app/oracle/ovm-manager-3/.config

This configuration file contains database connection information, ports, and the Oracle VM Manager UUID. The following is an example of the configuration file structure:

DBTYPE=MySQL
DBHOST=localhost
SID=ovs
LSNR=46500
OVSSCHEMA=ovs
APEX=None
WLSADMIN=weblogic
OVSADMIN=admin
COREPORT=54321
UUID=uuid
BUILDID=x.x.x.xxx

The following table describes the properties and values in the configuration file:

Name	Description
`DBTYPE`	Database type. This is a legacy configuration property. The value is always `MySQL`.
`DBHOST`	Hostname of database server. This is a legacy configuration property. The value is always `localhost`.
`SID`	Oracle System ID (SID). The default value is `ovs`.
`LSNR`	Database listener port number. The default value is `49500`.
`OVSSCHEMA`	Oracle VM Manager database name. The default value is `ovs`.
`APEX`	This is a legacy configuration property. The default value is `None`.
`WLSADMIN`	Oracle WebLogic Server administrator username. The default value is `weblogic`.
`OVSADMIN`	Oracle VM Manager administrator username. The default value is `admin`.
`COREPORT`	Oracle VM Manager core port number. The default value is `54321`.
`UUID`	Oracle VM Manager universally unique identifier (UUID).
`BUILDID`	Oracle VM Manager version and build number.

12.1.2 Backing up the MySQL Database Repository

This section describes the Oracle VM Manager MySQL backup facility.

As of Oracle VM Manager Release 3.2.1, backups of the local MySQL database are performed automatically. Backups are stored within /u01/app/oracle/mysql/dbbackup by default, and are rotated regularly so that only the most recent backups are stored at any point in time. Backups make use of the MySQL Enterprise Backup utility. See http://www.mysql.com/products/enterprise/backup.html for more information on the MySQL Enterprise Backup utility.

The MySQL Enterprise Backup package is installed as a dependency during the installation of Oracle VM Manager. On Oracle Linux systems this is handled by installing meb-version_number.x86_64.rpm.

On x86 systems, backup configuration options are defined in /etc/sysconfig/ovmm on the Oracle VM Manager host.

To configure the default path used to store MySQL database backup files, locate the following line:

DBBACKUP=/u01/app/oracle/mysql/dbbackup

Note

This path can be changed to an alternate location if you need to cater to disk space requirements.

The default path for the mysqlbackup binary is specified in the following line:

DBBACKUP_CMD=/opt/mysql/meb-x.x/bin/mysqlbackup

Warning

This path is made explicit for the purposes of handling future updates to the MySQL Enterprise Backup package. It should not be changed.

Configuration options such as how frequently the automated database backup facility should run and how many backups should be kept through rotations, are stored within the database itself. These parameters can be set using either the Oracle VM Manager Web Interface or the Oracle VM Manager Command Line Interface. For more information on how to set these parameters, please refer to Prefenences section in the Oracle VM Manager Online Help and the setDbBackupConfig command in the Oracle VM Manager Command Line Interface User's Guide .

12.1.2.1 Contents of the Backup Directory

The MySQL database backup directory has the following naming convention: AutoFullBackup-MMDDYYYY_hhmmss.

The backup directory contains the following:

AutoBackup.log, which contains information about the events that took place during the backup process.
A copy of the MySQL configuration file.
datadir directory that contains the binary log for the database.
meta directory that contains files specific to the MySQL Enterprise Backup process.
MBI image file for the database that is backed up

12.1.2.2 Configuring Backup Interval and Rotation

You can set the frequency of MySQL database backups as well as the number of database backups that Oracle VM Manager retains. See the Preferences section in the Oracle VM Manager Online Help for more information.

12.1.2.3 Backing Up the MySQL Database Manually

It is possible to manually initiate a backup. This is usually done when performing an upgrade of Oracle VM Manager. While it is possible to invoke the mysqlbackup utility directly, it is recommended that you use the backup script at /u01/app/oracle/ovm-manager-3/ovm_tools/bin/BackupDatabase.

The following is an example of this script:

# /u01/app/oracle/ovm-manager-3/ovm_tools/bin/BackupDatabase -w
Enter your OVM Manager username: admin  
Enter your OVM Manager password: 

INFO:  Backup job starting with destination:
        /u01/app/oracle/mysql/dbbackup/ManualBackup-time_stamp

        Job Id   = 'Start Backup to: ManualBackup(ID) 
        Uri: https://localhost:7002/ovm/core/wsapi/rest/Job/ID'
        Job Name = 'Start Backup to: ManualBackup'

INFO:  Backup job finished

By default, the backup script stores the backup as a manual backup, to avoid the rotation that takes place for automatic backups.

The preceding example uses the -w command-line switch to force the backup script to wait until the backup job is complete. This option is useful if you need to capture potential error messages, but it also causes the script to wait until the job either completes or exits due to an error. If you do not use the -w command-line switch, you should check the status of the backup job within the Oracle VM Manager Web Interface or Oracle VM Manager Command Line Interface to determine whether or not the job completes successfully. You can get a full list of supported options for this command with the -h command-line switch.

Note

The backup script assumes that you are using a CA-signed SSL certificate within a production environment. Using a self-signed certificate is not recommended and may result in an error when you run the script. It is possible to override SSL verification by using the --insecure command-line parameter, however this may compromise the security of the operation and is not recommended. A better approach to resolving any SSL verification error, is to install an SSL certificate signed by a recognized CA, as described in Section 2.2.6, “Changing the Default SSL Certificate”.

For more information on using MySQL Enterprise Backup, see http://dev.mysql.com/doc/mysql-enterprise-backup/en.

12.1.3 Oracle VM Manager Backup and Restore Troubleshooting

If you are experiencing problems with Oracle VM Manager, do the following:

Perform a database restore. See Section 12.1.4, “Restoring Oracle VM Manager” for more information.

Provided that you have a good backup in your archive, you should be able to revert back to it. To check for a recent database backup, on the Oracle VM Manager host, run the following command:
```
ls -ltr /u01/app/oracle/mysql/dbbackup/
```
If a backup exists, you can proceed with the steps documented in Section 12.1.4, “Restoring Oracle VM Manager”.

Note

You can also refer to Doc ID 2405023.1 in the Oracle Support Knowledge Base for information about restoring the Oracle VM Manager database.

There is a check completed before each backup is run to determine if the database can be backed up. If the database consistency check fails, automatic backups are no longer generated. For more information, see Doc ID 2060953.1 in the Oracle Support Knowledge Base.
If you do not have a good backup of the database or if you have other database corruption issues, rebuild the database. See Section 12.1.5, “Restoring Oracle VM Manager If You Have No Database Backup”

Also, see Doc ID 2038168.1 in the Oracle Support Knowledge Base for additional information about regenerating the Oracle VM Manager database.

12.1.4 Restoring Oracle VM Manager

To restore Oracle VM Manager, and the Oracle VM Manager database schema from a backup, do the following:

First, if you need to reinstall or upgrade Oracle VM Manager, use the Oracle VM Manager installation media to perform an install or upgrade of the software on your server. See the Installation and Upgrade Guide.

You should perform the install using the runInstaller.sh --uuid uuid command and provide the UUID from the previous manager installation you created a backup from. The UUID can be found in the Oracle VM Manager configuration file.
Note

The Oracle VM Manager UUID is also persisted in the /etc/sysconfig/ovmm file on Oracle Linux, and in the /etc/opt/ovmm file on . If the system disk of the server on which you are installing or restoring Oracle VM Manager was not wiped entirely, the existing UUID is still present and will be detected when running the installer.
- The --uuid option on Oracle Linux overrides this existing UUID. Oracle Solaris users must use the shortened form of this option: -u.
- If no UUID is present in /etc/sysconfig/ovmm, the --uuid option adds the UUID to the file on Oracle Linux. On Oracle Solaris, the -u option adds the UUID to /etc/opt/ovmm if the UUID is not present in this file.
An example install command syntax for Oracle Linux is as shown in this example:
```
# ./runInstaller.sh --uuid 0004FB000000100002CB7F2DFFA8D8
```
When the Oracle VM Manager installer prompts for installation information, reuse the same usernames for the database schema, Oracle WebLogic Server and Oracle VM Manager administration user, as set out in the backup of the Oracle VM Manager configuration file.

If possible, you should reuse the same passwords that existed for Oracle VM Manager prior to reinstallation, to avoid problems restarting the Oracle VM Manager service after Oracle VM Manager has been restored from backup. If you intend to change these passwords, do so after you have completed the restore operation.

Should you use a new password during reinstallation, you are unable to start the Oracle VM Manager service after the database has been restored. To rectify this situation, you must manually reset the passwords for the ovs and appfw users in the MySQL database. This can be achieved using the mysqladmin tool.
After installation, reinstallation or upgrade, stop the Oracle VM Manager Command Line Interface, Oracle VM Manager, and the database before you restore the backup. On Linux:
```
# /sbin/service ovmcli stop
# /sbin/service ovmm stop
# /sbin/service ovmm_mysql stop 
```
To initiate the database restore, as the oracle user, use the RestoreDatabase command located in /u01/app/oracle/ovm-manager-3/ovm_tools/bin, for example:
```
# su - oracle
$ bash /u01/app/oracle/ovm-manager-3/ovm_tools/bin/RestoreDatabase.sh \
     ManualBackup-time_stamp_ID
```
The RestoreDatabase script expects the name of the directory for a particular backup directory as described in the Installation and Upgrade Guide. You do not need to specify the full path to the backup directory as this is already specified in the DBBACKUP variable.

The RestoreDatabase script prompts you to remove existing database directories and their contents so that the database restore operation can complete successfully. You must confirm that it is safe to delete this data before the script can proceed. If you opt not to delete this data, the script cannot continue until the data has been removed. It is recommended that you allow the script to perform this action rather than attempting to do this manually:
```
Before the database can be restored, 
  the following database directories/files must be deleted:
appfw ibdata1 ib_logfile0 ib_logfile1 mysql ovs performance_schema

Are you sure it is safe to delete these directories/files now? [y,n] y
Deleting directory /u01/app/oracle/mysql/data/appfw
Deleting directory /u01/app/oracle/mysql/data/ibdata1
Deleting directory /u01/app/oracle/mysql/data/ib_logfile0
Deleting directory /u01/app/oracle/mysql/data/ib_logfile1
Deleting directory /u01/app/oracle/mysql/data/mysql
Deleting directory /u01/app/oracle/mysql/data/ovs
Deleting directory /u01/app/oracle/mysql/data/performance_schema
INFO: Expanding the backup image...
INFO: Applying logs to the backup snapshot...
INFO: Restoring the backup...
INFO: Restoring OVM keystores and certificates
INFO: Success - Done!
INFO: Log of operations performed is available at:
 /u01/app/oracle/mysql/dbbackup/ManualBackup-time_stamp_ID/Restore.log


IMPORTANT:

      As 'root', please start the OVM Manager database and application using:
            service ovmm_mysql start; service ovmm start; service ovmcli start
        
```
Important

The RestoreDatabase script performs a version check to ensure that the database version matches the version of the database from which the backup was created. If there is a version mismatch, the script exits with a warning, as this action may render Oracle VM Manager unusable.

It is possible to override this version check by using the --skipversionchecks option when invoking the script. This option should be used with care as version mismatches may have undesirable consequences for Oracle VM Manager.

For example, database backups from an earlier 3.4.x release cannot be used in an Oracle VM Manager deployment at release 3.4.5 or later, due to database schema changes.
Restart the database and Oracle VM Manager, and the Oracle VM Manager Command Line Interface. On Oracle Linux:
```
# /sbin/service ovmm_mysql start
# /sbin/service ovmm start 
# /sbin/service ovmcli start 
```
Because the certificates required to authenticate various components, such as the Oracle VM Manager Web Interface and Oracle VM Manager Command Line Interface, are regenerated during the new installation and the mappings for these are overwritten by the database restore, it is necessary to reconfigure the certificates used to authenticate these components.

Run the following script to reconfigure the Oracle WebLogic Server:
```
# export MW_HOME=/u01/app/oracle/Middleware
# /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh setupWebLogic
```
For more information on the ovmkeytool.sh script, see Section 2.2.1, “Oracle VM Key Tool”.
If you moved Oracle VM Manager to a new host, you must generate a new SSL key as follows:
```
# /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh gensslkey
```
For more information on generating a new SSL key, see Section 2.2.5, “Generating a New SSL Key”.
Restart Oracle VM Manager and then run the client certificate configuration script, as follows:
```
# /sbin/service ovmm restart
# /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh /path/to/cacert
```
Where /path/to/cacert is the absolute path to the CA certificate. You must provide the path to the CA certificate if you used a CA other than the default Oracle VM Manager CA to sign the SSL certificate.

The script requires that Oracle VM Manager is running, and prompts you for the administrator username and password that should be used to access Oracle VM Manager. The script makes changes that may require Oracle VM Manager to be restarted:
```
# /sbin/service ovmm restart
```
Within Oracle VM Manager go to the Servers and VMs tab and perform a Refresh All on your existing server pools. Refer to the Oracle VM Manager Online Help for more information on these options.

12.1.5 Restoring Oracle VM Manager If You Have No Database Backup

Important

The instructions provided here should be used as a last resort. You really must ensure that your backup strategy is adequate and that the database backups are available on storage that is suitable for this purpose. Typically, these backups should be stored on some form of network attached storage, preferably with a RAID that provides some form of mirroring. To change the backup path to a suitable location, see Section 12.1.2, “Backing up the MySQL Database Repository”.

If you have reinstalled Oracle VM Manager from scratch, using the runInstaller.sh --uuid uuid command and have provided the UUID from the previous manager installation, but you do not have a database backup, a certain level of recovery is possible based on the information stored on the Oracle VM Servers and in your attached storage. It is important that you follow a set order of actions to ensure that the server pools that your Oracle VM Servers are members of are able to be properly recovered. These steps are outlined as follows:

Discover one Oracle VM Server from each server pool.
Discover the storage that contains the server pool file system. Present it to the newly discovered Oracle VM Server. Refresh the storage.
Refresh the file system or physical disks that contain the server pool file system.
Refresh the file systems or physical disks that contain the repositories used by server pool. If you get an error, when refreshing a physical disk, similar to the following:
```
OVMAPI_7281E Cannot perform operation on file system...
```
then take ownership of the repositories and try to perform the physical disk refresh again.
Present the repositories to the Oracle VM Server.
Refresh the repositories.
Discover the remaining Oracle VM Servers in the server pool.
Refresh all Oracle VM Servers in the server pool to discover the virtual machines.

12.1.6 Oracle WebLogic Server Backup and Restore

In general, it is not necessary to perform a separate backup of the Oracle WebLogic Server component used by Oracle VM Manager, however in the instance that you have created separate Oracle WebLogic Server users to facilitate a number of different login credentials that can be used to access Oracle VM Manager you may need to perform your own backup of the Oracle WebLogic Server LDAP directory used for authentication. This is particularly important if you intend to upgrade Oracle VM Manager, as there is a possibility that any user credentials that have been manually configured within Oracle WebLogic Server may be lost during an update process.

Full documentation describing the Oracle WebLogic Server LDAP backup process and how to configure Oracle WebLogic Server LDAP backups can be found at:

http://docs.oracle.com/middleware/1221/wls/START/failures.htm#START162

In the Oracle VM context, LDAP data for Oracle WebLogic Server is stored in:

/u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/data/ldap

Based on the information provided in the Oracle WebLogic Server documentation, you can perform a full backup of this directory on your own schedule, or you can rely on Oracle WebLogic Server's automated backups located in:

/u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/data/ldap/backup

If you choose to use the Oracle WebLogic Server backup service, you can change default backup parameters. See the Configure backups for embedded LDAP servers topic in the Oracle WebLogic Server online help.

12.2 Backing up Virtual Machines

There are a number of options you can use to take a back up of a virtual machine. This section discusses some of them and the pros and cons for each.

One of the main points that should be considered when backing up a virtual machine, is whether you can shut down the virtual machine during the back up. Backing up a running virtual machine allows the machine to be available for use, but does not allow for a back up that is consistent or easy to restore. Creating a back up of a running virtual machine is similar to taking a back up of a running database without putting the tablespaces in back up or read-only mode. The first couple of blocks you back up from a the virtual machine are likely to be out of sync with the last blocks of your back up. If and when you try to restore a back up taken from a running virtual machine, you may not be able to rebuild the machine due to disk errors.

You can install back up software in the virtual machine, for example Oracle Secure Backup. This allows you to safely back up a running virtual machine. The ease by which you can restore the virtual machine from the back up depends on the software used.

The following table discusses some virtual machine back up options, with some high level benefits and disadvantages of each method. This is not an exhaustive list of all the options that may be available.

Table 12.1 Virtual Machine Backup Options

Backup Option	Benefits	Disadvantages
Install back up software in the virtual machine and back up to an external source.	Virtual machine can be running. Fine grained control of files backed up.
Create a back up of the virtual machine from the storage repository (see Clone a Virtual Machine or Template section in the User Guide ).	Consistent virtual disk status.	Virtual machine must be stopped.
Create a cold clone of the (stopped) virtual machine (see the Clone a Virtual Machine or Template section in the User Guide, then back up the clone from the storage repository (see the Repositories Perspective section in the User Guide ).	Consistent virtual disk status.	Virtual machine must be stopped.
Create a hot clone of the (running) virtual machine (see the Clone a Virtual Machine or Template section in the User Guide, then back up the clone from the storage repository (see the Repositories Perspective section in the User Guide).	Virtual machine can be running.	Inconsistent virtual disk status. Virtual disks may need to be recovered using a disk repair utility. May cause data loss or corruption. Only available on OCFS2-based file systems (iSCSI or fibre channel-based storage). Should not be used for virtual machines running an Oracle Database (instead use the rman utility or similar).
Create a back up of the entire storage repository (see the Repositories Perspective section in the User Guide).	Back up all virtual machines at once. Consistent virtual disk status.	Virtual machines must be stopped.

The two recommended strategies for backing up a virtual machine are to:

Shut down the virtual machine and create a cold clone, then back up the clone files from the storage repository.
Shut down the virtual machine and back up the virtual machine files from the storage repository.

These two options create a safe back up, with the virtual disks in a stable and consistent state. To restore the virtual machine, import the virtual machine into the storage repository (see the Import Virtual Machine section of the Server Pools Folder in the User Guide).