UMGUM.COM (лучше) 

Bacula + LDAP backup ( Резервное копирование настроек и данных LDAP-инстанса с помощью Bacula в среде OS Linux. )

3 декабря 2018

OS: "Linux Debian 6/7/8 (Squeeze/Wheezy/Jessie)", "Linux Ubuntu 14/16 (Trusty/Xenial) LTS".
Application: LDAP-server "389-DS v1.3", "Bacula v5.2/7.4".

Задача: наладить резервное копирование настроек и "баз данных" LDAP-инстансов полностью, с последующей выгрузкой в централизованное хранилище под управлением "Bacula".

Программное обеспечение SLDAP (Standalone LDAP), предназначающееся для обслуживания "баз данных" LDAP (Lightweight Directory Access Protocol), родилось почти одновременно с "интернетом" (в 1992-м году в Мичиганском университете выпускается пререлиз, работающий со спецификацией LDAP-протокола ещё не утверждённой в RFC) и похоже, что его инструментарий и методы инициализации не сильно с тех пор развились - оно было простым и осталось таковым настолько, что даже начинает выглядеть корявым на фоне современных подходов к реализации интерфейсов и средств управления.


Обзор резервируемых ресурсов.

Если говорить о LDAP-сервере "389-DS (Directory Server)" разработки "RedHat", то параметры первого этапа запуска инстансов (их может быть несколько) сосредоточены в файлах конфигурации, именованных по принципу "dirsrv-INSTANCE_NAME", по умолчанию располагающихся в немного неподходящей для этого директории "/etc/default". Там всего несколько переменных окружения, указывающих на месторасположение исполняемых и конфигурационных файлов запускаемого сервиса, таких как:

# cat /etc/default/dirsrv-ldap.example.net

....
SERVERBIN_DIR=/usr/sbin ; export SERVERBIN_DIR
CONFIG_DIR=/etc/dirsrv/slapd-ldap.example.net ; export CONFIG_DIR
....

Запускающийся сервис LDAP-сервера "389-DS" руководствуется обширным набором параметров из конфигурационных LDIF-файлов, загружаемых из соответствующей инстансу директории, задаваемой переменной окружения "CONFIG_DIR". Данные "каталогов" как таковых обычно размещаются в директории "/var/lib/dirsrv/slapd-INSTANCE_NAME/db" (определяется параметром "nsslapd-directory").

С учётом крайней простоты реализации методик обработки и хранения данных LDAP-сервером "389-DS" для полноценного резервного копирования достаточно выгрузки конфигурационных файлов из двух мест (оба в структуре директории "/etc") и набора файлов "базы данных" как таковых - единственное неудобство состоит в необходимости останавливать сервис "каталога" на момент выгрузки данных для обеспечения гарантированной консистентности таковых.

Общие рассуждения о неприменимости готовых решений.

Если копнуть глубже, то в дистрибутивном наборе LDAP "389-DS" обнаружатся два скрипта, предназначающихся специально для резервного копирования - один на Bash (/usr/sbin/db2bak), а второй на Perl (/usr/sbin/db2bak-online). Причём Bash-скрипт может выгружать резервную копию только с полным выключением LDAP-сервиса, а вот Perl-скрипт может это делать и "на лету".

Однако в использовании этих двух готовых решений есть ряд неудобств - как часто бывает в "этих ваших линуксах". Во первых, Bash-скрипт "db2bak" представляет собой лишь простейшую обёртку для единственной команды "ns-slapd db2archive", которую мы и там можем отдать самостоятельно, избегнув применения лишней прослойки. Во вторых, Perl-скрипт "db2bak-online" требует предоставления ему в открытом виде логина и пароля для подключения к LDAP-сервису с полным доступом к иерархии данных резервируемого "каталога", и не предоставляет чёткой обратной связи о процессе резервного копирования (!), сразу после отдачи команды сообщая о её успешном завершении, вне зависимости от реального состояния дел (!), совершая все дальнейшие процедуры в фоновом режиме и выводя текущие статусные сообщения в журнал ошибок (!) - иначе говоря, вообще невозможно без дополнительных проверок узнать, сделана ли утилитой "db2bak-online" резервная копия.

Итого: применение встроенных средств резервного копирования LDAP "389-DS" нецелесообразно и даже небезопасно.

Пробный запуск процедуры выгрузки "бэкапа".

Стремясь к применению простых и надёжных решений, для резервного копирования небольшого LDAP-сервиса (до нескольких сотен тысяч записей) я прихожу к методике выключения такового, быстрой выгрузки данных на файловую систему рядом и немедленному включению сервиса - это происходит буквально за одну секунду. Учитывая то, что в действительно ответственном сервисе "каталогов" должно быть два узла (связанных репликацией) обслуживания запросов пользователей, таким кратковременным простоем можно смело пренебречь.

Итак, запускаем тестовое резервное копирование:

# mkdir -p /var/backups/bacula-slapd
# chown -R dirsrv:dirsrv /var/backups/bacula-slapd
# stop-dirsrv ldap.example.net
# ns-slapd db2archive -D /etc/dirsrv/slapd-ldap.example.net -a /var/backups/bacula-slapd/ldap.example.net

Backing up file 1 (/var/backups/bacula-slapd/ldap.example.net/userRoot/entryusn.db)
Copying /var/lib/dirsrv/slapd-ldap.example.net/db/userRoot/entryusn.db to /var/backups/bacula-slapd/ldap.example.net/userRoot/entryusn.db
....
Backing up file 37 (/var/backups/bacula-slapd/ldap.example.net/NetscapeRoot/ancestorid.db)
Copying /var/lib/dirsrv/slapd-ldap.example.net/db/NetscapeRoot/ancestorid.db to /var/backups/bacula-slapd/ldap.example.net/NetscapeRoot/ancestorid.db
All database threads now stopped

# start-dirsrv ldap.example.net

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

Настройка резервного копирования посредством "Bacula".

Дополним описание настроек "Bacula", касающиеся резервного копирования клиентского GitLab-сервиса:

# vi /etc/bacula/client.d/ldap.example.net.conf

....
File Set {
  Name = "file-set-ldap.example.net"
  ....

  # Директории конфигураций и резервных копий сервиса LDAP
  File = "/etc/default/"
  File = "/etc/dirsrv/"
  File = "/var/backups/bacula-slapd/"
  ....
}
....

Job {
  Name = "ldap.example.net"
  Type = Backup
  ....

  # Запуск выгрузки резервной копии локальной БД LDAP-инстанса "389-DS" с остановкой сервиса:
  # (Debian: основной конфигурационный файл "/etc/default/dirsrv-ldap.example.net")
  Run Script {
    Runs When = Before
    Fail Job On Error = No
    Command = "rm -rf /var/backups/bacula-slapd"
    Command = "mkdir -p /var/backups/bacula-slapd"
    Command = "chown -R dirsrv:dirsrv /var/backups/bacula-slapd"
    Command = "chmod -R go-rwx /var/backups/bacula-slapd"
    Command = "/bin/bash -c 'stop-dirsrv ldap.example.net'"
    Command = "/bin/bash -c 'ns-slapd db2archive -D /etc/dirsrv/slapd-ldap.example.net -a /var/backups/bacula-slapd/ldap.example.net 1>/var/log/bacula-slapd.log 2>&1'"
    Command = "/bin/bash -c 'start-dirsrv ldap.example.net'"
  }
  #
  Run Script {
    Runs When = After
    Runs On Failure = yes
    Command = "rm -rf /var/backups/bacula-slapd"
  }
  ....
}

Не забываем проверять корректность конфигурации в целом средствами самого Bacula:

# bacula-dir -c /etc/bacula/bacula-dir.conf -t


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )