备份策略似乎是一个已解决的问题，但系统管理员经常遇到如何正确备份数据、将数据存储在何处以及如何在不同软件环境中标准化备份过程的问题。 2011 年，我们开发了自定义备份脚本，可以有效地处理客户 Web 项目的备份。这些脚本多年来为我们提供了良好的服务，根据需要将备份存储在我们的存储和外部存储库中。然而，随着我们的软件生态系统的发展和多样化，我们的脚本出现了不足，缺乏对 Redis 和 MySQL/PostgreSQL 等新技术的支持。脚本也变得很麻烦，除了电子邮件警报之外没有任何监控系统。
我们曾经紧凑的脚本演变成一个复杂且难以管理的系统。为不同的客户更新这些脚本变得具有挑战性，特别是当他们使用自定义版本时。到去年初，我们意识到我们需要一个更现代的解决方案。
在这篇文章中，我们将解释我们在开发nxs-backup时遇到的所有困难，并分享我们的经验和挑战。您还可以在您的项目中测试该工具并分享您的经验，我们非常有兴趣听取您的意见。现在，让我们开始吧！
我们列出了对新系统的要求：
我们研究了在创建第一个版本的 nxs-backup 之前就已经存在的开源解决方案。但他们都有自己的缺陷。例如，Bacula 对我们来说过载了不必要的功能，由于大量的手动工作（例如，用于编写/搜索数据库备份的脚本），初始配置是相当费力的工作，并且恢复副本需要使用特殊的实用程序等等
毫不奇怪，我们在考虑重写我们的工具时遇到了同样的问题。四年内发生一些变化并且在线出现新工具的可能性并不高，但仍然如此。
我们研究了一些以前没有考虑过的新工具。但是，正如前面所讨论的，这些也不适合我们。因为他们没有完全满足我们的要求。
我们最终得出两个重要结论：
在探索新版本之前，让我们先看看我们之前有什么以及为什么它对我们来说还不够。
旧版本支持MySQL、PostgreSQL、Redis、MongoDB等数据库，支持文件的离散和增量复制、多种远程存储（S3；SMB；NFS；FTP；SSH；WebDAV），并具有备份轮换、日志记录、e -邮件通知和外部模块。
现在，更多关于我们关心的事情。
在任何 Linux 上运行二进制文件而无需重新启动源文件
随着时间的推移，我们使用的系统列表已经大大增加。现在我们服务的项目使用非标准 deb 和 rpm 兼容发行版，例如 Arch、Suse、Alt 等。
最近的系统在运行 nxs-backup 时遇到困难，因为我们只收集了 deb 和 rpm 包，并且支持的系统版本列表有限。我们在某个地方重新提取了整个包，在某个地方只是二进制文件，在某个地方我们只需要运行源代码。
由于需要使用源代码，使用旧版本对于工程师来说非常不方便。更不用说这种模式下的安装和更新需要更多时间。您不必每小时设置 10 台服务器，而只需在一台服务器上花费一个小时。
我们很早就知道，如果您拥有一个没有系统依赖性的二进制文件，可以在任何发行版上运行，并且不会遇到不同版本的库和系统架构差异的问题，那么效果会更好。我们希望这个工具是一样的。
使用nxs-backup最小化docker镜像并在配置文件中支持ENV
最近、非常に多くのプロジェクトがコンテナ化された環境で動作しています。これらのプロジェクトにはバックアップも必要なので、コンテナ内で nxs-backup を実行します。コンテナ化された環境では、イメージのサイズを最小限に抑え、環境変数を操作できることが非常に重要です。
古いバージョンでは、環境変数を操作する機会が提供されませんでした。主な問題は、パスワードを構成に直接保存する必要があることでした。このため、パスワードのみを含む変数セットの代わりに、設定全体を変数に入れる必要があります。大規模な環境変数を編集するには、エンジニアの集中力がより必要になり、トラブルシューティングが少し難しくなります。
また、古いバージョンを使用する場合は、すでに大規模な Debian イメージを使用する必要があり、適切なバックアップのためにいくつかのライブラリとアプリケーションを追加する必要がありました。
イメージのスリム バージョンを使用した場合でも、最小サイズは約 250Mb でしたが、これは 1 つの小さなユーティリティとしてはかなり大きなサイズです。場合によっては、イメージがノードにプルされるまでの時間が原因で、コレクションの開始プロセスに影響を与えることがありました。 50 MB 以下の画像を取得したいと考えていました。
ヒューズなしでリモートストレージを操作
コンテナ環境のもう 1 つの問題は、ヒューズを使用してリモート ストレージをマウントすることです。
ホスト上でバックアップを実行している間も、これはまだ許容されます。適切なパッケージをインストールし、カーネルでヒューズを有効にしているため、機能するようになりました。
コンテナ内にヒューズが必要になると、物事が面白くなります。ホスト システムのコアに直接アクセスできる権限をアップグレードしない限り、問題は解決されず、セキュリティ レベルが大幅に低下します。
これは調整する必要があります。すべての顧客がセキュリティ ポリシーを弱めることに同意するわけではありません。だからこそ、思い出したくないほどの膨大な回避策を講じなければならなかったのです。さらに、層を追加すると障害の可能性が高まり、マウントされたリソースの状態をさらに監視する必要があります。 API を直接使用してリモート ストレージを操作する方が安全で安定しています。
メールだけでなくステータスの監視と通知の送信
今日、チームは日常業務で電子メールを使用することがますます少なくなっています。グループ チャットやグループ通話で問題について話し合う方がはるかに早いため、これは当然のことです。 Telegram、Slack、Mattermost、MS Teams、およびその他の同様の製品は、それによって広く配布されています。
さまざまなアラートを送信して通知してくれるボットもあります。そしてもちろん、私たちは、電子メールではなく、数百もの電子メールの中で、テレグラムのようなワークスペースでバックアップがクラッシュしたというレポートを確認したいと考えています。ちなみに、お客様の中には、Slack やその他のメッセンジャーで障害に関する情報を見たいという方もいらっしゃいます。 さらに、ステータスを追跡し、リアルタイムで作業の詳細を確認できるようにしたいと長年望んでいます。これを行うには、アプリケーションの形式を変更して、アプリケーションを悪魔に変える必要があります。 パフォーマンスが不十分ですもう 1 つの急性の痛みは、特定のシナリオでのパフォーマンス不足でした。
クライアントの 1 つは、ほぼ 1 テラバイトの巨大なファイル ダンプを持っていますが、そのすべてはテキストや写真などの小さなファイルです。私たちはこのものの増分コピーを収集していますが、次の問題があります。年 1 回のコピーには 3 日かかります。そうですね、古いバージョンでは、そのボリュームを 1 日以内に消化することはできません。
状況を考えると、実際には特定の日付のデータを復元することができません。これは私たちにとってまったく好ましくありません。
最初は、そのシンプルさと柔軟性のため、バックアップ ソリューションを Python で実装しました。しかし、需要が高まるにつれて、Python ベースのソリューションでは不十分になってきました。徹底的な議論の結果、いくつかの理由からシステムを Go で書き直すことにしました:
コンパイルと依存関係: Go の AOT コンパイラーは、依存関係のない汎用のバイナリを生成し、異なるシステム間でのデプロイメントを簡素化します。上記の問題はすべて、多かれ少なかれ、IT 部門に明らかな苦痛を与え、確かに重要なことに貴重な時間を費やすことになりましたが、これらのコストは回避できたはずです。さらに、特定の状況では、特定のリスクが事業主に生じました。これは、特定の日データが存在しない可能性が非常に低いですが、ゼロではありません。私たちは現状を受け入れることを拒否しました。
Nxs-バックアップ 3.0私たちの作業の結果、nxs-backup v 3.0 の新しいバージョンが作成され、最近 v3.8.0 にアップデートされました新しいバージョンの主な機能:
我们尝试保留大部分配置和应用程序逻辑，但存在一些更改。都是与上一版本缺陷的优化和修正有关
例如，我们将远程存储库的连接参数放在基本配置中，这样我们就不会每次为不同类型的备份指定它们。
下面是备份基本配置的示例。它包含通知通道、远程存储、日志记录和作业列表等常规设置。这是邮件通知的基本主要配置，我们强烈建议使用电子邮件通知作为默认方法。如果您需要更多功能，您可以查看文档中的参考。
关于陷阱的几句话
我们预计会面临某些挑战。否则的话就是愚蠢的。但有两个问题造成了最强烈的屁股。
内存泄漏或非最佳算法
即使在以前版本的 nxs-backup 中，我们也使用自己的文件归档实现。该解决方案的逻辑是尽量避免使用外部工具来创建备份，而使用文件是最简单的步骤。
在实践中，该解决方案被证明是可行的，尽管从测试中可以看出，对于大量文件来说并不是特别有效。当时我们把它写成 Python 的细节，并希望当我们切换到 Go 时看到显着的差异。
当我们最终进行新版本的负载测试时，我们得到了令人失望的结果。性能没有任何提升，内存消耗甚至比以前更高。我们正在寻找解决方案。阅读了很多关于这个主题的文章和研究，但他们都说使用“filepath.Walk”和“filepath.WalkDir”是最好的选择。这些方法的性能只会随着语言新版本的发布而提高。
为了优化内存消耗，我们甚至在创建增量副本时犯了错误。顺便说一句，损坏的选项实际上更有效。由于显而易见的原因，我们没有使用它们。
最终，一切都停留在要处理的文件数量上。我们测试了1000万。垃圾收集器似乎无法清除这么多生成的变量。
最终，意识到我们可能会在这里浪费太多时间，我们决定放弃我们的实现，转而采用经过时间考验且真正有效的解决方案 - GNU tar。
当我们想出更高效的解决方案来处理数千万个文件时，我们可能会回到自我实现的想法。
如此不同的ftp
使用 ftp 时出现了另一个问题。事实证明，不同的服务器对于相同的请求表现不同。
对于同一个请求，你要么得到正常的答案，要么得到与你的请求无关的错误，或者在你期望的时候没有得到错误，这是一个非常严重的问题。
因此，我们不得不放弃使用库“prasad83/goftp”，转而使用更简单的“jlaffaye/ftp”，因为第一个库无法与 Selectel 服务器正常工作。错误是在连接时，第一个尝试获取工作目录中的文件列表，并得到了上级目录访问权限的错误。使用“jlaffaye/ftp”就不存在这样的问题，因为它更简单并且不会向服务器发送任何请求。
下一个问题是没有请求时断开连接。并非所有服务器都这样做，但有些服务器确实如此。所以我们必须在每次请求之前检查连接器是否脱落并重新连接。
最重要的是从服务器获取文件的问题，或者说清楚，尝试获取不存在的文件。有些服务器在尝试访问此类文件时会出错，其他服务器会返回一个甚至可以读取的有效 io.Reader 接口对象，只有你得到一个空的字节。
所有这些情况都是凭经验发现的，必须自己处理。
结论
最重要的是，我们修复了旧版本的问题，影响工程师工作，给业务带来一定风险的事情。
我们还有上个版本中未实现的“愿望”，例如：
此列表现已添加新列表：
当然，我们很乐意了解社区的意见。您还看到哪些其他发展机会？您会添加哪些选项？
您可以在其网站上阅读文档并了解有关 nxs-backup 的更多信息，如果您想留下任何问题，我们的网站上还有故障排除部分。
我们已经在 Telegram 频道中对即将推出的功能进行了民意调查。关注我们参与此类活动，为工具的发展做出贡献！
下次见！
以上是维护开源备份工具：见解等的详细内容。更多信息请关注PHP中文网其他相关文章！
