Backup and Restore
This chapter contains information on the files you need to back up.
With the mgradm backup tool you create Uyuni backups. Information about restoring from your backups in the case of a system failure completes this chapter.
Because Uyuni relies on a database as well as the installed program and configurations, it is important to back up all components of your installation. Back up your Uyuni installation regularly to prevent data loss and enable quick recovery.
|
Regardless of the backup method you use, you must have available at least three times the amount of space your current installation uses. Running out of space can result in backups failing, so check this often. |
|
|
1. Back up Uyuni
The most comprehensive method for backing up your Uyuni installation is to use mgradm backup create command.
This can save you time in administering your backup, and can be faster to reinstall and re-synchronize in the case of failure.
However, this method requires significant disk space and could take a long time to perform the backup.
mgradm backup create command performs backup to a directory.
This directory can be both local or mounted remote storage.
mgradm backup create command allows various customizations of the content of the backup.
For all available options, see mgradm backup create --help.
1.1. Full Backup of Uyuni
A full backup of the Uyuni consists of backing up the following components:
-
Uyuni volumes
-
database volumes
-
podman network configuration
-
podman secrets
-
Uyuni systemd services
-
Uyuni container images
|
The Uyuni service is automatically stopped for the time it takes to create a full backup. The downtime can be significant. After backup is done, service is automatically restarted. |
mgradm backup create-
On the container host, as root, create backup with:
mgradm backup create $pathReplace
$pathby the path to the backup location.
1.2. Partial Backup of Uyuni
mgradm backup create tool allows creating partial backups.
It is possible to skip individual or all volumes, skip database backup and images.
Particularly when database backup is skipped, backup is created without stopping Uyuni services and can act as a one phase in two phase backup procedure.
|
Partial backup cannot guarantee backup/restore consistency. |
-
On the container host, as root, create backup with:
mgradm backup create --skipdatabase $pathReplace
$pathby the path to the backup location.
-
On the container host, as root, create backup with:
mgradm backup create --skipvolumes $volumes $pathReplace
$pathby the path to the backup location.Replace
$volumesby the name of the volume name to be included in the backup, or by a comma separated list of volumes to be included.Use
allto skip all volumes, except database volumes.
1.3. Backing up extra volumes
mgradm backup command uses internal list of Uyuni volumes.
If additional volumes were configured during the installation, or additional volumes should be added to the backup, they need to be specified using --extravolumes $volumes.
-
On the container host, as root, create backup with:
mgradm backup create --extravolumes $volume $pathReplace
$pathby the path to the backup location.Replace
$volumesby the name of the volume name to be included in the backup. or by a comma separated list of volumes to be included.
1.4. Perform a Manual Database Backup
-
Allocate permanent storage space for your backup.
-
At the command prompt of the Uyuni container host, as root, use:
mgradm backup create --skipvolumes all --skipconfig --skipimages $path
2. Restore Uyuni from the Existing Backup
Restoring Uyuni from the existing backup will enumerate backup for volumes, images and configuration to restore. Unlike in backup create scenario, restore operation is not using an internal volume list, but automatically detect every volume or image present in the backup.
After the list of items to restore is gathered, presence and integrity check is performed. Presence check ensures backup restore will not accidentally overwrite existing volumes, image or configurations. Integrity check is done by computing backup items checksums.
After both checks are successful, actual backup restore is performed.
|
Uyuni services are not automatically started after backup restore is finished. |
-
On the container host, as root, re-deploy the Uyuni Server with:
mgradm stop mgradm backup restore $path mgradm startReplace
$pathby the path to the backup location.
Verification of the backup can be a time-consuming operation. If backup integrity is ensured by other means, verification can be skipped by using --skipverify option.
If for some reason it is needed to skip restoring a volume present in the backup, --skipvolumes $volumes option can be used.
2.1. Recommended Steps after Restoring a Backup
-
Re-synchronize your Uyuni repositories using either the Uyuni Web UI, or with the
mgr-synctool at the command prompt in the container. You can choose to re-register your product, or skip the registration and SSL certificate generation sections. -
On the container host, check whether you need to restore
/var/lib/containers/storage/volumes/var-spacewalk/_data/packages/. If/var/lib/containers/storage/volumes/var-spacewalk/_data/packages/was not in your backup, you need to restore it. If the source repository is available, you can restore`/var/lib/containers/storage/volumes/var-spacewalk/_data/packages/with a complete channel synchronization:mgrctl exec -ti -- mgr-sync refresh --refresh-channels -
Schedule the re-creation of search indexes next time the
rhn-searchservice is started. This command produces only debug messages, it does not produce error messages. On the container host, enter:mgrctl exec -ti -- rhn-search cleanindex