Red Hat Training

A Red Hat training course is available for Red Hat Virtualization

Chapter 6. Backing up and Restoring a RHEL-Based Self-Hosted Environment

The nature of the self-hosted engine, and the relationship between the self-hosted engine nodes and the Manager virtual machine, means that backing up and restoring a self-hosted engine environment requires additional considerations to that of a standard Red Hat Virtualization environment. In particular, the self-hosted engine nodes remain in the environment at the time of backup, which can result in a failure to synchronize the new node and Manager virtual machine after the environment has been restored.
To address this, Red Hat recommends that one of the nodes be placed into maintenance mode prior to backup, thereby freeing it from a virtual load. This failover host can then be used to deploy the new self-hosted engine.
If a self-hosted engine node is carrying a virtual load at the time of backup, then a host with any of the matching identifiers - IP address, FQDN, or name - cannot be used to deploy a restored self-hosted engine. Conflicts in the database will prevent the host from synchronizing with the restored Manager virtual machine. The failover host, however, can be removed from the restored Manager virtual machine prior to synchronization.

Note

A failover host at the time of backup is not strictly necessary if a new host is used to deploy the self-hosted engine. The new host must have a unique IP address, FQDN, and name so that it does not conflict with any of the hosts present in the database backup.

Procedure 6.1. Workflow for Backing Up the Self-Hosted Engine Environment

This procedure provides an example of the workflow for backing up a self-hosted engine using a failover host. This host can then be used later to deploy the restored self-hosted engine environment. For more information on backing up the self-hosted engine, see Section 6.1, “Backing up the Self-Hosted Engine Manager Virtual Machine”.
  1. The Manager virtual machine is running on Host 2 and the six regular virtual machines in the environment are balanced across the three hosts.
    Place Host 1 into maintenance mode. This will migrate the virtual machines on Host 1 to the other hosts, freeing it of any virtual load and enabling it to be used as a failover host for the backup.
  2. Host 1 is in maintenance mode. The two virtual machines it previously hosted have been migrated to Host 3.
    Use engine-backup to create backups of the environment. After the backup has been taken, Host 1 can be activated again to host virtual machines, including the Manager virtual machine.

Procedure 6.2. Workflow for Restoring the Self-Hosted Engine Environment

This procedure provides an example of the workflow for restoring the self-hosted engine environment from a backup. The failover host deploys the new Manager virtual machine, which then restores the backup. Directly after the backup has been restored, the failover host is still present in the Red Hat Virtualization Manager because it was in the environment when the backup was created. Removing the old failover host from the Manager enables the new host to synchronize with the Manager virtual machine and finalize deployment. For more information on restoring the self-hosted engine, see Section 6.2, “Restoring the Self-Hosted Engine Environment”.
  1. Host 1 has been used to deploy a new self-hosted engine and has restored the backup taken in the previous example procedure. Deploying the restored environment involves additional steps to that of a regular self-hosted engine deployment:
    • After Red Hat Virtualization Manager has been installed on the Manager virtual machine, but before engine-setup is first run, restore the backup using the engine-backup tool.
    • After engine-setup has configured and restored the Manager, log in to the Administration Portal and remove Host 1, which will be present from the backup. If old Host 1 is not removed, and is still present in the Manager when finalizing deployment on new Host 1, the Manager virtual machine will not be able to synchronize with new Host 1 and the deployment will fail.
    After Host 1 and the Manager virtual machine have synchronized and the deployment has been finalized, the environment can be considered operational on a basic level. With only one self-hosted engine node, the Manager virtual machine is not highly available. However, if necessary, high-priority virtual machines can be started on Host 1.
    Any standard RHEL-based hosts - hosts that are present in the environment but are not self-hosted engine nodes - that are operational will become active, and the virtual machines that were active at the time of backup will now be running on these hosts and available in the Manager.
  2. Host 2 and Host 3 are not recoverable in their current state. These hosts need to be removed from the environment, and then added again to the environment using the hosted-engine deployment script. For more information on these actions, see Section 6.2.4, “Removing Non-Operational Hosts from a Restored Self-Hosted Engine Environment” and Chapter 7, Installing Additional Hosts to a Self-Hosted Environment.
    Host 2 and Host 3 have been re-deployed into the restored environment. The environment is now as it was in the first image, before the backup was taken, with the exception that the Manager virtual machine is hosted on Host 1.

6.1. Backing up the Self-Hosted Engine Manager Virtual Machine

Red Hat recommends backing up your self-hosted engine environment regularly. The supported backup method uses the engine-backup tool and can be performed without interrupting the ovirt-engine service. The engine-backup tool only allows you to back up the Red Hat Virtualization Manager virtual machine, but not the self-hosted engine node that runs the Manager virtual machine or other virtual machines hosted in the environment.

Procedure 6.3. Backing up the Original Red Hat Virtualization Manager

  1. Preparing the Failover Host

    A failover host, one of the self-hosted engine nodes in the environment, must be placed into maintenance mode so that it has no virtual load at the time of the backup. This host can then later be used to deploy the restored self-hosted engine environment. Any of the self-hosted engine nodes can be used as the failover host for this backup scenario, however the restore process is more straightforward if Host 1 is used. The default name for the Host 1 host is hosted_engine_1; this was set when the hosted-engine deployment script was initially run.
    1. Log in to one of the self-hosted engine nodes.
    2. Confirm that the hosted_engine_1 host is Host 1: 
       # hosted-engine --vm-status
    3. Log in to the Administration Portal.
    4. Click the Hosts tab.
    5. Select the hosted_engine_1 host in the results list, and click Maintenance.
    6. Click Ok.
    Depending on the virtual load of the host, it may take some time for all the virtual machines to be migrated. Proceed to the next step after the host status has changed to Maintenance.

  2. Creating a Backup of the Manager

    On the Manager virtual machine, back up the configuration settings and database content, replacing [EngineBackupFile] with the file name for the backup file, and [LogFILE] with the file name for the backup log. 
    # engine-backup --mode=backup --file=[EngineBackupFile] --log=[LogFILE]

  3. Backing up the Files to an External Server

    Back up the files to an external server. In the following example, [Storage.example.com] is the fully qualified domain name of a network storage server that will store the backup until it is needed, and /backup/ is any designated folder or path. The backup files must be accessible to restore the configuration settings and database content. 
    # scp -p [EngineBackupFiles] [Storage.example.com:/backup/EngineBackupFiles]

  4. Activating the Failover Host

    Bring the hosted_engine_1 host out of maintenance mode.
    1. Log in to the Administration Portal.
    2. Click the Hosts tab.
    3. Select hosted_engine_1 from the results list.
    4. Click Activate.
You have backed up the configuration settings and database content of the Red Hat Virtualization Manager virtual machine.