如何大规模备份 Gitlab？

Question

当询问 Gitlab 支持如何在内部部署的 Gitlab 上进行 3TB 备份时，他们回答使用我们的工具来生成 tarball。

这在所有层面上对我来说都是错误的。这个 tarball 包含 postgres 转储、docker 图像、repo 数据、GIT LFS 等配置等等。将 TB 的静态数据与 KB 非常动态的数据一起备份是不正确的。然后是问题，我们想每小时做一次备份。

题

我真的很想从其他人那里知道他们是如何做到的，以获得一致的备份。

Linux 上的 ZFS 对我来说没问题，如果这是解决方案的一部分。

Answer 1

我会审查您正在备份的内容，并可能使用“多路径”方法。例如，您可以通过在备份服务器上不断运行 Git 拉取来备份 Git 存储库。那只会复制差异，并为您留下所有 Git 存储库的第二个副本。据推测，您可以使用 API 检测新的存储库。

并使用“内置”备份程序来备份问题等。我怀疑 3TB 是否来自这部分，因此您将能够以很少的成本经常进行备份。您还可以设置带有复制的热备份的 PostgreSQL 数据库。

可能您的 3TB 来自 Docker 注册表中的容器映像。你需要备份这些吗？如果是这样，那么可能有更好的方法。

基本上，我会建议真正查看构成备份的内容并备份各个部分的数据。

甚至 GitLab 的备份工具也可以选择包含/排除系统的某些部分，例如 Docker Registry。

Answer 2

对于如此短的备份间隔时间（1 小时），最好的办法是依靠文件系统级快照和 send/recv支持。

如果在您的环境中使用ZoL不是问题，我强烈建议您使用它。ZFS 是一个非常强大的文件系统，您会非常喜欢它提供的所有附加功能（例如：压缩）。与 结合使用时sanoid/syncoid，它可以提供非常强大的备份策略。主要缺点是它不包含在主线内核中，因此您需要单独安装/更新它。

或者，如果您确实需要将自己限制在包含主线的内容中，则可以使用 BTRFS。但一定要了解它的（许多）缺点和皮塔饼。

最后，另一种解决方案是使用lvmthin采取定期备份（如：带snapper），依靠第三方工具（如：bdsync，blocksync等）只复制/船增量。

一种不同的方法是拥有两台复制的机器（通过DRBD），您可以通过lvmthin.