Menu Close

第8章 Backing Up Satellite Server and Capsule Server

You can back up your Satellite deployment to ensure the continuity of your Red Hat Satellite deployment and associated data in the event of a disaster. If your deployment uses custom configurations, you must consider how to handle these custom configurations when you plan your backup and disaster recovery policy.

To create a backup of your Satellite Server or Capsule Server and all associated data, use the satellite-maintain backup command. Backing up to a separate storage device on a separate system is highly recommended.

Satellite services are unavailable during the backup. Therefore, you must ensure that no other tasks are scheduled by other administrators. You can schedule a backup using cron. For more information, see the 「Example of a Weekly Full Backup Followed by Daily Incremental Backups」.

During offline or snapshot backups, the services are inactive and Satellite is in a maintenance mode. All the traffic from outside on port 443 is rejected by a firewall to ensure there are no modifications triggered.

A backup contains sensitive information from the /root/ssl-build directory. For example, it can contain hostnames, ssh keys, request files and SSL certificates. You must encrypt or move the backup to a secure location to minimize the risk of damage or unauthorized access to the hosts.

Conventional Backup Methods

You can also use conventional backup methods. For more information, see System Backup and Recovery in the Red Hat Enterprise Linux 7 System Administrator’s Guide.


If you plan to use the satellite-maintain backup command to create a backup, do not stop the satellite-maintain services.

  • When creating a snapshot or conventional backup, you must stop all services as follows:

    # satellite-maintain service stop
  • Start the services after creating a snapshot or conventional backup:

    # satellite-maintain service start

8.1. Estimating the Size of a Backup

The full backup creates uncompressed archives of MongoDB, PostgreSQL and Pulp database files, and Satellite configuration files. Compression occurs after the archives are created to decrease the time when Satellite services are unavailable.

A full backup requires space to store the following data:

  • Uncompressed Satellite database and configuration files
  • Compressed Satellite database and configuration files
  • An extra 20% of the total estimated space to ensure a reliable backup


  1. Enter the du command to estimate the size of uncompressed directories containing Satellite database and configuration files:

    # du -sh /var/lib/mongodb /var/lib/pgsql/data /var/lib/pulp
    480G	/var/lib/mongodb
    100G    /var/lib/pgsql/data
    100G	/var/lib/pulp
    # du -csh /var/lib/qpidd /var/lib/tftpboot /etc /root/ssl-build \
    /var/www/html/pub /opt/puppetlabs
    886M    /var/lib/qpidd
    16M     /var/lib/tftpboot
    37M	/etc
    900K	/root/ssl-build
    100K	/var/www/html/pub
    2M	/opt/puppetlabs
    942M   total
  2. Calculate how much space is required to store the compressed data.

    The following table describes the compression ratio of all data items included in the backup:

    表8.1 Backup Data Compression Ratio

    Data typeDirectoryRatioExample results

    MongoDB database files


    85 - 90 %

    480 GB → 60 GB

    PostgreSQL database files


    80 - 85%

    100 GB → 20 GB

    Pulp RPM files


    (not compressed)

    100 GB

    Configuration files



    942 MB → 141 MB

    In this example, the compressed backup data occupies 180 GB in total.

  3. To calculate the amount of available space you require to store a backup, calculate the sum of the estimated values of compressed and uncompressed backup data, and add an extra 20% to ensure a reliable backup.

    This example requires 681 GB plus 180 GB for the uncompressed and compressed backup data, 861 GB in total. With 172 GB of extra space, 1033 GB must be allocated for the backup location.