Я запускаю каталог OpenLDAP на сервере Debian, используя бэкэнд hdb. Меня интересовали резервные копии, и я кое-что читал в сети. Slapcat кажется подходящим вариантом, но я продолжаю видеть эти сообщения, в которых говорится о том, что его опасно использовать во время работы slapd.
Чем это опасно? Я планирую запускать эти резервные копии в течение ночи, и в течение ночи запись в базу данных производиться не будет - хотя чтение, вероятно, произойдет.
Если есть какое-либо другое решение для резервного копирования, которое лучше подходит для этого, я с радостью узнаю об этом.
OpenLDAP поддерживает различные бэкенды, наиболее популярными в настоящее время являются bdb / hdb. Из man-страница slapcat:
For some backend types, your slapd(8) should not be running (at least,
not in read-write mode) when you do this to ensure consistency of the
database. It is always safe to run slapcat with the slapd-bdb(5),
slapd-hdb(5), and slapd-null(5) backends.
Итак, пока вы используете bdb или hdb в качестве бэкэнда, нет проблем с его запуском во время работы slapd. Я использую это на многих серверах и рекомендую. Это действительно лучший способ резервного копирования.
Альтернативой может быть отправка серверу команды поиска ldap для возврата всего дерева. Это будет значительно медленнее, чем slapcat, потому что все коммуникации должны проходить через сетевые уровни, а правила контроля доступа должны быть проверены. Кроме того, вы должны быть очень уверены, что у пользователя, которого вы ищете, есть правильные права доступа.
Мы использовали slapcat для наших резервных копий, как и другие упомянутые ответы. Они были очень надежными в течение 4+ лет, но после обновления Debian lenny до squeeze мы иногда сталкивались с усеченными резервными копиями. Такие неработающие резервные копии возникают примерно в 1 из 30 случаев. Мы запускаем slapcat, пока запущен slapd. Плохо то, что slapcat не указывает на проблему, то есть код выхода равен нулю. По историческим причинам мы используем бэкэнд bdb. Может быть лучше с бэкэндом hdb.
Мы посмотрели вокруг, чтобы рассмотреть лучшие стратегии резервного копирования, но кроме настройки ведомого устройства, которое можно остановить для резервного копирования, нет ничего, кроме стандартных процедур или лучших практик. Это заставило нас переосмыслить нашу политику резервного копирования и написать несколько сценариев для автоматизации новой политики.
Прежде всего, у нас есть сценарий с именем safe-ldif, который запускает slapcat несколько раз, пока не получит одинаковое количество записей LDAP дважды подряд. Это компромисс между скоростью и надежностью. Во-вторых, мы решили поместить все записи LDIF по отдельности в репозиторий Git. Это дает нам гораздо лучшее сжатие, чем просто сжатие отдельных файлов LDIF из slapcat. Кроме того, очень удобно иметь историю отдельных строф LDIF.
Если кому-то еще интересно, взгляните на https://github.com/elmar/ldap-git-backup
Причина, по которой slapcat опасен, заключается в том, что он роется в базе данных напрямую. В зависимости от формата базы данных это может вызвать повреждение файла или взаимоблокировки.
Вот что я делаю:
Вот и все. Я запускаю обе копии openldap на одном компьютере (разные порты, репликация привязана только к 127.0.0.1 поэтому он не просачивается в настоящую сеть Ethernet).
Если вы хотите воссоздать свой каталог LDAP с помощью серверной части bdb, это может быть подходящим вариантом. На моем сайте мы выполняли резервное копирование slapcat в реальном каталоге с ~ 10k записями каждые 4 часа в течение последних шести лет или около того, и у нас не было ни одной проблемы с этим.