☰

使用 slapcat 备份 LDAP

tag-icon • tag-icon backup ldap
使用 slapcat 备份 LDAP

我在 Debian 服务器上运行 OpenLDAP 目录，使用 hdb 后端。我一直在考虑备份，并在网上查阅了一些资料。Slapcat 似乎是可行的方法，但我不断看到这些帖子说在 slapd 运行时使用它很危险。

这有什么危险？我计划在夜间运行这些备份，夜间不会对数据库进行任何写入 - 但可能会发生读取。

如果有其他更适合此情况的备份解决方案，我很乐意听到。

答案1

OpenLDAP 支持各种后端，目前最流行的是 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 运行时运行它就没有问题。我在许多服务器上都使用它，并推荐它。这确实是备份的最佳方式。

替代方案包括向服务器发出 ldap 搜索命令以返回整个树。这将比 slapcat 慢得多，因为所有通信都必须经过网络层，并且必须检查访问控制规则。此外，您必须非常确定您正在搜索的用户具有正确的访问权限。

答案2

与其他答案一样，我们一直使用 slapcat 进行备份。它们在 4 年多的时间里非常可靠，但自从从 Debian lenny 升级到 squeeze 以来，我们偶尔会遇到备份被截断的情况。这些损坏的备份大约发生在 30 个案例中的 1 个。我们在 slapd 运行时运行 slapcat。糟糕的是，slapcat 没有给出任何问题迹象，即退出代码为零。由于历史原因，我们使用 bdb 后端。使用 hdb 后端可能会更好。

我们四处寻找更好的备份策略，但除了设置一个可以停止备份的从属服务器外，就标准程序或最佳实践而言，没有太多其他选择。这促使我们重新考虑我们的备份策略，并编写了一些脚本来自动化新策略。

首先，我们有一个名为 safe-ldif 的脚本，它会多次运行 slapcat，直到它连续两次获得相同数量的 LDAP 条目。这是速度和可靠性之间的权衡。其次，我们决定将所有 LDIF 条目单独放在 Git 存储库中。这比仅从 slapcat 压缩单个 LDIF 文件提供了更好的压缩效果。此外，拥有单个 LDIF 节的历史记录非常方便。

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

答案3

slapcat 之所以危险是因为它直接在数据库中搜索。根据数据库格式，这可能会导致文件损坏或死锁。

这是我的做法：

  1. 在两个 openldap 安装之间设置复制
  2. 定期关闭从服务器上的 slapd，复制数据库文件，然后重新启动

就是这样。我在同一台机器上运行 openldap 的两个副本（不同的端口，复制仅绑定到，127.0.0.1因此它不会泄漏到实际的以太网上）。

答案4

如果您愿意使用 bdb 后端重新创建 LDAP 目录，这可能是可行的方法。在我的站点上，过去六年左右，我们每 4 小时对包含约 10k 个条目的实时目录运行一次 slapcat 备份，并且没有遇到任何问题。

相关内容