ГЛАВА 14

Резервное копирование и восстановление

При создании вашей политики резервного копирования вашего OpenStack лучшей практикой будет стандартное резервное копирование. Например, проблема того, как часто вы должны делать резервные копии своих данных тесно связана с тем, как быстро вы должны восстановить утраченные данные.

Если вы совсем не должны иметь никаких потерь данных, вам, помимо резервного копирования, следует сосредоточиться на высокой доступности (High Availability).

Другие соображения по поводу резервного копирования включают в себя:

• Сколько резервных копий стоит хранить?
• Должны ли резервные копии храниться за пределами площадки?
• Как часто стоит проверять резервные копии?

Политика восстановления (или, по крайней мере тестирование восстановления) является не менее важной, чем политика резервного копирования.

Что подлежит резервному копированию

Поскольку OpenStack состоит из многих компонентов и перемещающихся частей, резервное копирование критически важных данных достаточно простое.

В этой главе описывается только как выполнять резервное копирование файлов конфигурации и баз данных, которые необходимы для различных компонентов OpenStack. В данном разделе не описывается, как выполнять резервное копирование объектов внутри систем хранения объектов или данных, содержащихся внутри систем блочного хранения. Как правило, эти области отдаются на откуп пользователю для самостоятельного резервного копирования.

Резервное копирование баз данных

Приводимый пример архитектуры OpenStack определяет контроллер облака в качестве сервера MySQL. Этот сервер MySQL содержит базы данных для Nova, Glance, Cinder и Keystone. Поскольку все эти базы данных находятся в одном месте, создание резервной копии базы данных очень простое:
# mysqldump --opt --all-databases >
        openstack.sql


Если вы хотите выполнить резервное копирование только одной базы данных, вы можете вместо приведенного выше примера выполнить нечто типа:
# mysqldump --opt nova > nova.sql

где nova является базой данных, подлежащей резервному копированию.

Вы легко можете автоматизировать процесс путем создания задания cron, которое ежедневно выполняет следующий сценарий:
#!/bin/bash
backup_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 days
find $backup_dir -ctime +7 -type f -delete


Приведенный сценарий выгружает всю базу данных MySQL и удаляет любые резервные копии старше 7 дней.

Резервное копирование файловой системы

В данном разделе обсуждается, какие файлы и каталоги должны подвергаться регулярному резервному копированию со стороны службы.

Compute

Каталог /etc/nova и в контроллере облака, и в вычислительных узлах должен обеспечиваться регулярным резервным копированием.

Если у вас существуют журналы, помещенные в централизованном месте, нет необходимости выполнять резервное копирование /var/log/nova.

/var/lib/nova является еще одним важным каталогом для резервного копирования. Исключением из этого правила является подкаталог /var/lib/nova/instances на вычислительных узлах. Этот подкаталог содержит KVM образы запущенных на исполнение экземпляров. Вам следует создавать резервную копию этого подкаталога только если у вас есть необходимость создавать резервные копии всех экземпляров. В большинстве случаев в этом нет необходимости, однако это может меняться от облака к облаку и ваших уровней служб. Также имейте в виду, что создание резервной копии запущенного экземпляра KVM может привести к тому, что он не сможет загружаться надлежащим образом, будучи восстановленным из резервной копии.

Каталог образов и доставка

Глава 13	Оглавление	Глава 15
Перевод: Copyright © 2014  . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru