第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
Procedure
Enter the
du
command to estimate the size of uncompressed directories containing Satellite database and configuration files:# du -sh /var/lib/mongodb /var/opt/rh/rh-postgresql12/lib/pgsql/data /var/lib/pulp 480G /var/lib/mongodb 100G /var/opt/rh/rh-postgresql12/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
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 type Directory Ratio Example results MongoDB database files
/var/lib/mongodb
85 - 90 %
480 GB
60 GB PostgreSQL database files
/var/opt/rh/rh-postgresql12/lib/pgsql/data
80 - 85%
100 GB
20 GB Pulp RPM files
/var/lib/pulp
(not compressed)
100 GB
Configuration files
/var/lib/qpidd
/var/lib/tftpboot
/etc
/root/ssl-build
/var/www/html/pub
/opt/puppetlabs
85%
942 MB
141 MB In this example, the compressed backup data occupies 180 GB in total.
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.