Backup and Restore

This chapter contains information on the files you need to back up. With the built-in backup and restore solution (mgradm backup) 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. Disable old method with smdba

Skip this section if you installed Uyuni 2025.10 from scratch.

With the advent of the built-in solution, the old method with the smdba backup tool is deprecated. If you migrated from an old system with smdba to the new solution, you must disable the old funtionality and remove the old backup archives.

Either disable smdba before migrating (recommended) or later on the migrated Uyuni 2025.10 system.

Procedure: Disabling old method with installed smdba before migration

This procedure only works when smdba is still installed.

  1. On the command line of the container host, as root, execute:

    mgrctl exec -- smdba backup-hot --enable=off

This will change archive_command in /var/lib/pgsql/data/postgresql.conf as follows:

archive_command = '/bin/true'

Now your old system is ready to be migrated to Uyuni 2025.10.

Procedure: Disabling old method on Uyuni 2025.10 after migration

Use this procedure after migration, when smdba is no longer available.

  1. On the container host, as root, edit /var/lib/containers/storage/volumes/var-pgsql/_data/postgresql.conf and set these options:

    archive_mode = off
archive_command = '/bin/true'

  2. Restart the container:

    mgradm restart

2. 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.

2.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.
Procedure: Creating full backup with mgradm backup create

  1. On the container host, as root, create backup with:

    mgradm backup create $path

    Replace $path by the path to the backup location.

2.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 backups are only considering a part of the data, and do not take potential dependencies with other parts which may not have been backed up in consideration. Therefore they cannot guarantee backup/restore consistency.
Procedure: Creating partial backup by skipping database backup

  1. 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

  1. 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 excluded from the backup, or by a comma separated list of volumes to be excluded.

    Use all to skip all volumes, except database volumes.

2.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

  1. 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.

2.4. Perform a manual database backup

Procedure: Performing a manual database backup

  1. Allocate permanent storage space for your backup.

  2. At the command prompt of the Uyuni container host, as root, use:

    mgradm backup create --skipvolumes all --skipconfig --skipimages $path

3. 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

  1. On the container host, as root, re-deploy the Uyuni Server with:

    mgradm stop
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.

3.1. Recommended steps after restoring a backup

Procedure: Recommended steps after Uyuni restore

  1. 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.

  2. 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 [path]``/var/lib/containers/storage/volumes/var-spacewalk/_data/packages/`u with a complete channel synchronization:

    mgrctl exec -ti -- mgr-sync refresh --refresh-channels

  3. 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.

    On the container host, enter:

    mgrctl exec -ti -- rhn-search cleanindex