GitLab が大規模な NextCloud ストレージのバックアップにどのように役立つか

おい、ハブル！

今日は、さまざまな構成で Nextcloud ストレージからのビッグ データのバックアップを自動化した経験について話したいと思います。 私は Molniya AK でサービス ステーションとして働いており、IT システムの構成管理を行っており、データ ストレージには Nextcloud が使用されています。 分散構造、冗長性を含む。

インストールの特徴から生じる問題は、大量のデータがあることです。 Nextcloud が提供するバージョン管理、冗長性、主観的な理由などにより、多くの重複が作成されます。

背景

Nextcloud を管理する場合、データは貴重であるため、効果的なバックアップを組織するという問題が発生します。バックアップは暗号化する必要があります。

当社では、当社の場所または顧客の Nextcloud とは別のマシンにバックアップを保存するオプションを提供していますが、これには柔軟な自動化された管理アプローチが必要です。

多くのクライアントがあり、そのすべてが異なる構成を持ち、すべて独自のサイトにあり、独自の特性を持っています。 これは、サイト全体が自分のものであり、バックアップがクラウンから作成されている場合の標準的な手法ですが、あまり適していません。

まず、入力データを見てみましょう。 必要なものは次のとおりです。

• XNUMX つまたは複数のノードに関するスケーラビリティ。 大規模なインストールの場合、ストレージとして minio を使用します。
• バックアップの実行に関する問題を調べてください。
• クライアントおよび/または当社でバックアップを保持する必要があります。
• 問題に迅速かつ簡単に対処します。
• クライアントとインストールは互いに大きく異なるため、均一性を実現することはできません。
• 完全回復 (災害)、XNUMX つのフォルダーを誤って消去した場合の XNUMX つのシナリオでは、回復速度は最小限になるはずです。
• 重複排除機能が必要です。

バックアップ管理の問題を解決するために、GitLab をインストールしました。 詳細はタックル別に。

もちろん、このような問題を解決したのは私たちが初めてではありませんが、私たちの実践的で苦労して得た経験は興味深いものになる可能性があると思われるので、それを共有する準備ができています。

当社はオープンソース ポリシーを採用しているため、オープンソース ソリューションを探していました。 順番に、開発内容を共有し、投稿します。 たとえば、GitHub には次のようなものがあります。 Nextcloud 用のプラグイン、これをクライアントに提供し、偶発的または意図的な削除の場合のデータセキュリティを強化します。

バックアップツール

私たちは、バックアップ作成ツールを選択することから解決方法の模索を開始しました。

通常の tar + gzip はうまく機能せず、データが複製されます。 多くの場合、増分には実際の変更はほとんど含まれず、単一ファイル内のデータの多くが繰り返されます。
分散データストレージの冗長性という別の問題もあります。 私たちは minio を使用していますが、そのデータは基本的に冗長です。 あるいは、minio 自体を介してバックアップを作成する必要がありました。minio をロードし、ファイル システム間のすべてのスペーサーを使用します。また、同様に重要なことですが、一部のバケットとメタ情報を忘れてしまうリスクがあります。 または重複排除を使用します。

重複のあるバックアップ ツールはオープン ソースで入手できます (Habré には 記事 このトピックについて)そしてファイナリストは ボルグ и レスティック。 XNUMX つのアプリケーションの比較は以下にありますが、ここでは全体のスキームをどのように構成したかを説明します。

バックアップの管理

Borg と Restic は優れていますが、どちらの製品も集中制御メカニズムを備えていません。 管理と制御の目的で、私たちはすでに実装済みのツールを選択しました。これなしでは自動化を含む作業を想像することはできません。これが有名な CI/CD、GitLab です。

考え方は次のとおりです。gitlab-runner は Nextcloud データを保存する各ノードにインストールされます。 ランナーは、バックアップ プロセスを監視するスケジュールに従ってスクリプトを実行し、Borg または Restic を起動します。

何が得られたでしょうか？ 実行からのフィードバック、変更の便利な制御、エラーの場合の詳細。

ここで ここGitHubにあります さまざまなタスクのスクリプトの例を投稿し、最終的には Nextcloud だけでなく、他の多くのサービスのバックアップにもスクリプトを添付することになりました。 手動で構成したくない場合 (そして私たちもそうしたくない場合) には、スケジューラもあります。

Gitlab API で CI/CD タイムアウトを変更する方法はまだありませんが、小さいものです。 それを増やす必要があるとします。 1d.

幸いなことに、GitLab はコミットに従ってだけでなく、スケジュールに従ってのみ起動することができます。これはまさに私たちが必要としているものです。

次にラッパースクリプトについてです。

このスクリプトには次の条件を設定します。

• 同じ機能を使用して、ランナーとコンソールから手動で起動する必要があります。
• エラー ハンドラーが必要です。
• リターンコード。
• ログ内の文字列を検索します。 たとえば、私たちにとってエラーは、プログラムが致命的とはみなさないメッセージである可能性があります。
• 処理タイムアウト。 リードタイムは妥当なものでなければなりません。
• 非常に詳細なログが必要です。 ただし、エラーが発生した場合に限ります。
• 開始前にいくつかのテストも実行されます。
• サポート プロセス中に役立つとわかった便利な小さなボーナス:
• 開始と終了はローカル マシンの syslog に記録されます。 これは、システムエラーとバックアップ操作を結び付けるのに役立ちます。
• エラー ログがある場合は、その一部が標準出力に出力され、ログ全体が別のファイルに書き込まれます。 CI をすぐに見て、軽微なエラーであれば評価するのに便利です。
• デバッグモード。

完全なログは GitLab にアーティファクトとして保存され、エラーがなければログは削除されます。 スクリプトはbashで書きます。

オープンソースに関するあらゆる提案やコメントを喜んで検討させていただきます - 歓迎します。

これはどう動かすのですか

Bash エグゼキュータを備えたランナーがバックアップ ノード上で起動されます。 スケジューラによれば、ジョブ CI/CD は特別なカブで起動されます。 ランナーは、そのようなタスク用のユニバーサル ラッパー スクリプトを起動し、バックアップ リポジトリ、マウント ポイント、その他必要なものすべての有効性をチェックし、古いリポジトリをバックアップしてクリーンアップします。 完成したバックアップ自体は S3 に送信されます。

私たちはこのスキームに従って作業しています。これは外部の AWS プロバイダーまたはロシアの同等プロバイダーです (より高速で、データはロシア連邦外に出ません)。 または、これらの目的のために、クライアントのサイトに別個の minio クラスターをインストールします。 通常、クライアントが回線からデータを一切流出したくない場合、セキュリティ上の理由からこれを行います。

ssh経由でバックアップを送信する機能は使用しませんでした。 これによってセキュリティが強化されるわけではありません。また、S3 プロバイダーのネットワーク機能は、XNUMX 台の ssh マシンよりもはるかに優れています。

ハッカーは S3 上のデータを消去できるため、ローカル マシンをハッカーから保護するには、バージョニングを有効にする必要があります。
バックアップは常に暗号化されます。

Borgには非暗号化モードがあります none, ただし、これをオンにすることは強くお勧めしません。 このモードでは、暗号化がないだけでなく、書き込み内容のチェックサムも計算されません。つまり、整合性はインデックスを使用して間接的にのみチェックできます。

別のスケジューラがバックアップのインデックスとコンテンツの整合性をチェックします。 チェックは遅くて長いため、月に XNUMX 回個別に実行します。 数日かかる場合もございます。

ロシア語のReadme

主な機能

• 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 インストールに使用でき、データベースのバックアップも可能です。 便利なのは、すべてが XNUMX か所にあるだけでなく、時間差が最小限であるため、データベースの内容がファイルの内容に近いことです。

レスティック vs ボーグ

ボーグとレスティックの比較もあります ここハブレでそして、私たちには別のものを作るというタスクはありませんでしたが、自分たち自身のものを作りました。 私たちにとって、それがデータ上でどのように見えるか、詳細が重要でした。 私たちはそれらを持ってきます。

すでに述べたもの (重複排除、高速リカバリなど) に加えて、当社の選択基準は次のとおりです。

• 未完成の仕事への抵抗。 キル -9 を確認します。
• ディスク上のサイズ。
• リソースの要件 (CPU、メモリ)。
• 保存された BLOB のサイズ。
• S3での作業。
• 整合性チェック。

テストのために、実際のデータと合計サイズ 1,6 TB を持つ XNUMX つのクライアントを使用しました。
条件。

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 を操作することに疑問は生じませんが、バックアップの完了後にアンマウントを実行してキャッシュを完全にリセットすることをお勧めします。 S3 の特徴は、ポンプ不足のチャンクがバケットに送信されないことです。つまり、不完全に埋められたデータは大きな損害につながります。
• 整合性チェックはどちらの場合でも正常に機能しますが、速度は大きく異なります。
  レスティック 3,5時間.
  Borg、100GB SSD ファイルキャッシュを搭載 – 5時間データがローカル ディスク上にある場合は、ほぼ同じ速度になります。
  Borg はキャッシュなしで S3 から直接読み取ります 33時間。 恐ろしく長い。

肝心なのは、Borg は圧縮でき、より大きな BLOB を持つことができるため、S3 でのストレージと GET/PUT 操作が安価になるということです。 ただし、これには検証がより複雑になり、時間がかかるという代償が伴います。 回復速度に関しては、特に違いは感じられませんでした。 Restic では (最初のバックアップの後) 後続のバックアップに少し時間がかかりますが、それほど大きくはありません。

最後に重要なことは、コミュニティの規模です。

そして私たちはボーグを選びました。

圧縮について一言

Borg には、優れた新しい圧縮アルゴリズム zstd が組み込まれています。 圧縮品質は gzip より劣ることはありませんが、はるかに高速です。 速度はデフォルトの lz4 と同等です。

たとえば、MySQL データベース ダンプは、同じ速度で lz4 よりも XNUMX 倍圧縮されます。 ただし、実際のデータの経験から、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 を介して XNUMX つのウィンドウでバックアップ ステータスを収集します。必要に応じて、問題に簡単に気づき、場所を特定するのも簡単です。

まとめ

その結果、バックアップを作成していること、バックアップが有効であること、バックアップに関連して発生した問題にはほとんど時間がかからず、職務管理者のレベルで解決されることが確実にわかります。 tar.gz や Bacula と比べて、バックアップに必要なスペースは非常にわずかです。

出所： habr.com