バックアップ、パート 1: 目的、方法とテクノロジのレビュー

なぜバックアップを作成する必要があるのですか? 結局のところ、この機器は非常に信頼性が高く、さらに、物理サーバーよりも信頼性の高い「クラウド」が存在します。適切な構成があれば、「クラウド」サーバーはインフラストラクチャの物理サーバーの障害にも簡単に耐えることができます。サービス ユーザーの観点からは、サービス時間に小さな、ほとんど目立たない程度のジャンプが発生します。 さらに、情報を複製すると、多くの場合、「余分な」プロセッサ時間、ディスク負荷、ネットワーク トラフィックの支払いが必要になります。

理想的なプログラムは高速に実行され、メモリ リークがなく、ホールがなく、存在しません。

-未知

プログラムは依然としてプロテイン開発者によって書かれており、多くの場合テストプロセスが存在せず、さらにプログラムが「ベストプラクティス」（それ自体もプログラムであるため不完全です）を使用して提供されることはほとんどないため、システム管理者はほとんどの場合、簡単に聞こえるが、簡潔に言うと、「元の状態に戻す」、「ベースを通常の動作に戻す」、「動作が遅い - ロールバックする」、そして私のお気に入りの「何かは分からないが、修正する」も含まれます。

開発者の不注意な作業や状況の組み合わせの結果として発生する論理エラーに加えて、接続やシステム機能 (オペレーティング システム、ドライバー、ファームウェアなど) を構築するプログラムの小さな機能に関する不完全な知識や誤解も含まれます。他にもエラーがあります。 たとえば、ほとんどの開発者はランタイムに依存しており、プログラムを使用して回避することが依然として不可能である物理法則については完全に忘れています。 これには、ディスク サブシステムと、一般にあらゆるデータ ストレージ サブシステム (RAM やプロセッサ キャッシュを含む!) の無限の信頼性、プロセッサでの処理時間がゼロであること、ネットワーク経由の送信中およびプロセッサ上での処理中にエラーがないことが含まれます。悪名高い期限を無視してはなりません。期限に間に合わないと、ネットワークやディスクの操作の微妙な違いよりもさらに深刻な問題が発生する可能性があるからです。

本格的に発生し、貴重なデータに影響を与える問題にどう対処すればよいでしょうか? 生きている開発者に代わるものは何もありませんし、それが近い将来に可能になるということも事実ではありません。 一方で、プログラムが意図したとおりに機能することを完全に証明することに成功したプロジェクトはわずかであり、その証拠を他の同様のプロジェクトに適用できるとは限りません。 また、こうした証拠には多大な時間がかかり、特別なスキルや知識が必要となるため、期限を考慮すると証拠が利用できる可能性は事実上最小限に抑えられます。 さらに、情報を保存、処理、送信するための超高速、安価、そして限りなく信頼性の高いテクノロジーを使用する方法もまだわかっていません。 そのようなテクノロジーは、存在するとしても、概念の形で存在するか、ほとんどの場合、SF の本や映画の中でのみ存在します。

優れたアーティストはコピーし、優れたアーティストは盗む。

-パブロ・ピカソ。

最も成功したソリューションや驚くほどシンプルなことは、通常、一見すると絶対に相容れない概念、技術、知識、科学分野が出会う場所で起こります。

たとえば、鳥や飛行機には翼がありますが、機能的な類似性にもかかわらず、いくつかのモードでの動作原理は同じであり、技術的問題は中空の骨、強くて軽量な素材の使用など、同様の方法で解決されます。結果は非常に似ていますが、まったく異なります。 私たちの技術で見られる最良の例も、主に自然から借用したものです。船や潜水艦の加圧区画は、環形動物と直接類似しています。 RAID アレイの構築とデータの整合性のチェック - DNA チェーンの複製。 同様に、対になった器官、中枢神経系からのさまざまな器官の働きの独立性（心臓の自動化）、および反射 - インターネット上の自律システム。 もちろん、既成のソリューションを「真正面から」取り入れて適用することには問題が伴いますが、おそらく他に解決策はないのかもしれません。

あなたがどこに落ちるか知っていたら、わらを敷いていたのに！

—ベラルーシの民間のことわざ

つまり、次のことを行う場合には、バックアップ コピーが不可欠です。

• 最小限のダウンタイムで、またはまったくダウンタイムを発生させずにシステムの動作を復元できる
• エラーが発生した場合は常にロールバックの可能性があるため、大胆に行動してください。
• 意図的なデータ破損の影響を最小限に抑える

ここでちょっとした理論をご紹介します

分類は任意です。 自然は分類しません。 分類するのは、そのほうが私たちにとって便利だからです。 そして、これも任意に取得したデータに従って分類します。

—ジャン・ブルーラー

物理的なストレージ方法に関係なく、論理的なデータ ストレージは、このデータにアクセスする 2 つの方法 (ブロックとファイル) に分けることができます。 純粋なファイルだけでなく、純粋なブロックの論理ストレージも存在しないため、この区分は最近非常に曖昧になってきています。 ただし、簡単にするために、それらが存在すると仮定します。

ブロック データ ストレージは、データが特定の固定部分、ブロックに書き込まれる物理デバイスが存在することを意味します。 ブロックは特定のアドレスでアクセスされ、各ブロックはデバイス内で独自のアドレスを持ちます。

バックアップは通常、データのブロックをコピーすることによって作成されます。 データの整合性を確保するために、新しいブロックの記録と既存のブロックへの変更はコピー時に一時停止されます。 通常の世界から類推すると、同じ番号のセルが入ったクローゼットが最も近いものになります。

論理デバイスの原則に基づくファイル データ ストレージはブロック ストレージに近く、多くの場合、その上に編成されます。 重要な違いは、ストレージ階層の存在と人間が判読できる名前です。 抽象化は、ファイル (名前付きデータ領域)、およびディレクトリ (説明と他のファイルへのアクセスが保存される特別なファイル) の形式で割り当てられます。 ファイルには、作成時間、アクセスフラグなどの追加のメタデータを指定できます。 バックアップは通常、次の方法で行われます。変更されたファイルを検索し、同じ構造を持つ別のファイル ストレージにコピーします。 データの整合性は通常、ファイルが書き込まれないことによって実装されます。 ファイルのメタデータも同様にバックアップされます。 最も近い例は図書館です。図書館にはさまざまな書籍が置かれたセクションがあり、人間が読める書籍名が記載されたカタログもあります。

最近では、原理的にはファイル データ ストレージが始まり、同じ古い機能を持つオブジェクト データ ストレージという別のオプションが説明されることもあります。

ファイル ストレージとは異なり、複数のネスト (フラット スキーム) がなく、ファイル名は人間が判読できるものの、マシンによる処理に適しています。 バックアップを実行する場合、オブジェクト ストレージはファイル ストレージと同様に扱われることがほとんどですが、他のオプションが存在する場合もあります。

— システム管理者には XNUMX つのタイプがあり、バックアップを作成しない人と、すでにバックアップを作成している人です。
・実はXNUMX種類あって、バックアップが復元できるか確認するタイプもあります。

-未知

データのバックアッププロセス自体はプログラムによって実行されるため、他のプログラムと同じ欠点があることも理解する価値があります。 人的要因や機能への依存を取り除く（排除するのではありません！） - 個々には強い効果はありませんが、一緒にすると顕著な効果を与える可能性があります - いわゆるルール3-2-1。 解読方法には多くのオプションがありますが、私は次の解釈の方が気に入っています。同じデータを 3 セット保存する必要があり、2 セットを異なる形式で保存する必要があり、1 セットを地理的に離れたストレージに保存する必要があります。

保存形式は次のように理解する必要があります。

• 物理的な保存方法に依存している場合は、物理的な保存方法を変更します。
• 論理的な保存方法に依存がある場合は、論理的な保存方法を変更します。

3-2-1 ルールの効果を最大限に発揮するには、両方の方法で保存形式を変更することをお勧めします。

機能の復元という本来の目的に対するバックアップの準備の観点から、「ホット」バックアップと「コールド」バックアップは区別されます。 ホット サーバーとコールド サーバーの違いは XNUMX つだけです。ホット サーバーはすぐに使用できるのに対し、コールド サーバーは復号化やアーカイブからの抽出など、回復のために追加の手順が必要です。

ホット コピーとコールド コピーをオンライン コピーとオフライン コピーと混同しないでください。これらはデータの物理的な分離を意味し、実際、バックアップ方法の分類のもう XNUMX つの兆候です。 したがって、復元する必要があるシステムに直接接続されていないオフライン コピーは、(リカバリの準備の観点から) ホットまたはコールドのいずれかになります。 オンライン コピーは復元が必要な場所で直接利用でき、ほとんどの場合ホットですが、コールドのコピーもあります。

さらに、バックアップ コピーの作成プロセス自体は、通常 XNUMX つのバックアップ コピーの作成では終了せず、かなりの数のコピーが作成される可能性があることを忘れないでください。 したがって、完全バックアップ、つまり完全バックアップを区別する必要があります。 他のバックアップとは独立して復元できるもの、および差分 (増分、差分、減分など) コピー - 独立して復元できず、XNUMX つ以上の他のバックアップの事前復元が必要なもの。

差分増分バックアップは、バックアップのストレージ領域を節約する試みです。 したがって、前回のバックアップから変更されたデータのみがバックアップ コピーに書き込まれます。

差分デクリメンタル コピーも同じ目的で作成されますが、方法が少し異なります。完全バックアップ コピーが作成されますが、実際には新しいコピーと前のコピーの差分のみが保存されます。

これとは別に、重複ストレージの不在をサポートするストレージ上でのバックアップのプロセスを検討する価値があります。 したがって、その上に完全バックアップを書き込む場合、実際にはバックアップ間の差分のみが書き込まれますが、バックアップを復元するプロセスは完全コピーからの復元と同様であり、完全に透過的です。

カストディエットipsos custodesを終了しますか？

（誰が監視員たちを自分たちで守るのか？ - 緯度）

バックアップ コピーがない場合は非常に不快ですが、バックアップ コピーが作成されているように見えても、復元するときに次の理由で復元できないことが判明した場合はさらに悪いことになります。

• ソース データの整合性が損なわれています。
• バックアップストレージが破損しています。
• 復元の動作は非常に遅く、部分的に復元されたデータは使用できません。

適切に構築されたバックアップ プロセスでは、このようなコメント、特に最初の XNUMX つのコメントを考慮する必要があります。

ソース データの整合性は、いくつかの方法で保証できます。 最も一般的に使用されるのは、a) ブロック レベルでのファイル システムのスナップショットの作成、b) ファイル システムの状態の「フリーズ」、c) バージョン ストレージを備えた特別なブロック デバイス、d) ファイルの順次記録、またはブロック。 リカバリ中にデータが確実に検証されるようにチェックサムも適用されます。

ストレージの破損は、チェックサムを使用して検出することもできます。 追加の方法は、すでに記録されたデータは変更できないが、新しいデータを追加できる特殊なデバイスまたはファイル システムを使用することです。

リカバリを高速化するために、遅いネットワークや遅いディスク システムなどのボトルネックがない限り、データ リカバリでは複数のリカバリ プロセスが使用されます。 データが部分的に復元された場合の状況を回避するには、バックアップ プロセスを比較的小さなサブタスクに分割し、それぞれを個別に実行します。 これにより、復旧時間を予測しながら安定的に性能を回復することが可能となります。 この問題はほとんどの場合、組織面 (SLA) にあるため、これについては詳しく説明しません。

スパイスの専門家とは、すべての料理にスパイスを加える人ではなく、決して余分なものを加えない人のことです。

-で。 シニャフスキー

システム管理者が使用するソフトウェアに関する慣行は異なる場合がありますが、特に次のような一般原則は何らかの形で同じです。

• 既製のソリューションを使用することを強くお勧めします。
• プログラムは予測どおりに動作する必要があります。 文書化されていない機能やボトルネックがあってはなりません。
• 各プログラムのセットアップは、毎回マニュアルやチートシートを読む必要がないほど簡単である必要があります。
• 可能であれば、解決策は普遍的である必要があります。 サーバーのハードウェア特性は大きく異なる場合があります。

ブロック デバイスからバックアップを取得するための一般的なプログラムは次のとおりです。

• システム管理のベテランにはおなじみの dd ですが、これには同様のプログラム (たとえば、同じ dd_rescue) も含まれています。
• ファイル システムのダンプを作成する、一部のファイル システムに組み込まれているユーティリティ。
• 雑食性のユーティリティ。 たとえばパートクローン。
• 自分自身の、多くの場合独占的な意思決定。 たとえば、NortonGhost 以降などです。

ファイル システムの場合、バックアップの問題はブロック デバイスに適用できる方法を使用して部分的に解決されますが、次のような方法を使用すると、より効率的に問題を解決できます。

• Rsync、ファイル システムの状態を同期するための汎用プログラムおよびプロトコル。
• 組み込みのアーカイブ ツール (ZFS)。
• サードパーティのアーカイブツール。 最も人気のある代表はタールです。 他にも、たとえば、現代のシステムを対象とした tar の代替となる dar があります。

バックアップ コピーを作成するときにデータの一貫性を確保するためのソフトウェア ツールについては、別途言及する価値があります。 最も一般的に使用されるオプションは次のとおりです。

• ファイル システムを読み取り専用モード (ReadOnly) でマウントするか、ファイル システムをフリーズする (freeze) - この方法の適用範囲は限られています。
• ファイル システムまたはブロック デバイス (LVM、ZFS) の状態のスナップショットを作成します。
• 何らかの理由で前述のポイントを提供できない場合でも、印象を整理するためのサードパーティ ツールの使用 (ホットコピーなどのプログラム)。
• ただし、変更時コピー技術 (CopyOnWrite) は、使用されるファイル システム (BTRFS、ZFS) に関連付けられていることがほとんどです。

したがって、小規模サーバーの場合は、次の要件を満たすバックアップ スキームを提供する必要があります。

• 使いやすい - 操作中に特別な追加手順は必要なく、コピーの作成と復元の手順は最小限です。
• ユニバーサル - 大規模サーバーと小規模サーバーの両方で動作します。 これは、サーバーの数を増やしたり拡張したりする場合に重要です。
• パッケージ マネージャーによってインストールされるか、「ダウンロードと解凍」などの XNUMX つまたは XNUMX つのコマンドでインストールされます。
• 安定 - 標準または長年確立されているストレージ形式が使用されます。
• 仕事が早い。

以下の要件を概ね満たす方からの応募となります。

• rdiff-バックアップ
• rsnapshot
• げっぷ
• 複製
• 二枚舌
• 重複させて
• 与える
• zbackup
• レスティック
• ボーグバックアップ

次の特性を持つ仮想マシン (XenServer ベース) がテストベンチとして使用されます。

• 4コア2.5GHz、
• 16 GB RAM、
• パーティション分割のない個別の仮想ディスクの形式の 50 GB ハイブリッド ストレージ (仮想ディスク サイズの 20% を SSD にキャッシュするストレージ システム)、
• 200 Mbps のインターネット チャネル。

ほぼ同じマシンがバックアップ受信サーバーとして使用されますが、500 GB のハード ドライブのみが搭載されています。

オペレーティング システム - Centos 7 x64: 標準パーティション、追加パーティションはデータ ソースとして使用されます。

初期データとして、40 GB のメディア ファイルと mysql データベースを備えた WordPress サイトを考えてみましょう。 仮想サーバーは特性が大きく異なるため、また再現性を高めるために、次のとおりです。

sysbench を使用したサーバーのテスト結果。sysbench --threads=4 --time=30 --cpu-max-prime=20000 CPU 実行
sysbench 1.1.0-18a9f86 (バンドルされている LuaJIT 2.1.0-beta3 を使用)
次のオプションを使用してテストを実行します。
スレッド数：4
現在時刻から乱数発生器を初期化しています

素数制限: 20000

ワーカー スレッドを初期化しています…

スレッドが始まりました！

CPU速度:
836.69 秒あたりのイベント数: XNUMX

スループット：
イベント/秒 (eps): 836.6908
経過時間: 30.0039秒
イベント総数: 25104

レイテンシー (ミリ秒):
最小: 2.38
平均: 4.78
最大: 22.39
95 パーセンタイル: 10.46
合計：119923.64

スレッドの公平性：
イベント (平均/標準偏差): 6276.0000/13.91
実行時間 (平均/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=読み取りメモリ実行
sysbench 1.1.0-18a9f86 (バンドルされている LuaJIT 2.1.0-beta3 を使用)
次のオプションを使用してテストを実行します。
スレッド数：4
現在時刻から乱数発生器を初期化しています

次のオプションを使用してメモリ速度テストを実行します。
ブロックサイズ: 1KiB
合計サイズ: 102400MiB
操作: 読み取り
スコープ: グローバル

ワーカー スレッドを初期化しています…

スレッドが始まりました！

合計操作数: 50900446 (1696677.10 秒あたり XNUMX)

49707.47 MiB 転送 (1656.91 MiB/秒)

スループット：
イベント/秒 (eps): 1696677.1017
経過時間: 30.0001秒
イベント総数: 50900446

レイテンシー (ミリ秒):
最小: 0.00
平均: 0.00
最大: 24.01
95 パーセンタイル: 0.00
合計：39106.74

スレッドの公平性：
イベント (平均/標準偏差): 12725111.5000/137775.15
実行時間 (平均/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=書き込みメモリ実行
sysbench 1.1.0-18a9f86 (バンドルされている LuaJIT 2.1.0-beta3 を使用)
次のオプションを使用してテストを実行します。
スレッド数：4
現在時刻から乱数発生器を初期化しています

次のオプションを使用してメモリ速度テストを実行します。
ブロックサイズ: 1KiB
合計サイズ: 102400MiB
操作: 書き込み
スコープ: グローバル

ワーカー スレッドを初期化しています…

スレッドが始まりました！

合計操作数: 35910413 (1197008.62 秒あたり XNUMX)

35068.76 MiB 転送 (1168.95 MiB/秒)

スループット：
イベント/秒 (eps): 1197008.6179
経過時間: 30.0001秒
イベント総数: 35910413

レイテンシー (ミリ秒):
最小: 0.00
平均: 0.00
最大: 16.90
95 パーセンタイル: 0.00
合計：43604.83

スレッドの公平性：
イベント (平均/標準偏差): 8977603.2500/233905.84
実行時間 (平均/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio 実行
sysbench 1.1.0-18a9f86 (バンドルされている LuaJIT 2.1.0-beta3 を使用)
次のオプションを使用してテストを実行します。
スレッド数：4
現在時刻から乱数発生器を初期化しています

追加のファイルオープンフラグ: (なし)
128 ファイル、各 8MiB
合計ファイルサイズ 1GiB
ブロックサイズ 4KiB
IOリクエストの数: 0
複合ランダム IO テストの読み取り/書き込み比: 1.50
定期的な FSYNC が有効になり、100 リクエストごとに fsync() が呼び出されます。
テストの最後に fsync() を呼び出すと、有効になります。
同期I/Oモードの使用
ランダムな読み取り/書き込みテストを実行する
ワーカー スレッドを初期化しています…

スレッドが始まりました！

スループット：
読み取り: IOPS=3868.21 15.11 MiB/秒 (15.84 MB/秒)
書き込み: IOPS=2578.83 10.07 MiB/秒 (10.56 MB/秒)
fsync: IOPS=8226.98

レイテンシー (ミリ秒):
最小: 0.00
平均: 0.27
最大: 18.01
95 パーセンタイル: 1.08
合計：238469.45

このメモは大きな始まりです

バックアップに関する一連の記事

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

出所： habr.com