Модуль 10. Резервное копирование ALD Pro

Введение 

Потеря данных — это страшный сон для владельца любого бизнеса, так как после такого события девять из десяти компаний обычно не выживают. Речь тут идет, конечно же, о потере клиентской базы или интеллектуальной собственности, но даже в менее критичных случаях ущерб может оказаться весьма значителен. Поэтому иногда шутят, что все системные администраторы делятся на три группы: тех, кто не делает бэкапы, кто делает и кто проверяет возможность восстановления системы из резервной копии.

Из этого модуля вы узнаете о том, как выполнять резервное копирование подсистем ALD Pro и в чем заключаются особенности их восстановления, связанные с хранением данных в распределенной базе каталога.

Резервное копирование дисков 

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

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

Если мы полностью выключим сервер и сделаем снимок виртуальной машины (или создадим копии всех его дисков), то у нас не возникнет проблем с запуском системы, см. рис. 328.
Если же мы попытаемся копировать файлы или блочное устройство во время работы системы, то данные могут оказаться несогласованными и система не заработает или какие-то изменения окажутся утеряны.

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

../_images/image3.png — рис. 328 Создание полного снимка виртуальной машины

Примечание

В случае выключения контроллера домена его клиенты автоматически переключатся на другие серверы, но если так делать постоянно, то лучше выделить так называемую скрытую реплику (англ. hidden replica), которая будет исключена из SRV-записей, чтобы клиенты не выбирали ее в качестве активного контроллера.

Для того чтобы обычный контроллер сделать скрытой репликой, нужно изменить статус командой ipa server-state $(hostname) --state=hidden. Чтобы вернуть контроллер в строй, нужно изменить статус на enabled. Текущее состояние домена покажет команда ipa config-show.

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

Потребность повторной инициализации вызвана тем, что при восстановлении контроллера домена из резервной копии соседние серверы, с которыми он связан соглашениями о репликации, не смогут отдать ему те изменения, которые были внесены в домен непосредственно с его участием. Очень подробно механизм репликации был рассмотрен в Модуль 8. Управление топологией в домене.

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

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

Чтобы переинициализировать контроллер, выполните следующие действия, см. рис. 329:

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

../_images/image51.png — рис. 329 Переинициализация контроллера домена

Из командной строки это можно сделать с помощью утилиты ipa-replica-manage:

admin@dc-2:~$ sudo ipa-replica-manage re-initialize --from dc-1.ald.company.lan

При восстановлении обычных подсистем (не контроллеров) из снимков нужно учитывать, что PXE и DHCP хранят свои настройки в каталоге, а с версии 2.4.0 все подсистемы будут хранить свое целевое состояние в каталоге.

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

Учитывая, что полное выключение сервера приводит к временному прерыванию в обслуживании клиентов, в многие системы реализуют функции резервного копирования, которые гарантируют целостность данных при снятии копий «на горячую». Например, вы можете сделать дамп базы PostgreSQL или каталога 389DS. Мы рассмотрим несколько скриптов резервного копирования контроллера домена и отдельных подсистем.

Контроллеры домена 

Для выполнения резервного копирования контроллера домена на этом сервере необходимо выполнить следующий скрипт:

#!/usr/bin/env bash
# Название директории для резервной копии формируется
# из текущей даты и находится в папке /tmp/backup
now=$(date +"%d-%m-%Y")
BACKUP_PATH=/tmp/backup/$now
# Создание временной директории для резервных копий
mkdir -p $BACKUP_PATH
# Создание резервной копии FreeIPA
ipa-backup
# Архивирование РК FreeIPA
tar -zcvf $BACKUP_PATH/ipa.tar.gz /var/lib/ipa/backup
# Очистка промежуточного бэкапа FreeIPA
rm -rf /var/lib/ipa/backup/*
# Остановка затрагиваемых бэкапом сервисов
systemctl stop apache2 celery celerybeat rabbitmq-server postgresql salt-minion salt-minion-standalone
# Архивирование БД PostgreSQL
tar -zcvf $BACKUP_PATH/postgresql.tar.gz /var/lib/postgresql/
# Архивирование RabbitMQ
tar -zcvf $BACKUP_PATH/rabbitmq.tar.gz /var/lib/rabbitmq/mnesia/
# Архивирование директории ipa-client
tar -zcvf $BACKUP_PATH/ipa-client.tar.gz /var/lib/ipa-client/
# Архивирование логов
tar -zcvf $BACKUP_PATH/log.tar.gz --exclude=faillog --exclude=lastlog /var/log/
# Архивирование директории etc
tar -zcvf $BACKUP_PATH/etc.tar.gz /etc/
# Архивирование директории rbta
tar -zcvf $BACKUP_PATH/rbta.tar.gz /opt/rbta/
# Запуск затрагиваемых бэкапом сервисов
systemctl start apache2 celery celerybeat rabbitmq-server postgresql salt-minion salt-minion-standalone

А вот набор команд для восстановления:

# Перейти в директорию с резервными копиями
cd /tmp/backup/
# Разархивирование РК IPA
tar -C "/" -xvf ipa.tar.gz
# Восстановление IPA из РК
ipa-restore /var/lib/ipa/backup/ipa-full-YOUR_BACKUP_DATE
# Остановка затрагиваемых восстановлением сервисов
systemctl stop apache2 celery celerybeat rabbitmq-server postgresql salt-minion salt-minion-standalone salt-master
# Восстановление БД Postgresql
tar -C "/" -xvf postgresql.tar.gz
# Восстановление RabbitMQ
tar -C "/" -xvf rabbitmq.tar.gz
# Восстановление логов
tar -C "/" -xvf log.tar.gz
# Восстановление директории etc
tar -C "/" -xvf etc.tar.gz
# Восстановление директории rbta
tar -C "/" -xvf rbta.tar.gz
# Восстановление ipa-client
tar -C "/" -xvf ipa-client.tar.gz
# Перезагрузка
reboot

Если в домене несколько контроллеров, то после восстановления сервера вы будете наблюдать ошибки репликации в журнале /var/log/dirsrv/slapd-ALD-COMPANY-LAN/errors, и вам нужно будет как можно скорее выполнить повторную инициализацию этого сервера (или, наоборот, использовать данные этого сервера для переинициализации остальных контроллеров в домене). Например, если мы восстановили dc-2 и хотим забрать актуальные данные с dc-1, то нужно выполнить команду:

admin@dc-2:~$ sudo ipa-replica-manage re-initialize --from dc-1.ald.company.lan
Update in progress, 7 seconds elapsed
Update succeeded

Напомним, что для проверки состояния репликации между двумя конкретными серверами RedHat предлагает использовать утилиту ds-replcheck:

admin@dc-2:~$ ds-replcheck online -D "cn=Directory Manager" -m ldap://dc-1.ald.company.lan:389 -r ldap://dc-2.ald.company.lan:389 -b dc=ald,dc=company,dc=lan

Подсистема общего доступа к файлам 

Для выполнения резервного копирования подсистемы общего доступа к файлам необходимо выполнить скрипт:

#!/usr/bin/env bash
# Название директории для резервной копии формируется
# из текущей даты и находится в папке /tmp/backup
now=$(date +"%d-%m-%Y")
BACKUP_PATH=/tmp/backup/$now
# Создание временной директории для резервных копий
mkdir -p $BACKUP_PATH
# Остановка затрагиваемых бэкапом сервисов
systemctl stop salt-minion salt-minion-standalone
# Архивирование логов
tar -zcvf $BACKUP_PATH/log.tar.gz --exclude=faillog --exclude=lastlog /var/log/
# Архивирование директории etc
tar -zcvf $BACKUP_PATH/etc.tar.gz /etc/
# Архивирование директории ipa-client
tar -zcvf $BACKUP_PATH/ipa-client.tar.gz /var/lib/ipa-client/
# Архивирование директории /opt/samba_shares/
tar -zcvf $BACKUP_PATH/samba.tar.gz /opt/samba_shares/
# Запуск затрагиваемых бэкапом сервисов
systemctl start salt-minion salt-minion-standalone