Standard backup best practices apply when creating your OpenStack backup policy. For example, how often to back up your data is closely related to how quickly you need to recover from data loss.
![[Note]](../common/images/admon/note.png) | Note |
|---|---|
If you cannot have any data loss at all, you should also focus on a highly available deployment. The OpenStack High Availability Guide offers suggestions for elimination of a single point of failure that could cause system downtime. While it is not a completely prescriptive document, it offers methods and techniques for avoiding downtime and data loss. |
Other backup considerations include:
Just as important as a backup policy is a recovery policy (or at least recovery testing).
While OpenStack is composed of many components and moving parts, backing up the critical data is quite simple.
The example OpenStack architecture designates the cloud controller as the MySQL server. This MySQL server hosts the databases for nova, glance, cinder, and keystone. With all of these databases in one place, it's very easy to create a database backup:
1 | <a id="d6e6208" class="indexterm"># mysqldump --opt --all-databases > openstack.sql</a> |
If you only want to backup a single database, you can instead run:
1 | <a id="d6e6208" class="indexterm"># mysqldump --opt nova > nova.sql</a> |
where nova is the database you want to back up.
1 2 3 4 5 6 7 | <a id="d6e6208" class="indexterm">#!/bin/bashbackup_dir="/var/lib/backups/mysql"filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"# Dump the entire MySQL database/usr/bin/mysqldump --opt --all-databases | gzip > $filename# Delete backups older than 7 daysfind $backup_dir -ctime +7 -type f -delete</a> |
This script dumps the entire MySQL database and deletes any backups older than seven days.
This section discusses which files and directories should be backed up regularly, organized by service.
The /etc/nova directory on both the cloud
controller and compute nodes should be regularly backed up.
/etc/glance and /var/log/glance follow
the same rules as their nova counterparts.
# rsync -az --progress /var/lib/glance/images \ backup-server:/var/lib/glance/images/
/etc/swift is very important to have backed up. This
directory contains the swift configuration files as well as the ring
files and ring builder files, which if lost,
render the data on your cluster inaccessible. A best practice is to copy
the builder files to all storage nodes along with the ring files.
Multiple backup copies are spread throughout your storage
cluster.
Recovering backups is a fairly simple process. To begin, first
ensure that the service you are recovering is not running. For example, to
do a full recovery of nova on the cloud controller,
first stop all nova services:
1 2 3 4 5 6 | <a id="d6e6300" class="indexterm"># stop nova-api# stop nova-cert# stop nova-consoleauth# stop nova-novncproxy# stop nova-objectstore# stop nova-scheduler</a> |
Now you can import a previously backed-up database:
1 | <a id="d6e6300" class="indexterm"># mysql nova < nova.sql</a> |
You can also restore backed-up nova directories:
1 2 | <a id="d6e6300" class="indexterm"># mv /etc/nova{,.orig}# cp -a /path/to/backup/nova /etc/</a> |
Once the files are restored, start everything back up:
1 2 3 4 5 6 | <a id="d6e6300" class="indexterm"># start mysql# for i in nova-api nova-cert nova-consoleauth nova-novncproxynova-objectstore nova-scheduler> do> start $i> done</a> |
Other services follow the same process, with their respective directories and databases.
Backup and subsequent recovery is one of the first tasks system administrators learn. However, each system has different items that need attention. By taking care of your database, image service, and appropriate file system locations, you can be assured that you can handle any event requiring recovery.
