バックアップ パート 3: 重複性と重複性のレビューとテスト

このノートでは、バックアップ サーバー上にアーカイブを作成してバックアップを実行するバックアップ ツールについて説明します。

要件を満たすものの中には、duplicity (deja dup の形式で優れたインターフェイスを備えています) と duplicati があります。

もう 10 つの非常に優れたバックアップ ツールは dar ですが、これには非常に広範なオプションのリストがあるため (テスト方法では機能のわずか XNUMX% しかカバーされていません)、現在のサイクルの一部としてテストしていません。

期待される結果

どちらの候補者も何らかの方法でアーカイブを作成するため、通常の tar をガイドとして使用できます。

さらに、完全コピーとファイルの現在の状態、または以前のアーカイブと現在のアーカイブ (増分、減分など) の差分のみを含むバックアップ コピーを作成することによって、ストレージ サーバー上のデータ ストレージがどの程度最適化されているかを評価します。 。

バックアップ作成時の動作:

1. バックアップ ストレージ サーバー上のファイルの数は比較的少ない (バックアップ コピーの数またはデータのサイズ (GB 単位) に相当) が、そのサイズはかなり大きくなります (数十から数百メガバイト)。
2. リポジトリ サイズには変更のみが含まれます。重複は保存されないため、リポジトリ サイズは rsync ベースのソフトウェアよりも小さくなります。
3. 圧縮や暗号化を使用する場合は CPU 負荷が高くなることが予想され、アーカイブや暗号化プロセスがバックアップ ストレージ サーバーで実行されている場合は、ネットワークとディスクの負荷が非常に高くなる可能性があります。

参考値として以下のコマンドを実行してみます。

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

実行結果は以下の通りでした。

実行時間は3分12秒。 の例のように、速度はバックアップ ストレージ サーバーのディスク サブシステムによって制限されていることがわかります。 rsync。 ほんの少しだけ早くなったから… 録音は XNUMX つのファイルになります。

また、圧縮を評価するために、同じオプションを実行しますが、バックアップ サーバー側で圧縮を有効にします。

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

結果は次のとおりです。

実行時間は10分11秒。 おそらくボトルネックは受信側のシングルフローコンプレッサーです。

同じコマンドですが、ボトルネックがシングルスレッドのコンプレッサーであるという仮説をテストするために、元のデータとともに圧縮がサーバーに転送されます。

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

次のようになりました。

実行時間は9分37秒でした。 コンプレッサーによる XNUMX つのコアへの負荷が明確に表示されます。 ネットワーク転送速度とソース ディスク サブシステムの負荷は同様です。

暗号化を評価するには、追加のコマンドを接続して openssl または gpg を使用できます。 openssl または gpg パイプの中。 参考までに、次のようなコマンドがあります。

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

結果は次のようになりました。

受信側で 10 つのプロセスが実行されていたため、実行時間は 30 分 2 秒でした。ボトルネックはやはりシングル スレッドのコンプレッサーと、わずかな暗号化オーバーヘッドです。

UPD： bliznezz のリクエストに応じて pigz を使用したテストを追加しています。 コンプレッサーのみを使用する場合は 6 分 30 秒、暗号化も追加すると約 7 分かかります。 下のグラフのくぼみは、フラッシュされていないディスク キャッシュです。

重複テスト

Duplicity は、tar 形式で暗号化されたアーカイブを作成してバックアップするための Python ソフトウェアです。

増分アーカイブの場合は librsync が使用されるため、次で説明されている動作が期待できます。 シリーズの前回の投稿.

バックアップは gnupg を使用して暗号化および署名できます。これは、バックアップの保存に別のプロバイダー (s3、backblaze、gdrive など) を使用する場合に重要です。

結果を見てみましょう:

これらは暗号化なしで実行したときに得られた結果です

ネタバレ

各テスト実行の実行時間:

ラン1
ラン2
ラン3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

そして、キー サイズ 2048 ビットで gnupg 暗号化が有効になっている場合の結果は次のとおりです。

暗号化を使用した場合の同じデータの動作時間:

ラン1
ラン2
ラン3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

ブロック サイズは 512 メガバイトと示されており、グラフではっきりと確認できます。 実際には、プロセッサの負荷は 50% のままでした。これは、プログラムが XNUMX つのプロセッサ コアしか使用していないことを意味します。

プログラムの動作原理も非常にはっきりとわかります。プログラムはデータを取得して圧縮し、バックアップ ストレージ サーバーに送信しますが、これは非常に遅い場合があります。
もう XNUMX つの特徴は、プログラムの実行時間が予測可能であることです。これは、変更されたデータのサイズのみに依存します。

暗号化を有効にしてもプログラムの実行時間は大幅に増加しませんでしたが、プロセッサの負荷が約 10% 増加しました。これは非常に良いボーナスとなります。

残念ながら、このプログラムはディレクトリの名前変更の状況を正しく検出できず、結果としてリポジトリのサイズは変更のサイズ（つまり、すべて 18GB）と同じであることが判明しましたが、信頼できないサーバーをバックアップに使用できることは明らかです。この動作については説明します。

重複テスト

このソフトウェアは C# で書かれており、Mono の一連のライブラリを使用して実行されます。 CLI バージョンだけでなく GUI バージョンもあります。

主な機能のおおよそのリストは、さまざまなバックアップ ストレージ プロバイダーを含む Duplicity と似ていますが、Duplicity とは異なり、ほとんどの機能はサードパーティのツールなしで利用できます。 これがプラスになるかマイナスになるかは具体的なケースによって異なりますが、初心者にとっては、Python のパッケージをそのまま追加でインストールするよりも、すべての機能のリストを一度に確認できる方が簡単である可能性が高くなります。二重性のあるケース。

もう XNUMX つの小さなニュアンス - プログラムは、バックアップを開始するユーザーに代わってローカル sqlite データベースをアクティブに書き込むため、cli を使用してプロセスを開始するたびに、必要なデータベースが正しく指定されていることをさらに確認する必要があります。 GUI または WEBGUI を使用して作業する場合、詳細はユーザーには表示されません。

このソリューションがどのような指標を生成できるかを見てみましょう。

暗号化をオフにすると (WEBGUI ではこれを推奨しません)、結果は次のようになります。

営業時間：

ラン1
ラン2
ラン3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

暗号化を有効にし、aes を使用すると、次のようになります。

営業時間：

ラン1
ラン2
ラン3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

外部プログラム gnupg を使用すると、次の結果が得られます。

ラン1
ラン2
ラン3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

ご覧のとおり、プログラムは複数のスレッドで動作できますが、これによってソリューションの生産性が向上するわけではありません。暗号化作業を比較すると、外部プログラムを起動していることになります。
Mono セットのライブラリを使用するよりも高速であることが判明しました。 これは、外部プログラムがより最適化されていることが原因である可能性があります。

もう XNUMX つの優れた点は、リポジトリのサイズが実際に変更されたデータとまったく同じ大きさであるという事実です。 duplicati はディレクトリ名の変更を検出し、この状況を正しく処理しました。 これは、XNUMX 番目のテストを実行すると確認できます。

全体として、初心者に対してかなりフレンドリーであることを含め、プログラムに対してかなり肯定的な印象がありました。

結果

どちらの候補も作業はかなり遅かったですが、一般的に、通常の tar と比較して、少なくとも duplicati については進歩がありました。 このような進歩の代償も明らかであり、顕著な負担となる
プロセッサー。 一般に、結果の予測に特別な逸脱はありません。

所見

どこにも急ぐ必要がなく、予備のプロセッサーがある場合は、検討されている解決策のいずれかで十分です。いずれにせよ、tar 上にラッパー スクリプトを作成して繰り返すべきではないかなりの作業が行われています。 。 バックアップ コピーを保存するサーバーが完全に信頼できない場合、暗号化の存在は非常に必要なプロパティです。

ソリューションベースとの比較 rsync - 純粋な形式の tar は rsync より 20 ～ 30% 高速に動作するにもかかわらず、パフォーマンスは数倍悪くなる可能性があります。
リポジトリのサイズは節約されますが、それは重複した場合のみです。

お知らせ

バックアップ、パート 1: バックアップが必要な理由、方法、テクノロジの概要
バックアップ パート 2: rsync ベースのバックアップ ツールのレビューとテスト
バックアップ パート 3: 重複性、重複性、デジャ デュップのレビューとテスト
バックアップ パート 4: zbackup、restic、borgbackup のレビューとテスト
バックアップ パート 5: Linux 用の bacula および veeam バックアップのテスト
バックアップ パート 6: バックアップ ツールの比較
バックアップ パート 7: 結論

投稿者： パベル・デムコビッチ

出所： habr.com