Backup and Restore

This chapter contains information on the files you need to back up, and introduces the mgradm backup tool to create Uyuni backups and information about restoring from your backups in the case of a system failure.

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.

smdba backup tool is deprecated in Uyuni.

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 during creation of a full backup.

Procedure: Creating Full Backup with mgradm backup create

On the container host, as root, create backup with:
```
mgradm backup create $path
```
Replace $path by 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.

Procedure: Creating Partial Backup by Skipping Database Backup

On the container host, as root, create backup with:
```
mgradm backup create --skipdatabase $path
```
Replace $path by the path to the backup location.

Procedure: Creating Partial Backup by Skipping a Volume.

On the container host, as root, create backup with:
```
mgradm backup create --skipvolumes $volumes $path
```
Replace $path by the path to the backup location.

Replace $volumes by the name of the volume name to be included in the backup, or by a comma separated list of volumes to be included.

Use all to 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.

Procedure: Creating Backup with Additional Custom Volume

On the container host, as root, create backup with:
```
mgradm backup create --extravolumes $volume $path
```
Replace $path by the path to the backup location.

Replace $volumes by 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

Procedure: Performing 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.

Procedure: Restoring from an Existing Backup

On the container host, as root, re-deploy the Uyuni Server with:
```
mgradm backup restore $path
mgradm start
```
Replace $path by 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

Procedure: Recommended Steps after Uyuni Restore

Re-synchronize your Uyuni repositories using either the Uyuni Web UI, or with the mgr-sync tool 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-search service is started. This command produces only debug messages, it does not produce error messages. In the container, enter:
```
rhn-search cleanindex
```