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

Глава по обслуживанию в руководстве администратора OpenLDAP не слишком подробно описывает решаемые проблемы. Будем надеятся, что этот раздел поможет Вам.

10.1 Резервное копирование

Где работаем: ldap-srv

Что мы будем резервировать?

База данных и конфигурация сервера OpenLDAP могут быть выгружены в LDIF-файлы с помощью slapcat. Запакуем их вместе в один tar-файл. Общесистемная конфигурация — это всё остальное. Например, набор ключей Kerberos (keytab) и файл /etc/defaults/slapd.

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

#  mkdir -p /root/scripts /root/backup /var/log/backup
#  touch /root/scripts/backup.slapd.sh
#  chmod +x /root/scripts/backup.slapd.sh

И запишем в файл backup.slapd.sh несложный скрипт:

#!/bin/sh

# Копируем данные и конфигурацию OpenLDAP в сжатые LDIF-файлы.
# А так же резервируем весь каталог OpenLDAP и конфигурацию демона slapd.

umask 022

PATH="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin"
export PATH

DATE=`date +%Y%m%d`

BACKUP_DIR="/root/backup/slapd"
BACKUP_DATA_FILENAME="slapd.data.${DATE}.ldif"
BACKUP_CONFIG_FILENAME="slapd.config.${DATE}.ldif"
BACKUP_TAR_FILENAME="slapd.directory.${DATE}.tar.gz"

CA_TLS_CERT="/etc/ssl/certs/rootca.crt"

DIT_CONFIG="cn=config"
DIT_SUFFIX="dc=example,dc=com"

SLAPD_CONFIG_FILENAME="/etc/default/slapd"
SLAPD_DIR="/etc/ldap"
SLAPD_LOG_ROTATION="/etc/logrotate.d/slapd"
SLAPD_TLS_CERT="/etc/ldap/ssl/ldap-srv.example.com.crt"
SLAPD_TLS_KEY="/etc/ldap/ssl/ldap-srv.example.com.key"
SLAPCAT_OPTIONS="-F /etc/ldap/slapd.d"

LOGFILE="/var/log/backup/slapd.log"
KEEP="30"

# Убедимся, что скрипт запущен от имени суперпользователя
if [ `id -u` -ne "0" ]; then
 echo "ERROR: only root can run this script." | tee -a ${LOGFILE}
 exit 1
fi

# Проверим, есть ли у нас файл для журнала
if [ ! -f ${LOGFILE} ]; then
 touch ${LOGFILE}

 if [ "$?" -ne "0" ]; then
  echo "ERROR: could not create the log file."
  exit 1
 fi
fi

# Убедимся, что у нас есть каталог для резервных копий
if [ ! -d ${BACKUP_DIR} ]; then
 mkdir -p ${BACKUP_DIR}

 if [ "$?" -ne "0" ]; then
  echo "ERROR: could not create the backup directory." | tee -a ${LOGFILE}
  exit 1
 fi
fi

# Убедимся, что в нашем каталоге с резервными копиями не свалено слишком много файлов
# и удалим все резервные копии кроме последних ${KEEP} копий.
FILES=`find ${BACKUP_DIR} -type f -name "slapd.*" -print | wc -l`

if [ "${FILES}" -gt "${KEEP}" ]; then
 OVER=`echo ${FILES}-${KEEP} | bc`
 RMFILES=`find ${BACKUP_DIR} -type f -name "slapd.*" -print | sort -r | tail -${OVER}`
 echo "NOTE: removing ${RMFILES} from the backup directory." >> ${LOGFILE}
 rm ${RMFILES}
fi

# Создаём резервную копию данных из DIT
slapcat ${SLAPCAT_OPTIONS} -b ${DIT_SUFFIX} -l ${BACKUP_DIR}/${BACKUP_DATA_FILENAME} >/dev/null 2>&1

if [ "$?" -eq "0" ]; then
 gzip -f ${BACKUP_DIR}/${BACKUP_DATA_FILENAME} 2>&1 >> ${LOGFILE}

 if [ "$?" -ne "0" ] ; then
  echo "ERROR: dump file compression problem." | tee -a ${LOGFILE}
  exit 1
 fi
else
 echo "ERROR: problem running slapcat(8C) for the DIT data backup." | tee -a ${LOGFILE}
 rm ${BACKUP_DIR}/${BACKUP_DATA_FILENAME}
 exit 1
fi

# Сохраняем конфигурацию DIT в виде LDIF-файла
slapcat ${SLAPCAT_OPTIONS} -b ${DIT_CONFIG} -l ${BACKUP_DIR}/${BACKUP_CONFIG_FILENAME} >/dev/null 2>&1

if [ "$?" -eq "0" ]; then
 gzip -f ${BACKUP_DIR}/${BACKUP_CONFIG_FILENAME} 2>&1 >> ${LOGFILE}

 if [ "$?" -ne "0" ] ; then
  echo "ERROR: dump file compression problem." | tee -a ${LOGFILE}
  exit 1
 fi
else
 echo "ERROR: problem running slapcat(8C) for the DIT config backup." | tee -a ${LOGFILE}
 rm ${BACKUP_DIR}/${BACKUP_CONFIG_FILENAME}
 exit 1
fi

# Делаем резервную копию файлов каталога и конфигурации
BACKUP_FILES_LIST="${CA_TLS_CERT} ${SLAPD_CONFIG_FILENAME} ${SLAPD_DIR} ${SLAPD_LOG_ROTATION} ${SLAPD_TLS_CERT} ${SLAPD_TLS_KEY}"

tar zcf ${BACKUP_DIR}/${BACKUP_TAR_FILENAME} ${BACKUP_FILES_LIST} >/dev/null 2>&1

if [ "$?" -ne "0" ]; then
 echo "ERROR: problem running config directory tar." | tee -a ${LOGFILE}
 rm ${BACKUP_DIR}/${BACKUP_TAR_FILENAME}
 exit 1
fi

Создадим задание планировщика cron для нашего скрипта:

#  crontab -e

Откроется конфигурация планировщика для суперпользователя. Допишем в неё:

# Резервное копирование для OpenLDAP
00 22 * * * /root/scripts/backup.slapd.sh

По этому правилу резервное копирование запускается каждый день в 22:00. Запустите скрипт вручную или дождитесь и проверьте, что всё работает.

ВНИМАНИЕ! Копируйте файлы на другой сервер! Лучше всего монтировать сетевые ресурсы в каталоги резервного копирования (в нашем случае — в /root/backup). Тогда все данные сразу будут заливаться на удалённый сервер.

10.2 Восстановление

В случае выхода из строя сервера OpenLDAP у нас есть всё, чтобы его воскресить. Сценарий восстановления зависит от типа решаемой проблемы:

  1. Полная потеря сервера;
  2. Проблемы с ACL;
  3. Повреждение данных (или человеческий фактор);
  4. Исчерпано свободное место в файловой системе.

10.2.1 Полная потеря сервера

Где работаем: ldap-srv

Если сервер который крутит OpenLDAP сломается, то первым делом нам нужно будет найти другой или починить этот. Затем потребуется установить на него Ubuntu 14.04. Потом скопируйте на него файлы из резервной копии и выполните следующие команды:

#  apt-get install -y slapd ldap-utils krb5-kdc-ldap krb5-pkinit krb5-admin-server libnss-ldapd libpam-ldapd wamerican sudo-ldap
#  mv /etc/ldap /etc/ldap.install
#  cd / && tar zxvf /tmp/slapd.directory.20141215.tar.gz
#  update-rc.d slapd defaults
#  service slapd start

Это поможет Вам начать работать. Конечно, затем нужно будет перенастроить rsyslog. Смотрите раздел 2.3.

10.2.2 Проблемы с ACL

Где работаем: ldap-srv

Чаще всего такое случается при настройке сервера. При изменении ACL Вы можете закрыть самим себе любой доступ к нему. Поправить ситуацию не сложно:

#  service nslcd stop
#  service nscd stop
#  service slapd stop
#  mv /etc/ldap /etc/ldap.broken
#  cd / && tar zxvf /root/backup/slapd/slapd.directory.20141215.tar.gz
#  service slapd start
#  service nscd start
#  service nslcd start

10.2.3 Повреждение данных (или человеческий фактор)

Где работаем: ldap-srv

Чтож, иногда и администраторы совершают ошибки. В обычной ситуации достаточно просто запустить LDAP-браузер и вернуть всё как было. Но допустим один администратор в пятницу сделал изменение и уехал заниматься альпинизмом. Другой администратор не имел ни малейшего понятия об изменениях и в субботу после обеда мы имеем сломанную конфигурацию. В таких ситуациях у среднестатистического администратора нет терпения для отладки. Поэтому самый простой (и самый быстрый!) способ исправления ошибки — остановить демон slapd и вернуть данные из резервной копии, которая была сделана в четверг, с помощью slapadd.

#  service nslcd stop
#  service nscd stop
#  service slapd stop
#  mv /var/lib/ldap /var/lib/ldap.broken
#  mkdir /var/lib/ldap
#  zcat /root/backup/slapd/slapd.data.20141212.ldif.gz > /tmp/slapd.data.ldif
#  slapadd -v < /tmp/slapd.data.ldif
#  chown -R openldap:openldap /var/lib/ldap
#  service slapd start
#  service nscd start
#  service nslcd start

Это вернёт данные из любого файла, в который мы сохраняли наши резервные копии.

10.2.4 Исчерпано свободное место в файловой системе

Где работаем: ldap-srv

Вы ведь храните каталог /var в отдельной файловой системе (CCE-14777-7)? Иногда в нём кончается свободное место. Это может случиться как от разрастания базы данных в /var/lib/ldap, так и от слишком активного наполнения каталога /var/log журналами событий (подсказка: храните базу LDAP в отдельной ФС). Отсутствие свободного места будет генерировать ошибки в журналах. Используемый нами мехнизм манипуляции данными MDB не требует каких-либо особых процедур для восстановления из такого состояния. После вполне очевидного решения проблемы увеличения свободного места (lvresize / монтирование новой ФС / btrfs filesystem resize …) нужно просто перезапустить демоны:

#  service slapd restart
#  service nscd restart
#  service nslcd restart

Вот и всё! Если пропали какие-то данные, просто восстановите их из резервной копии как описано в предыдущем разделе.

Pro-LDAP.ru 2015 г. Последнее изменение страницы — 3 мая 2015 г. Вопросы и предложения принимаются на форуме проекта.