REDHAT ADMIN: Backup and Restore

1. Backups
2. Restore from Backup
3. Automated Backups

This chapter outlines the methods to back up, verify, and restore a Satellite system.

Backups should be conducted either nightly or weekly, depending on the amount of data being stored, and how much data you could tolerate losing in the case of a system outage.

It is recommended that database backups are performed during a scheduled maintenance outage for the RHN Satellite, as all services will become unusable for website and client connections during the backup.

1. Backups

Backing up the Embedded Database

Stop the RHN Satellite server using the stop command:
```
rhn-satellite stop
```
Switch to the Oracle user, and create the backup using the db-control utility:
```
su - oracle
db-control backup [directory]
```
Replace directory with the absolute path to the location where you want to store your database backup. The process will take several minutes.
Switch back to the root user, and start the Satellite:
```
exit
rhn-satellite start
```
Switch to the Oracle user, and use the examine option of db-control to check the backup time stamp and to determine if there are any missing files:
```
su - oracle
db-control examine [directory]
```
You can also use the verify option of db-control to conduct a thorough review, which includes checking the md5sum of each of the files in the backup:
```
db-control verify [directory]
```
If the verification is successful, the contents of directory are safe to be used to restore the database.

Backing up System Files

In addition to the database, a number of system files and directories should also be backed up. The files and directories that should be backed up are:

/etc/sysconfig/rhn/
/etc/rhn/
/etc/sudoers
/etc/tnsnames.ora
/var/www/html/pub/
/var/satellite/redhat/[0-9]*/ (This is the location for any custom RPMs)
/root/.gnupg/
/root/ssl-build/
/etc/dhcpd.conf
/etc/httpd/
/tftpboot/
/var/lib/cobbler/
/var/lib/nocpulse/
/var/lib/rhn/kickstarts/
/var/www/cobbler/

If possible, back up /var/satellite/ as well. This is a duplicate of the Red Hat RPM repository, and it will save a large download when recovering from a failure. It can be regenerated with the satellite-sync tool. If you are using a disconnected satellite, /var/satellite/ must be backed up in order to be able to recover from failure.

Backing up only the files and directories listed above would require reinstalling the RHN Satellite Server ISO RPMs and re-registering the satellite in order to recover from a failure. In addition, Red Hat packages would need to be resynchronized using the satellite-sync tool, and the /root/ssl-build/rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm package would need to be installed. Alternatively, you could reinstall the RHN Satellite without re-registering it. This can be achieved by canceling or skipping the Red Hat Network registration and SSL certificate generation sections.

The most comprehensive backup method is to back up the entire machine. This method saves time in downloading and re-installing, but also requires additional storage and time to perform the backup.

Restore from Backup

Red Hat Network database control is used to restore the embedded database from a backup.

Restoring the Embedded Database from Backup

Stop the RHN Satellite server using the stop command:
```
rhn-satellite stop
```
Switch to the Oracle user, and restore the backup using the db-control utility:
```
su - oracle
db-control restore [directory]
```
Replace directory with the absolute path to the location that contains the backup. This process will verify the contents of the backup before restoring the database. The process will take several minutes.
Switch back to the root user, and start the Satellite:
```
exit
rhn-satellite start
```
Regardless of whether you are backing up an external or embedded database, when the satellite is restored from a backup, the following command should be run to schedule the recreation of search indexes the next time the rhn-search service is started:
```
/etc/init.d/rhn-search cleanindex
```

Automated Backups

Backup tasks can be automated so that they occur in non-peak times, such as the late evening or early morning. This also ensures they are performed regularly, and are not forgotten. The most effective way to automate backups is using cron.

Automating Backups

Create a new file called backup-db.sh containing the following script. This script will stop the satellite, perform a database backup, and restart the satellite:

#!/bin/bash
{
/usr/sbin/rhn-satellite stop
su - oracle -c'
d=db-backup-$(date "+%F");
mkdir -p /tmp/$d;
db-control backup /tmp/$d
';
/usr/sbin/rhn-satellite start
} &> /dev/null

Create a new file called move-files.sh containing the following script. This script will usersync to move the backup files to a directory to be stored:
```
#!/bin/bash
rsync -avz /tmp/db-backup-$(date "+%F") [destination] &> /dev/null
```
Replace [destination] with the path to the backup directory.

Alternatively, the following script uses scp to achieve the same goal:
```
#!/bin/bash
scp -r /tmp/db-backup-$(date "+%F") [destination] &> /dev/null
```
Switch to the root user, and open the crontab in a text editor:
```
cront
```
In the crontab, use the first five fields (minute, hour, day, month, and weekday) to schedule the backup scripts to run:
```
0 3 * * * backup-db.sh
0 6 * * * move-files.sh
```
This crontab entry will run the backup at 03:00, and transfer the backup files at 06:00. Other options can be included as needed. You can also include a clean up script to remove older backup directories and prevent the backup storage from filling up.
To save the crontab, simply exit from the text editor. The new cron rules will be put in to place immediately.

Heading

Backup and Restore