Questo contenuto non è disponibile nella lingua selezionata.
Chapter 6. Backing up and Restoring a RHEL-Based Self-Hosted Environment
Note
Procedure 6.1. Workflow for Backing Up the Self-Hosted Engine Environment
- The Manager virtual machine is running on
Host 2and the six regular virtual machines in the environment are balanced across the three hosts.PlaceHost 1into maintenance mode. This will migrate the virtual machines onHost 1to the other hosts, freeing it of any virtual load and enabling it to be used as a failover host for the backup. Host 1is in maintenance mode. The two virtual machines it previously hosted have been migrated to Host 3.Useengine-backupto create backups of the environment. After the backup has been taken,Host 1can be activated again to host virtual machines, including the Manager virtual machine.
Procedure 6.2. Workflow for Restoring the Self-Hosted Engine Environment
Host 1has 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-setupis first run, restore the backup using theengine-backuptool. - After
engine-setuphas configured and restored the Manager, log in to the Administration Portal and removeHost 1, which will be present from the backup. If oldHost 1is not removed, and is still present in the Manager when finalizing deployment on newHost 1, the Manager virtual machine will not be able to synchronize with newHost 1and the deployment will fail.
AfterHost 1and 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 onHost 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.Host 2andHost 3are not recoverable in their current state. These hosts need to be removed from the environment, and then added again to the environment using thehosted-enginedeployment 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 2andHost 3have 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 onHost 1.
6.1. Backing up the Self-Hosted Engine Manager Virtual Machine Copia collegamentoCollegamento copiato negli appunti!
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.
Warning
engine-backup tool must be used for backup and restoration. If a third-party tool is used, it must back up the tar file produced by the engine-backup tool.
Procedure 6.3. Backing up the Original Red Hat Virtualization Manager
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 ifHost 1is used. The default name for theHost 1host ishosted_engine_1; this was set when thehosted-enginedeployment script was initially run.- Log in to one of the self-hosted engine nodes.
- Confirm that the
hosted_engine_1host isHost 1:hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Log in to the Administration Portal.
- Click the Hosts tab.
- Select the
hosted_engine_1host in the results list, and click. - Click .
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 toMaintenance.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]
# engine-backup --mode=backup --file=[EngineBackupFile] --log=[LogFILE]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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]
# scp -p [EngineBackupFiles] [Storage.example.com:/backup/EngineBackupFiles]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Activating the Failover Host
Bring thehosted_engine_1host out of maintenance mode.- Log in to the Administration Portal.
- Click the Hosts tab.
- Select
hosted_engine_1from the results list. - Click
.