バックアップ パート 4: zbackup、restic、borgbackup のレビューとテスト

この記事では、データ ストリームを個別のコンポーネント (チャンク) に分割してリポジトリを形成するバックアップ ソフトウェアについて検討します。

リポジトリ コンポーネントはさらに圧縮および暗号化でき、最も重要なことは、繰り返しのバックアップ プロセス中に再利用できることです。

このようなリポジトリ内のバックアップ コピーは、たとえばさまざまなハッシュ関数に基づいて相互に接続されたコンポーネントの名前付きチェーンです。

同様のソリューションがいくつかありますが、ここでは 3 つである zbackup、borgbackup、restic に焦点を当てます。

期待される結果

すべての申請者は何らかの方法でリポジトリの作成を必要とするため、最も重要な要素の 13 つはリポジトリのサイズを見積もることになります。理想的には、そのサイズは、受け入れられている方法論に従えば XNUMX GB 以下である必要があり、適切な最適化が行われた場合にはそれ以下である必要があります。

また、tar などのアーカイバを使用せずにファイルのバックアップ コピーを直接作成できることや、rsync や sshfs などの追加ツールなしで ssh/sftp を操作できることも非常に望ましいです。

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

1. リポジトリのサイズは、変更のサイズと同じかそれ以下になります。
2. 圧縮や暗号化を使用する場合は CPU の負荷が高くなることが予想され、アーカイブや暗号化のプロセスがバックアップ ストレージ サーバーで実行されている場合は、ネットワークとディスクの負荷が非常に高くなる可能性があります。
3. リポジトリが破損している場合、新しいバックアップの作成時と復元の試行時に遅延エラーが発生する可能性があります。リポジトリの整合性を確保するための追加の対策を計画するか、整合性をチェックするための組み込みツールを使用する必要があります。

以前の記事の 1 つで示したように、tar の操作は参考値として使用されます。

zbackup のテスト

zbackup の一般的なメカニズムは、プログラムが入力データ ストリーム内で同じデータを含む領域を見つけ、オプションでそれらを圧縮および暗号化し、各領域を 1 回だけ保存するというものです。

重複排除では、スライディング ウィンドウを備えた 64 ビット リング ハッシュ関数を使用して、既存のデータ ブロックとのバイト単位の一致をチェックします (rsync の実装方法と同様)。

マルチスレッドの lzma および lzo が圧縮に使用され、aes が暗号化に使用されます。最新バージョンには、将来リポジトリから古いデータを削除する機能があります。
プログラムは最小限の依存関係で C++ で書かれています。作者は明らかに unix 方式に触発されているため、プログラムはバックアップの作成時に stdin 上のデータを受け入れ、復元時に stdout 上に同様のデータ ストリームを生成します。したがって、zbackup は、独自のバックアップ ソリューションを作成するときに非常に優れた「構成要素」として使用できます。たとえば、この記事の著者は、2014 年頃からこのプログラムを家庭用マシンのメインのバックアップ ツールとして使用しています。

特に指定がない限り、データ ストリームは通常の tar になります。

結果を見てみましょう:

作業は 2 つのオプションでチェックされました。

1. リポジトリが作成され、ソース データを含むサーバー上で zbackup が起動され、リポジトリの内容がバックアップ ストレージ サーバーに転送されます。
2. リポジトリがバックアップ ストレージ サーバー上に作成され、zbackup がバックアップ ストレージ サーバー上で ssh 経由で起動され、データがパイプ経由でそこに送信されます。

最初のオプションの結果は次のとおりです。暗号化されていないリポジトリと lzma コンプレッサーを使用する場合は 43 分 11 秒、コンプレッサーを lzo に置き換える場合は 19 分 13 秒です。

元のデータによるサーバーの負荷は次のとおりです (lzma を使用した例が示されています。lzo の場合もほぼ同じ状況でしたが、rsync のシェアは約 4 分の 1 でした)。

このようなバックアップ プロセスが、比較的まれで小規模な変更にのみ適していることは明らかです。また、zbackup を 1 スレッドに制限することを強くお勧めします。そうしないと、CPU 負荷が非常に高くなります。このプログラムは、複数のスレッドでの作業に非常に優れています。ディスクの負荷は小さく、一般に、最新の SSD ベースのディスク サブシステムでは顕著ではありません。また、リポジトリ データをリモート サーバーに同期するプロセスの開始を明確に確認できます。操作速度は通常の rsync と同等で、バックアップ ストレージ サーバーのディスク サブシステムのパフォーマンスに依存します。このアプローチの欠点は、ローカル リポジトリに保存されることになり、その結果、データが重複することです。

より興味深く、実際に適用できるのは、バックアップ ストレージ サーバー上で zbackup を直接実行する 2 番目のオプションです。

まず、lzma コンプレッサーを使用して暗号化を使用せずに操作をテストします。

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

ラン1
ラン2
ラン3

39m45s
40m20s
40m3s

7m36s
8m3s
7m48s

15m35s
15m48s
15m38s

aes を使用して暗号化を有効にすると、結果はほぼ同じになります。

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

ラン1
ラン2
ラン3

43m40s
44m12s
44m3s

8m3s
8m15s
8m12s

15m0s
15m40s
15m25s

暗号化と lzo を使用した圧縮を組み合わせると、次のようになります。

営業時間：

ラン1
ラン2
ラン3

18m2s
18m15s
18m12s

5m13s
5m24s
5m20s

8m48s
9m3s
8m51s

結果のリポジトリのサイズは 13GB で比較的同じでした。これは、重複排除が正しく機能していることを意味します。また、すでに圧縮されたデータでは、lzo を使用すると顕著な効果が得られます。合計動作時間の観点から見ると、zbackup は重複性/重複性に近づきますが、librsync に基づくものよりも 2 ～ 5 倍遅れます。

利点は明白で、バックアップ ストレージ サーバーのディスク領域を節約できます。リポジトリ チェック ツールに関しては、zbackup の作成者は提供していません。フォールト トレラントなディスク アレイまたはクラウド プロバイダーを使用することをお勧めします。

プロジェクトが約 3 年間停止していたにもかかわらず、全体的には非常に良い印象でした (最後の機能リクエストは約 XNUMX 年前でしたが、返答はありませんでした)。

ボーグバックアップのテスト

Borgbackup は attic のフォークであり、zbackup に似た別のシステムです。 Python で書かれており、zbackup と同様の機能リストを備えていますが、さらに次のことができます。

• ヒューズ経由でバックアップをマウントする
• リポジトリの内容を確認する
• クライアントサーバーモードで作業する
• データのさまざまな圧縮プログラムを使用するだけでなく、圧縮時にファイル タイプをヒューリスティックに決定します。
• 2 つの暗号化オプション、aes と blake
• 内蔵ツール

パフォーマンスチェック

borgbackup ベンチマーク crud ssh://backup_server/repo/path local_dir

結果は次のとおりでした。

C-Z-BIG 96.51 MB/秒 (10 100.00 MB オールゼロ ファイル: 10.36 秒)
R-Z-BIG 57.22 MB/秒 (10 100.00 MB オールゼロ ファイル: 17.48 秒)
U-Z-BIG 253.63 MB/秒 (10 100.00 MB オールゼロ ファイル: 3.94 秒)
D-Z-BIG 351.06 MB/秒 (10 100.00 MB オールゼロ ファイル: 2.85 秒)
C-R-BIG 34.30 MB/秒 (10 100.00 MB ランダム ファイル: 29.15 秒)
R-R-BIG 60.69 MB/秒 (10 100.00 MB ランダム ファイル: 16.48 秒)
U-R-BIG 311.06 MB/秒 (10 100.00 MB ランダム ファイル: 3.21 秒)
D-R-BIG 72.63 MB/秒 (10 100.00 MB ランダム ファイル: 13.77 秒)
C-Z-MEDIUM 108.59 MB/秒 (1000 1.00 MB オールゼロ ファイル: 9.21 秒)
R-Z-MEDIUM 76.16 MB/秒 (1000 1.00 MB オールゼロ ファイル: 13.13 秒)
U-Z-MEDIUM 331.27 MB/秒 (1000 1.00 MB オールゼロ ファイル: 3.02 秒)
D-Z-MEDIUM 387.36 MB/秒 (1000 1.00 MB オールゼロ ファイル: 2.58 秒)
C-R-MEDIUM 37.80 MB/秒 (1000 1.00 MB ランダム ファイル: 26.45 秒)
R-R-MEDIUM 68.90 MB/秒 (1000 1.00 MB ランダム ファイル: 14.51 秒)
U-R-MEDIUM 347.24 MB/秒 (1000 1.00 MB ランダム ファイル: 2.88 秒)
D-R-MEDIUM 48.80 MB/秒 (1000 1.00 MB ランダム ファイル: 20.49 秒)
C-Z-SMALL 11.72 MB/秒 (10000 10.00 KB オールゼロ ファイル: 8.53 秒)
R-Z-SMALL 32.57 MB/秒 (10000 10.00 KB オールゼロ ファイル: 3.07 秒)
U-Z-SMALL 19.37 MB/秒 (10000 10.00 KB オールゼロ ファイル: 5.16 秒)
D-Z-SMALL 33.71 MB/秒 (10000 10.00 KB オールゼロ ファイル: 2.97 秒)
C-R-SMALL 6.85 MB/秒 (10000 10.00 KB ランダム ファイル: 14.60 秒)
R-R-SMALL 31.27 MB/秒 (10000 10.00 KB ランダム ファイル: 3.20 秒)
U-R-SMALL 12.28 MB/秒 (10000 10.00 KB ランダム ファイル: 8.14 秒)
D-R-SMALL 18.78 MB/秒 (10000 10.00 KB ランダム ファイル: 5.32 秒)

テスト時には、圧縮ヒューリスティックを使用してファイル タイプ (自動圧縮) が決定され、結果は次のようになります。

まず、暗号化なしでどのように動作するかを確認してみましょう。

営業時間：

ラン1
ラン2
ラン3

4m6s
4m10s
4m5s

56s
58s
54s

1m26s
1m34s
1m30s

リポジトリの認可 (認証モード) を有効にすると、結果は次のようになります。

営業時間：

ラン1
ラン2
ラン3

4m11s
4m20s
4m12s

1m0s
1m3s
1m2s

1m30s
1m34s
1m31s

aes 暗号化を有効にしても、結果はそれほど劣化しませんでした。

ラン1
ラン2
ラン3

4m55s
5m2s
4m58s

1m0s
1m2s
1m0s

1m49s
1m50s
1m50s

そして、aes を blake に変更すると、状況は完全に改善されます。

営業時間：

ラン1
ラン2
ラン3

4m33s
4m43s
4m40s

59s
1m0s
1m0s

1m38s
1m43s
1m40s

zbackup の場合と同様に、リポジトリ サイズは 13 GB で、一般的に予想される値よりもさらに小さくなりました。実行時間には非常に満足しており、librsync ベースのソリューションに匹敵し、より広範な機能を提供します。また、環境変数を通じてさまざまなパラメータを設定できる機能にも満足しました。これは、borgbackup を自動モードで使用するときに非常に大きな利点をもたらします。バックアップ中の負荷にも満足しています。プロセッサの負荷から判断すると、borgbackup は 1 スレッドで動作します。

使用してみて特にデメリットはありませんでした。

レストティックテスト

Retic はかなり新しいソリューションであるという事実にもかかわらず (最初の 2 つの候補は 2013 年以前に知られていました)、非常に優れた特性を備えています。 Goで書かれています。

zbackup と比較すると、さらに次のような利点があります。

• リポジトリの整合性をチェックします (パーツのチェックインを含む)。
• バックアップを保存するためにサポートされているプロトコルとプロバイダーの膨大なリスト、およびクラウド ソリューション用の rclone - rsync のサポート。
• 2 つのバックアップを相互に比較します。
• ヒューズを介してリポジトリをマウントします。

一般に、機能のリストは borgbackup に非常に近く、場所によってはそれよりも多く、また別の場所ではそれより少なくなります。特徴の 1 つは、暗号化を無効にする方法がないため、バックアップ コピーは常に暗号化されることです。このソフトウェアから何が絞り出せるかを実際に見てみましょう。

結果は次のとおりでした。

営業時間：

ラン1
ラン2
ラン3

5m25s
5m50s
5m38s

35s
38s
36s

1m54s
2m2s
1m58s

パフォーマンスの結果も rsync ベースのソリューションと同等であり、一般に borgbackup に非常に近いですが、CPU 負荷が高く (複数のスレッドが実行されている)、ノコギリ波のようになります。

おそらく、rsync の場合と同様に、プログラムはデータ ストレージ サーバー上のディスク サブシステムのパフォーマンスによって制限されます。リポジトリのサイズは 13GB で、zbackup や borgbackup と同様に、このソリューションを使用しても明らかな欠点はありませんでした。

結果

実際、すべての候補者は同様の結果を達成しましたが、価格は異なりました。 Borgbackup は最高のパフォーマンスを発揮しましたが、Restic は少し遅かったです。zbackup はおそらく使い始める価値がありません。
すでに使用されている場合は、borgbackup またはrestic に変更してみてください。

所見

最も有望な解決策は、restic であると思われます。能力と動作速度の比率が最も優れているのは彼ですが、今は一般的な結論を急ぐのはやめましょう。

Borgbackup も基本的には悪くありませんが、おそらく zbackup を置き換えた方がよいでしょう。確かに、3-2-1 ルールが機能することを確認するために zbackup を使用することはできます。たとえば、(lib)rsync ベースのバックアップ機能に加えて。

お知らせ

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

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

出所： habr.com