主持人 > 博客 > 管理 > GitLab 如何帮助您备份大型 NextCloud 存储

GitLab 如何帮助您备份大型 NextCloud 存储

嘿哈布尔！

今天我想谈谈我们在不同配置下从 Nextcloud 存储自动备份大数据的经验。 我在 Molniya AK 担任服务站，负责 IT 系统的配置管理；Nextcloud 用于数据存储。 包括，具有分布式结构，具有冗余性。

由于安装的特点而产生的问题是数据量很大。 Nextcloud 提供的版本控制、冗余、主观原因等会造成许多重复。

史前

管理 Nextcloud 时，会出现组织有效备份的问题，必须对备份进行加密，因为数据很有价值。

我们提供在我们的地方或客户的 Nextcloud 不同机器上存储备份的选项，这需要灵活的自动化管理方法。

客户端有很多，它们都有不同的配置，并且都在自己的站点上并具有自己的特点。 当整个站点都属于您并且由皇冠制作备份时，这是一种标准技术；它不太适合。

首先，让我们看一下输入数据。 我们需要：

  • 一个或多个节点的可扩展性。 对于大型安装，我们使用 minio 作为存储。
  • 了解执行备份时遇到的问题。
  • 您需要与您的客户和/或我们一起保留备份。
  • 快速轻松地处理问题。
  • 客户端和安装彼此之间有很大不同 - 无法实现统一。
  • 在两种情况下恢复速度应该是最低的：完全恢复（灾难）、一个文件夹被错误删除。
  • 需要重复数据删除功能。

GitLab 如何帮助您备份大型 NextCloud 存储

为了解决管理备份的问题，我们安装了GitLab。 更多详细信息请参见tackle。

当然，我们并不是第一个解决此类问题的人，但在我们看来，我们来之不易的实际经验可能很有趣，并且我们准备分享它。

由于我们公司有开源政策，因此我们一直在寻找开源解决方案。 反过来，我们也会分享并发布我们的进展。 例如，在 GitHub 上有 我们的 Nextcloud 插件，我们向客户提供，以增强数据安全性，防止意外或故意删除。

备份工具

我们通过选择备份创建工具开始寻找解决方法。

常规 tar + gzip 效果不佳 - 数据是重复的。 增量通常包含很少的实际更改，并且单个文件中的大部分数据都是重复的。
还有一个问题——分布式数据存储的冗余。 我们使用minio，它的数据基本上是冗余的。 或者您必须通过 minio 本身进行备份 - 加载它并使用文件系统之间的所有间隔符，并且同样重要的是，存在忘记某些存储桶和元信息的风险。 或者使用重复数据删除。

具有复制功能的备份工具可在开源中获得（在 Habré 上有 文章 关于这个话题）我们的决赛入围者是 博格 и 雷斯蒂奇。 我们对这两个应用程序的比较如下，但现在我们将告诉您我们如何组织整个计划。

管理备份

Borg 和 Restic 都不错，但是这两个产品都没有集中控制机制。 出于管理和控制的目的，我们选择了一个我们已经实现的工具，没有它我们无法想象我们的工作，包括自动化——这就是众所周知的 CI/CD - GitLab。

思路是：在每个存储Nextcloud数据的节点上安装gitlab-runner。 运行程序按计划运行一个脚本来监视备份过程，并启动 Borg 或 Restic。

我们得到了什么？ 来自执行的反馈、对变更的便捷控制、发生错误时的详细信息。

这里 在 GitHub 上 我们发布了用于各种任务的脚本示例，最终我们不仅将其附加到 Nextcloud 的备份中，还附加到许多其他服务的备份中。 如果您不想手动配置它（我们也不想），还有一个调度程序和 .gitlab-ci.yml

目前还没有办法在 Gitlab API 中更改 CI/CD 超时，但它很小。 它需要增加，比如说 1d.

幸运的是，GitLab 不仅可以根据提交启动，而且只能根据时间表启动，这正是我们所需要的。

现在介绍包装脚本。

我们为此脚本设置以下条件：

  • 它应该由跑步者启动并从具有相同功能的控制台手动启动。
  • 必须有错误处理程序：
  • 返回码。
  • 在日志中搜索字符串。 例如，对于我们来说，错误可能是程序不认为是致命的消息。
  • 处理超时。 交货时间必须合理。
  • 我们需要一个非常详细的日志。 但仅限于出现错误时。
  • 在开始之前还要进行一些测试。
  • 为了方便起见，我们发现在支持过程中很有用的小额奖金：
  • 开始和结束记录在本地机器的 syslog 中。 这有助于连接系统错误和备份操作。
  • 部分错误日志（如果有）输出到 stdout，整个日志写入单独的文件。 如果错误很小，那么立即查看 CI 并评估错误是很方便的。
  • 调试模式。

完整日志作为工件保存在 GitLab 中；如果没有错误，则删除日志。 我们在 bash 中编写脚本。

我们很乐意考虑有关开源的任何建议和意见 - 欢迎。

怎么开动这个

具有 Bash 执行器的运行器在备份节点上启动。 根据调度程序，作业 CI/CD 是在一个特殊的萝卜中启动的。 运行程序为此类任务启动一个通用包装脚本，它检查备份存储库、挂载点和我们想要的所有内容的有效性，然后备份并清理旧的。 完成的备份本身将发送到 S3。

我们按照这个方案工作 - 它是外部 AWS 提供商或俄罗斯同等提供商（速度更快，并且数据不会离开俄罗斯联邦）。 或者我们出于这些目的在客户的站点上为客户安装一个单独的 minio 集群。 当客户端根本不希望数据离开其电路时，我们通常出于安全原因这样做。

我们没有使用通过 ssh 发送备份的功能。 这并没有增加安全性，而且S3提供商的网络能力比我们一台ssh机器高得多。

为了保护您的本地计算机免受黑客攻击，因为他可以删除 S3 上的数据，因此您必须启用版本控制。
备份始终对备份进行加密。

Borg 有未加密模式 none，但我们强烈不建议打开它。 在这种模式下，不仅不会加密，而且不会计算正在写入的内容的校验和，这意味着只能使用索引间接检查完整性。

单独的调度程序检查备份的索引和内容的完整性。 检查速度慢且时间长，因此我们每月单独运行一次。 可能需要几天时间。

俄语自述文件

主要功能

  • prepare 训练
  • testcheck 准备情况检查
  • maincommand 核心团队
  • forcepostscript 最终执行或错误执行的函数。 我们用它来卸载分区。

服务功能

  • cleanup 我们记录错误或删除日志文件。
  • checklog 解析日志中是否存在错误行。
  • ret 退出处理程序。
  • checktimeout 检查是否超时。

环境

  • VERBOSE=1 我们立即在屏幕上显示错误（标准输出）。
  • SAVELOGSONSUCCES=1 成功后保存日志。
  • INIT_REPO_IF_NOT_EXIST=1 如果存储库不存在，则创建它。 默认禁用。
  • TIMEOUT 主要操作的最长时间。 您可以将其设置为末尾的“m”、“h”或“d”。

旧副本的存储模式。 默认：

  • KEEP_DAILY=7
  • KEEP_WEEKLY=4
  • KEEP_MONTHLY=6

脚本内的变量

  • ERROR_STRING — 用于检查错误日志的字符串。
  • EXTRACT_ERROR_STRING — 如果出错则显示字符串的表达式。
  • KILL_TIMEOUT_SIGNAL — 如果超时则发出终止信号。
  • TAIL — 屏幕上有多少个字符串有错误。
  • COLORMSG — 消息的颜色（默认黄色）。

该脚本名为 wordpress，有一个条件名称，它的技巧是它还备份 mysql 数据库。 这意味着它可用于单节点 Nexcloud 安装，您还可以在其中备份数据库。 方便之处不仅在于所有内容都集中在一处，而且数据库的内容与文件的内容很接近，因为时间差很小。

雷斯蒂奇 vs 博格

还有博格和雷斯蒂克之间的比较 这里是哈布雷，我们的任务不是制作另一个，而是我们自己的。 对我们来说，重要的是它在我们的数据上的表现以及我们的具体情况。 我们带他们来。

除了已经提到的（重复数据删除、快速恢复等）之外，我们的选择标准：

  • 对未完成的工作的抵制。 检查是否有kill -9。
  • 磁盘上的大小。
  • 资源需求（CPU、内存）。
  • 存储的 blob 的大小。
  • 使用 S3。
  • 完整性检查。

为了进行测试，我们使用了一台具有真实数据的客户端，总大小为 1,6 TB。
条款和条件。

Borg 不知道如何直接使用 S3，我们将磁盘作为保险丝安装，通过 高飞。 Restic 将其发送到 S3 本身。

Goofys 工作得非常快而且很好，而且有 磁盘缓存模块，这进一步加快了工作速度。 它处于测试阶段，坦率地说，我们在测试（其他）期间因数据丢失而崩溃。 但方便之处在于，备份过程本身不需要太多读取，而主要是写入，因此我们仅在完整性检查时使用缓存。

为了减少网络的影响，我们使用了本地提供商 - Yandex Cloud。

对比测试结果。

  • Kill -9 并进一步重新启动均成功。
  • 磁盘上的大小。 Borg可以压缩，所以结果符合预期。

备份器
大小

博格
562Gb

雷斯蒂奇
628Gb

  • 通过CPU
    Borg本身消耗很少，采用默认压缩，但必须与goofys进程一起评估。 总的来说，它们具有可比性，并且在同一测试虚拟机上使用大约 1,2 个内核。
  • 记忆。 Restic约为0,5GB，Borg约为200MB。 但这与系统文件缓存相比，都是微不足道的。 所以建议分配更多的内存。
  • 斑点大小的差异是惊人的。

备份器
大小

博格
约500MB

雷斯蒂奇
约5MB

  • Restic S3 的体验非常棒。 通过 goofys 使用 Borg 不会产生任何问题，但有人指出，建议在备份完成后执行 umount 以完全重置缓存。 S3 的特点是，未泵送的块永远不会被发送到桶中，这意味着未完全填充的数据会导致重大损坏。
  • 完整性检查在这两种情况下都运行良好，但速度差异很大。
    雷斯蒂奇 3,5小时.
    Borg，具有 100GB SSD 文件缓存 – 5小时如果数据位于本地磁盘上，速度结果大致相同。
    Borg直接从S3读取，无需缓存 33小时。 长得可怕。

最重要的是，Borg 可以压缩并具有更大的 blob，这使得 S3 中的存储和 GET/PUT 操作更便宜。 但这是以更复杂和更慢的验证为代价的。 至于恢复速度，我们没有发现任何差异。 Restic 的后续备份（在第一个备份之后）时间会稍长一些，但并不明显。

最后但并非最不重要的选择是社区的规模。

我们选择了博格。

关于压缩的几句话

Borg 的武器库中有一个出色的新压缩算法 - zstd。 压缩质量不比gzip差，但速度快得多。 并且速度与默认的 lz4 相当。

例如，在相同速度下，MySQL 数据库转储的压缩效果是 lz4 的两倍。 然而，实际数据的经验表明，Nextcloud节点的压缩率差异很小。

Borg 有一个相当奖励的压缩模式 - 如果文件具有高熵，则根本不应用压缩，这会提高速度。 创建时通过选项启用
-C auto,zstd
对于 zstd 算法
因此，使用此选项，与默认压缩相比，我们得到
分别为 560Gb 和 562Gb。 我提醒您一下，上面示例中的数据，未经压缩的结果是 628Gb。 2GB差异的结果让我们有些惊讶，但我们认为我们最终还是会选择它。 auto,zstd.

备份验证方法

根据调度程序，虚拟机直接从提供者或客户端启动，大大减少了网络负载。 至少比自己养、拉流量便宜。

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

使用相同的方案，我们使用防病毒软件检查文件（事后）。 毕竟，用户向 Nextcloud 上传不同的内容，而且并不是每个人都有防病毒软件。 浇注时进行检查既耗时又影响业务。

可扩展性是通过在具有不同标签的不同节点上运行运行器来实现的。
我们的监控通过一个窗口中的 GitLab API 收集备份状态；如有必要，问题很容易被发现，也很容易定位。

结论

因此，我们确信我们进行了备份，我们的备份是有效的，备份中出现的问题只需要很少的时间，并且可以在值班管理员的级别上解决。 与 tar.gz 或 Bacula 相比，备份占用的空间非常小。

来源： habr.com

添加评论