バックアップ パート 6: バックアップ ツールの比較

この記事ではバックアップ ツールを比較しますが、まずバックアップからのデータの復元がどのくらい迅速かつ適切に行われるかを確認する必要があります。
比較を容易にするために、特にすべての候補がこの操作モードをサポートしているため、完全バックアップからの復元を検討します。 簡単にするために、数値はすでに平均化されています (複数回の実行の算術平均)。 結果は表にまとめられます。この表には、Web インターフェイスの存在、セットアップと操作の容易さ、自動化機能、さまざまな追加機能の存在 (データ整合性のチェックなど) などの機能に関する情報も含まれます。 、など。 グラフには、データが使用されるサーバー (バックアップ コピーを保存するサーバーではありません) の負荷が表示されます。

データ復旧

rsync と tar は参照ポイントとして使用されます。 それらは通常それらに基づいています バックアップコピーを作成するための簡単なスクリプト。

Rsync 4分28秒でテストデータセットに対処し、

そんな負荷

回復プロセスがバックアップ ストレージ サーバーのディスク サブシステムの制限に達しました (のこぎり波グラフ)。 また、XNUMX つのカーネルが問題なくロードされていることがはっきりとわかります (iowait と Softirq が低く、それぞれディスクとネットワークに問題はありません)。 他の XNUMX つのプログラム、つまり rdiff-backup と rsnapshot は rsync に基づいており、回復ツールとして通常の rsync も提供するため、負荷プロファイルとバックアップ回復時間はほぼ同じになります。

タール 少し早くできました

2分43秒:

SoftIRQ の増加により、システム全体の負荷が平均 20% 増加しました。これにより、ネットワーク サブシステムの動作中のオーバーヘッド コストが増加しました。

アーカイブがさらに圧縮されると、回復時間は 3 分 19 秒に増加します。
メインサーバーにそのような負荷がかかる場合 (メインサーバー側で解凍):

3 つのプロセスが実行されているため、解凍プロセスは両方のプロセッサ コアを消費します。 一般に、これは予想される結果です。 また、バックアップを使用してサーバー側で gzip を実行すると、同等の結果 (20 分 XNUMX 秒) が得られました。メイン サーバーでの負荷プロファイルは、gzip コンプレッサーを使用せずに tar を実行した場合と非常に似ていました (前のグラフを参照)。

В rdiff-バックアップ 通常の rsync を使用して作成した最後のバックアップを同期できます (結果は同様になります)。ただし、古いバックアップは rdiff-backup プログラムを使用して復元する必要があり、復元は 17 分 17 秒で完了しました。

この負荷:

おそらくこれは、少なくとも著者の速度を制限することを意図したものでした。 そのような解決策を提案します。 バックアップ コピーを復元するプロセス自体は 2 コアの半分よりわずかに少なく、rsync を使用するとディスクやネットワークと比例して同等のパフォーマンス (つまり 5 ～ XNUMX 倍遅い) が得られます。

Rスナップショット 回復には通常の rsync を使用することを推奨しているため、結果は同様になります。 一般的に、このようになりました。

げっぷ バックアップを復元するタスクを 7 分 2 秒で完了しました。
この負荷では:

これは非常に高速に動作し、少なくとも純粋な rsync よりもはるかに便利です。フラグを覚える必要がなく、シンプルで直感的な cli インターフェイス、複数のコピーのサポートが組み込まれていますが、XNUMX 倍遅いです。 最後に作成したバックアップからデータを復元する必要がある場合は、rsync を使用できますが、いくつかの注意点があります。

プログラムはほぼ同じ速度と負荷を示しました バックアップPC rsync 転送モードを有効にする場合、バックアップをデプロイする

7分42秒:

しかし、データ転送モードでは、BackupPC は tar に対処するのが遅くなり、12 分 15 秒で、プロセッサの負荷は全体的に低くなりました。

XNUMX回半：

二枚舌 暗号化を行わない場合はわずかに良い結果が得られ、10 分 58 秒でバックアップが復元されました。 GPG を使用して暗号化を有効にすると、回復時間は 15 分 3 秒に増加します。 また、コピーを保存するためのリポジトリを作成するときに、受信データ ストリームを分割するときに使用されるアーカイブ サイズを指定できます。 一般に、従来のハードドライブでは、シングルスレッド動作モードのため、大きな違いはありません。 ハイブリッド ストレージが使用されている場合、異なるブロック サイズで表示される場合があります。 復旧時のメインサーバーの負荷は以下のとおりでした。

暗号化なし

暗号化あり

複製 は同等の回復率を示し、13 分 45 秒で完了しました。 復元したデータが正しいかどうかを確認するのにさらに約 5 分かかりました (合計約 19 分)。 負荷は

かなり高い：

aes 暗号化が内部で有効になっている場合、回復時間は 21 分 40 秒で、回復中の CPU 使用率は最大 (両方のコア!) でした。 データをチェックすると、5 つのスレッドのみがアクティブになり、27 つのプロセッサ コアを占有していました。 リカバリ後のデータの確認には同じ XNUMX 分かかりました (合計で約 XNUMX 分)。

結果

暗号化に外部 gpg プログラムを使用すると、duplicati の回復が少し速くなりましたが、一般に、以前のモードとの違いは最小限です。 操作時間は 16 分 30 秒、データ検証は 6 分で完了しました。 負荷は

そのような：

AMANDAtar を使用すると、原理的には通常の tar に非常に近い 2 分 49 秒で完了しました。 原則としてシステムに負荷がかかる

同じ：

を使用してバックアップを復元する場合 zbackup 次の結果が得られました。

暗号化、lzma 圧縮

上映時間 11分8秒

AES暗号化、lzma圧縮

稼働時間 14分

AES暗号化、lzo圧縮

上映時間 6分19秒

全体的には悪くありません。 すべてはバックアップ サーバーのプロセッサの速度に依存します。これは、さまざまなコンプレッサーを使用したプログラムの実行時間から明らかです。 バックアップサーバー側では通常のtarが起動したので、それと比較すると復旧が3倍遅くなります。 XNUMX つ以上のスレッドを使用したマルチスレッド モードでの動作を確認するとよいでしょう。

ボーグバックアップ 非暗号化モードでは tar より少し遅く、2 分 45 秒でしたが、tar とは異なり、リポジトリの重複排除が可能になりました。 負荷は次のようになりました。

次の

ブレークベースの暗号化を有効にすると、バックアップの回復速度が若干遅くなります。 このモードでの回復時間は 3 分 19 秒で、負荷はなくなります。

このような：

AES暗号化は若干遅く、回復時間は3分23秒、特に負荷が高い

変わっていない：

Borg はマルチスレッド モードで動作できるため、プロセッサの負荷は最大になり、追加機能がアクティブになると動作時間は単純に増加します。 どうやら、zbackup と同様の方法でマルチスレッドを検討する価値があるようです。

レスティック 回復が少し遅くなり、稼働時間は4分28秒でした。 負荷は次のようになりました

次のように：

明らかに、回復プロセスは複数のスレッドで動作しますが、その効率は BorgBackup ほど高くはありませんが、時間的には通常の rsync に匹敵します。

ととも​​に urBackup 負荷は8分19秒でデータを復元できました

そのような：

負荷はまだそれほど高くはなく、タールの負荷よりもさらに低いです。 場所によってはバーストが発生しますが、XNUMX つのコアの負荷を超えることはありません。

比較基準の選択と正当化

以前の記事のいずれかで述べたように、バックアップ システムは次の基準を満たしている必要があります。

• 使いやすさ
• 普遍主義
• 安定性
• スピード

それぞれの点を個別にさらに詳細に検討する価値があります。

操作性の良さ

「すべてをうまく実行する」ボタンが XNUMX つある場合が最適ですが、実際のプログラムに戻ると、最も便利なのは、使い慣れた標準的な動作原理になるでしょう。
ほとんどのユーザーは、CLI の大量のキーを覚えたり、Web や tui 経由でさまざまな、よくわかりにくいオプションを設定したり、失敗した操作に関する通知を設定したりする必要がなければ、おそらくその方が良いでしょう。 これには、バックアップ ソリューションを既存のインフラストラクチャに簡単に「適合」させる機能や、バックアップ プロセスの自動化も含まれます。 パッケージ マネージャーを使用してインストールすることも、「ダウンロードして解凍する」などの XNUMX つまたは XNUMX つのコマンドでインストールすることもできます。 curl ссылка | sudo bash - リンク経由で何が到着するかを確認する必要があるため、複雑な方法です。

たとえば、検討された候補のうち、簡単な解決策は、さまざまな動作モードに対応するニーモニック キーを持つ burp、rdiff-backup、restic です。 もう少し複雑なのは、borg と duplicity です。 一番難しかったのはアマンダでした。 残りは使いやすさの点で中間くらいです。 いずれにせよ、ユーザーマニュアルを読むのに 30 秒以上かかる場合、または Google または別の検索エンジンにアクセスし、さらに長いヘルプシートをスクロールする必要がある場合、どちらにせよ決断は困難です。

検討されている候補の中には、e-mailjabber 経由でメッセージを自動的に送信できるものもあれば、システムに設定されたアラートに依存するものもあります。 さらに、ほとんどの場合、複雑なソリューションには完全に明確なアラート設定がありません。 いずれの場合でも、バックアップ プログラムがゼロ以外のリターン コードを生成し、それが定期タスクのシステム サービスによって正しく理解される場合 (メッセージがシステム管理者または監視に直接送信されます)、状況は単純です。 しかし、バックアップ サーバー上で実行されないバックアップ システムを構成できない場合は、問題がすでに過度に複雑になっていることが明らかです。 いずれの場合でも、警告やその他のメッセージを Web インターフェイスまたはログにのみ発行することは、ほとんどの場合無視されるため、悪い習慣です。

自動化に関しては、単純なプログラムで動作モードを設定する環境変数を読み取ることができます。また、Web インターフェイスを介して作業するときの動作を完全に再現できる開発された CLI を備えています。 これには、継続的な運用の可能性、拡張機会の利用可能性なども含まれます。

普遍主義

自動化に関する前のサブセクションを部分的に繰り返しますが、バックアップ プロセスを既存のインフラストラクチャに「適合」させることは特に問題ではありません。
非標準のポート (Web インターフェイスを除く) を仕事で使用すること、非標準の方法で暗号化を実装すること、非標準のプロトコルを使用してデータを交換することは、非標準の兆候であることは注目に値します。 -ユニバーサルソリューション。 ほとんどの場合、すべての候補者が何らかの形でそれらを持っていますが、その理由は明白です。単純さと汎用性は通常両立しないからです。 例外として、げっぷ、他にもあります。

その兆候として、通常の SSH を使用して動作できることが挙げられます。

作業スピード

最も物議を醸し、物議を醸すポイント。 一方で、私たちはプロセスを開始しましたが、可能な限り迅速に機能し、主要なタスクを妨げることはありませんでした。 一方、バックアップ期間中はトラフィックとプロセッサの負荷が急増します。 また、コピーを作成するための最速のプログラムは、通常、ユーザーにとって重要な機能に関しては最も貧弱であることにも注意してください。 繰り返しますが、パスワード付きのサイズが数十バイトの残念なテキスト ファイルを XNUMX つ取得するために、そのためにサービス全体の費用がかかる場合 (はい、はい、ほとんどの場合、バックアップ プロセスのせいではないことは理解しています)、そして、リポジトリ内のすべてのファイルを順番に再読み取るか、アーカイブ全体を展開する必要があります。バックアップ システムは決して高速ではありません。 しばしば障害となるもう XNUMX つの点は、アーカイブからのバックアップの展開の速度です。 ここには、多くの操作を行わずにファイルを目的の場所にコピーまたは移動するだけ（たとえば、rsync）できるユーザーには明らかな利点がありますが（rsync など）、ほとんどの場合、問題は組織的な方法で経験的に解決する必要があります。つまり、バックアップの回復時間を測定することです。そしてこれについてユーザーに公然と通知します。

安定性

これは次のように理解する必要があります。一方で、バックアップ コピーはどのような方法でも展開できなければなりませんが、他方では、ネットワークの中断、ディスク障害、ファイルの一部の削除など、さまざまな問題に耐性がなければなりません。リポジトリ。

バックアップツールの比較

コピー作成時間
コピーの回復時間
簡単インストール
簡単なセットアップ
使いやすい
シンプルな自動化
クライアントサーバーが必要ですか?
リポジトリの整合性をチェックする
差分コピー
パイプを介して作業する
普遍主義
独立
リポジトリの透明性
Шифрование
圧縮
重複排除
ウェブインターフェース
クラウドへの充填
Windowsのサポート
マーク

Rsync
4m15s
4m28s
はい
ノー
ノー
ノー
はい
ノー
ノー
はい
ノー
はい
はい
ノー
ノー
ノー
ノー
ノー
はい
6

タール
純粋な
3m12s
2m43s
はい
ノー
ノー
ノー
ノー
ノー
はい
はい
ノー
はい
ノー
ノー
ノー
ノー
ノー
ノー
はい
8,5

gzip
9m37s
3m19s
はい

Rdiffバックアップ
16m26s
17m17s
はい
はい
はい
はい
はい
ノー
はい
ノー
はい
ノー
はい
ノー
はい
はい
はい
ノー
はい
11

Rスナップショット
4m19s
4m28s
はい
はい
はい
はい
ノー
ノー
はい
ノー
はい
ノー
はい
ノー
ノー
はい
はい
ノー
はい
12,5

げっぷ
11m9s
7m2s
はい
ノー
はい
はい
はい
はい
はい
ノー
はい
はい
ノー
ノー
はい
ノー
はい
ノー
はい
10,5

二枚舌
暗号化なし
16m48s
10m58s
はい
はい
ノー
はい
ノー
はい
はい
ノー
ノー
はい
ノー
はい
はい
ノー
はい
ノー
はい
11

gpg
17m27s
15m3s

複製
暗号化なし
20m28s
13m45s
ノー
はい
ノー
ノー
ノー
はい
はい
ノー
ノー
はい
ノー
はい
はい
はい
はい
はい
はい
11

エース
29m41s
21m40s

gpg
26m19s
16m30s

Zバックアップ
暗号化なし
40m3s
11m8s
はい
はい
ノー
ノー
ノー
はい
はい
はい
ノー
はい
ノー
はい
はい
はい
ノー
ノー
ノー
10

エース
42m0s
14m1s

aes+lzo
18m9s
6m19s

ボーグバックアップ
暗号化なし
4m7s
2m45s
はい
はい
はい
はい
はい
はい
はい
はい
はい
はい
ノー
はい
はい
はい
はい
ノー
はい
16

エース
4m58s
3m23s

blake2
4m39s
3m19s

レスティック
5m38s
4m28s
はい
はい
はい
はい
ノー
はい
はい
はい
はい
はい
ノー
はい
ノー
はい
ノー
はい
はい
15,5

urBackup
8m21s
8m19s
はい
はい
はい
ノー
はい
ノー
はい
ノー
はい
はい
ノー
はい
はい
はい
はい
ノー
はい
12

アマンダ
9m3s
2m49s
はい
ノー
ノー
はい
はい
はい
はい
ノー
はい
はい
はい
はい
はい
ノー
はい
はい
はい
13

バックアップPC
rsync
12m22s
7m42s
はい
ノー
はい
はい
はい
はい
はい
ノー
はい
ノー
ノー
はい
はい
ノー
はい
ノー
はい
10,5

tar
12m34s
12m15s

表の凡例:

• 緑色、稼働時間が 1 分未満、または「はい」と回答 (「クライアントサーバーが必要ですか?」の欄を除く)、XNUMX ポイント
• 黄色、動作時間 0.5 ～ XNUMX 分、XNUMX ポイント
• 赤、作業時間が 0 分を超える、または答えが「いいえ」（「クライアント サーバーは必要ですか?」の欄を除く）、XNUMX ポイント

上の表によると、最もシンプルで最速、そして同時に便利で強力なバックアップ ツールは BorgBackup です。 Restic が XNUMX 位となり、検討された残りの候補者は最終的に XNUMX ～ XNUMX ポイントの差でほぼ均等に順位が決まりました。

このシリーズを最後まで読んでくださった皆さんに感謝します。オプションについて話し合って、もしあれば独自のオプションを提案してください。 議論が進むにつれて、テーブルが拡大される可能性があります。

このシリーズの結果が最終記事となります。この記事では、コピーを最短時間で展開できると同時に便利で簡単な、高速で管理しやすい理想的なバックアップ ツールを開発する試みが行われます。設定と保守を行います。

お知らせ

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

出所： habr.com