使用slapcat来备份LDAP

OpenLDAP支持各种后端，目前最stream行的是bdb / hdb。 从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运行时没有问题。 我在很多服务器上使用它，并推荐它。 这真的是最好的备份方式。

替代scheme将包括发出一个ldapsearch命令到服务器返回整个树。 这将比slapcat慢得多，因为所有通信都必须经过networking层，并且必须检查访问控制规则。 另外，您必须确定您search的用户具有正确的访问权限。

我们一直在使用slapcat进行备份，就像其他提到的答案一样。 他们是非常可靠的4年以上，但自从Debian lenny升级到挤压我们经历偶尔被截断的备份。 这些断开的备份在30个案例中的大约1个中发生。 我们在slapd运行时正在运行slapcat。 不好的部分是slapcat没有提供任何问题，即退出代码为零。 由于历史原因，我们正在使用bdb后端。 hdb后端可能会更好。

我们环顾四周考虑了更好的备份策略，但除了设置一个可以停止备份的slave之外，就标准程序或最佳实践而言，没有太多其他的东西。 这使我们重新思考我们的备份策略，并编写一些脚本来自动化新策略。

首先，我们有一个名为safe-ldif的脚本，它多次运行slapcat，直到它连续两次获得相同数量的LDAP条目。 这是速度和可靠性之间的折衷。 其次，我们决定把所有的LDIF条目分别放在一个Git仓库中。 这比直接从slapcat压缩单独的LDIF文件给了我们更好的压缩。 另外有个人LDIF节的历史非常方便。

如果其他人有兴趣看一下https://github.com/elmar/ldap-git-backup

slapcat是危险的原因是因为它直接在数据库中四处移动。 根据数据库格式，这可能导致文件损坏或死锁。

这就是我所做的：

1. 设置两个openldap安装之间的复制
2. 定期closuresslave上的slapd，复制数据库文件，然后重新启动

而已。 我在同一台机器上运行两个openldap副本（不同的端口，复制只绑定到127.0.0.1所以它不泄漏到实际的以太网上）。

如果您愿意使用bdb后端重新创build您的LDAP目录，那可能就是要走的路。 在我的网站上，我们已经在过去六年左右的时间里每隔4小时在一个活动目录上运行一个slapcat备份，每次约有10K条目，并且没有任何问题。