キャパシティ層 (または Vim 内ではそれを captir と呼んでいます) は、Veeam Backup and Replication 9.5 Update 4 の時代に、Archive Tier という名前で登場しました。 その背後にあるアイデアは、いわゆる運用上の復元ウィンドウから外れたバックアップをオブジェクト ストレージに移動できるようにすることです。 これは、ディスク容量がほとんどないユーザーのディスク容量を確保するのに役立ちました。 このオプションは移動モードと呼ばれていました。

この単純な (ように見える) アクションを実行するには、XNUMX つの条件を満たすだけで十分です。移動されたバックアップのすべてのポイントが、UI で明示的に設定されている前述の操作可能な復元ウィンドウの境界の外側にある必要があります。 そして XNUMX 番目: チェーンはいわゆる「シールされた形式」 (シールされたバックアップ チェーンまたは非アクティブ バックアップ チェーン) である必要があります。 つまり、時間が経ってもこのチェーンには変化が起こりません。

しかし、VBR v10 では、この概念に新しい機能 (コピー モード、シールド モード) が追加され、不変という発音しにくい名前のものが登場しました。

これらが今日お話しする興味深い事柄です。 まず、VBR9.5u4 での動作について、次に XNUMX 番目のバージョンでの変更点について説明します。

そして、純粋言語の擁護者たちには許してもらいたいのですが、翻訳できない用語が多すぎます。
したがって、ここには英国主義が大量に存在することになります。
そしてたくさんのGIF。
そして写真。

• 少しの後悔もなく。 記事の著者。

そのまま

さて、操作可能な復元ウィンドウと封印されたバックアップ (または非アクティブ バックアップ チェーンのドキュメントで呼ばれる) を分析することから始めましょう。 彼らの理解がなければ、これ以上の説明は不可能です。

図にあるように、データ ブロックを含む一種のバックアップ チェーンがあり、これはキャパシティ層が接続されているリポジトリのパフォーマンス層 SOBR にあります。 運用上のバックアップ期間は XNUMX 日間です。

したがって、月曜日に作成された .vbk は、ウィンドウが XNUMX 日に設定されている前のチェーンを封印します。 つまり、この XNUMX 日より古いものはすべて、安全に射撃場に輸送し始めることができます。

しかし、密封されたチェーンとは正確には何を意味し、アップデート 4 では何がキャパシティー射撃場に送られるのでしょうか?

前方増分では、チェーンが封鎖される兆候は、新しい完全バックアップの作成です。 また、この完全バックアップがどのように取得されるかは関係ありません。合成完全バックアップとアクティブ完全バックアップの両方が考慮されます。

リバースの場合、これらはすべて操作ウィンドウに収まらないファイルです。

ロールバックを伴う前方増分の場合、パフォーマンス エクステントに別の .vbk がある場合、これらはすべてロールバックと .vbk です。

ここで、バックアップ コピー チェーンを使用するオプションを検討してみましょう。 GFS 保管に該当する品目のみがここに輸送されました。 なぜなら、より新しいバックアップ コピー チェーンに保存されているものはすべて、何らかの方法で変更される可能性があるからです。

ボンネットの下を見てみましょう。 そこでは、デハイドレーションと呼ばれるプロセスが発生します。空のバックアップ ファイルがエクステント上に残され、これらのファイルからブロックがキャパシティー射撃範囲にドラッグされます。 このプロセスを最適化するために、いわゆる脱水指数が使用されます。これにより、すでにキャパシティー射撃場にコピーされているブロックのコピーを回避できます。

これがどのようなものかを例で見てみましょう。トランザクション ウィンドウから出てきて、シールされたチェーンに属する .vbk があるとします。 これは、私たちにはそれを定員制の射撃場に移動させる権利があることを意味します。 移動時には、転送されたファイルの容量ダッシュとブロック内にメタデータファイルが作成されます。 リンクレベルのメタデータ ファイルには、ファイルがどのようなブロックで構成されているかが記述されています。 図のケースでは、最初のファイルはブロック a、b、c で​​構成されており、メタデータにはこれらのブロックへのリンクが含まれています。 ブロック a、b、d で構成された XNUMX 番目の .vbk ファイルが移動の準備ができているとき、脱水指数を分析すると、ブロック d のみを転送する必要があることがわかります。 そして、そのメタデータ ファイルには、以前の XNUMX つのブロックと新しいブロック XNUMX つへのリンクが含まれます。

したがって、これらの空のスペースをデータで埋めるプロセスは、リハイドレーションと呼ばれます。 ローカル パフォーマンス エクステント上の最も古い .vbk ファイルに基づいて、独自のリハイドレーション インデックスがすでに使用されています。 つまり、ユーザーがキャパシティ シューティング レンジからファイルを返したい場合は、まず最も古い完全バックアップのブロックのインデックスを作成し、不足しているブロックのみをキャパシティ シューティング ギャラリーから転送します。 図に示されているケースでは、リハイドレーション インデックスに従って FullBackup1.vbk をリハイドレートするには、容量撮影範囲から取得したブロック C のみが必要です。 ストレージ クラウド オブジェクトが容量の射撃場として機能する場合、莫大な費用を節約できます。

ここでは、このテクノロジーが WAN アクセラレータで使用されているものと同一であるように見えるかもしれませんが、実際はそうであるだけです。 アクセラレータでは、重複排除はグローバルです。ここでは、ローカル重複排除は、特定のオフセットにある各ファイル内で使用されます。 これは、解決するタスクの違いにより発生します。ここでは、大規模な完全バックアップ ファイルをコピーする必要があります。調査によると、ファイル間に長時間が経過した場合でも、この重複排除アルゴリズムが最良の結果をもたらします。

でもインデックスの神様にはもっとインデックスが！ データ復旧用のインデックスもあります！ キャパシティ ダッシュにあるマシンの復元を開始するときは、パフォーマンス ダッシュにない一意のデータ ブロックのみを読み取ります。

なったので

導入部分は以上です。 非常に詳細ですが、前述したように、これらの詳細がなければ、新しい機能がどのように動作するかを説明することはできません。 したがって、これ以上苦労せずに、最初の作業に進みましょう。

コピーモード

これは主に既存のテクノロジーに基づいていますが、使用ロジックはまったく異なります。 

このモードの目的は、ローカル エクステントにあるすべてのデータが容量ダッシュにコピーを持つことを保証することです。

移動モードとコピー モードを正面から比較すると、次のようになります。

• シールドチェーンのみ移動可能です。 コピー モードの場合、バックアップ ジョブで何が起こったかに関係なく、絶対にすべてが転送されます。
• ファイルが操作可能なバックアップ ウィンドウの境界を超えると移動がトリガーされ、バックアップ ファイルが表示されるとすぐにコピーがトリガーされます。
• 新しいデータのコピーの監視は継続的に行われ、移動の場合は 4 時間ごとにトリガーされました。

新しいモードを検討する際に、単純な例から複雑な例に移行することを提案します。

最も一般的なケースでは、単に増分付きの新しいファイルがあり、それをキャパシティー射撃場にコピーするだけです。 バックアップ ジョブでどのモードが使用されているかに関係なく、チェーンのシールされた部分に属しているかどうかに関係なく、操作ウィンドウの有効期限が切れているかどうかに関係なく。 彼らはただそれを受け取ってコピーしただけです。

この背後にあるプロセスは、前述したように依然として脱水です。 コピー モードでは、すでにストレージ上にあるブロックをコピーしないようにします。 唯一の違いは、ムービー モードで実際のファイルをダミー ファイルに置き換える場合、ここではそれらに一切手を加えず、すべてをそのままにしておくということです。 それ以外の場合は、お金と時間を慎重に節約しようとする脱水指数とまったく同じです。

疑問が生じます。UI を見ると、両方のオプションを同時に選択する機会があります。 このような複合モードはどのように機能するのでしょうか?

それを考えてみましょう。

最初は標準です。バックアップ ファイルが作成され、すぐにコピーされます。 それに増分が作成され、コピーされます。 これは、ファイルがオペレーティング ウィンドウから出て、密閉されたチェーンが出現したことに気づく瞬間まで発生します。 この時点で、デハイドレーション操作を実行し、これらのファイルをダミー ファイルに置き換えます。 もちろん、キャパシティー射撃場に再度何かをコピーすることはありません。

この魅力的なロジックはすべて、インターフェイス内の XNUMX つのチェックボックスだけを担当します。つまり、バックアップが作成されたらすぐにオブジェクト ストレージにコピーします。

なぜこのコピーモードが必要なのでしょうか?

この質問を次のように言い換えるとさらによいでしょう。「その助けを借りて私たちはどのようなリスクから守られるのでしょうか?」 それはどのような問題の解決に役立ちますか?

答えは明らかです。もちろん、これはデータの回復です。 オブジェクト ストレージ上にローカル データの完全なコピーがあれば、製品に何が起こっても、いつでも条件付き Amazon にあるファイルからデータを復元できます。

それでは、最も単純なものからより複雑なものまで、考えられるシナリオを見てみましょう。

私たちの身に降りかかる可能性のある最も単純な不幸は、バックアップ チェーン内のファイルの XNUMX つにアクセスできなくなることです。

さらに悲しい話は、SOBR リポジトリのエクステントの XNUMX つが破損したことです。

SOBR リポジトリ全体がアクセスできなくなっても、キャパシティー シューティング レンジは機能している場合、事態はさらに悪化します。
そして、すべてが本当に悪いです - これはバックアップサーバーが停止したときであり、最初の願望はXNUMX分以内にカナダ国境まで走ろうとすることです。

次に、それぞれの状況を個別に見てみましょう。

XNUMX つ (場合によっては複数) のバックアップ ファイルが失われた場合、リポジトリの再スキャン プロセスを開始するだけで、失われたファイルはダミー ファイルに置き換えられます。 また、再水和プロセス (記事の冒頭で説明した) を使用すると、ユーザーはキャパシティ射撃場からローカル ストレージにデータをダウンロードできるようになります。

現在、状況はさらに複雑になっています。 SOBR がパフォーマンス モードで実行されている XNUMX つのエクステントで構成されていると仮定します。これは、.vbk と .vib がかなり不均一なレイヤーでそれらの上に分散されていることを意味します。 そしてある時点で、エクステントの XNUMX つが使用できなくなり、ユーザーはデータの一部が正確にこのエクステント上に存在するマシンを緊急に復元する必要があります。

ユーザーはリカバリ ウィザードを起動し、復元したいポイントを選択します。ウィザードは作業中に、リカバリに必要なすべてのデータがローカルにないため、キャパシティー シューティングからダウンロードする必要があることに気づきます。ギャラリー。 同時に、ローカル ストレージに残っているブロックはクラウドからダウンロードされません。 復元インデックスに栄光あれ (はい、記事の冒頭でも触れました)。

このケースのサブタイプは、SOBR リポジトリ全体がアクセス不能になったことです。 この場合、ローカル ストレージからコピーするものは何もなく、すべてのブロックがクラウドからダウンロードされます。

そして最も興味深い状況は、バックアップ サーバーが停止したことです。 ここには XNUMX つのオプションがあります。管理者は優秀で構成のバックアップを作成しました。もう XNUMX つは、管理者自体が邪悪なピノキオであり、構成のバックアップを作成しませんでした。

最初のケースでは、VBR のクリーン インストールをどこかに展開し、標準的な手段を使用してバックアップからデータベースを復元するだけで十分です。 このプロセスが完了すると、すべてが通常の状態に戻ります。 または、上記のいずれかのシナリオに従って復元されます。

しかし、管理者が自分の敵である場合、または構成のバックアップにも重大な障害が発生した場合でも、ここでも管理者を運命のなすがままにしておくことはできません。 このケースのために、オブジェクト ストレージのインポートと呼ばれる新しい手順を導入しました。 これにより、手動で SOBR リポジトリを再作成し、その後の再スキャンでキャパシティ シューティング レンジをアタッチするプロセスをスキップし、単純にストレージ オブジェクトを Vim インターフェイスに追加して、ストレージ リポジトリのインポート手順を実行できます。 バックアップが暗号化されている場合、ユーザーとバックアップの間で唯一邪魔になるのは、パスワードの入力を要求されることです。

おそらくこれはコピー モードに関するすべてであり、次に進みます。

密閉モード

主な考え方は、リポジトリの選択された SOBR エクステントには新しいバックアップを表示できないということです。 v10 より前は、リポジトリでの作業が完全に禁止されていたメンテナンス モードのみがありました。 ストレージをシャットダウンするための一種のハードコア モードで、バックアップを別のエクステントに XNUMX 回だけ転送する [退避] ボタンのみが使用可能です。

また、シールド モードは一種の「ソフト」オプションです。新しいバックアップの作成を禁止し、選択した保持期間に従って古いバックアップを徐々に削除しますが、その過程で、保存されたポイントから復元する機能は失われません。 これは、ハードウェアの寿命が近づいていて交換する必要がある場合、またはより重要な作業のためにハードウェアを解放する必要があるが、それを取り出してすべてを一度に移動する場所がない場合に非常に役立ちます。 もしくは削除できません。

したがって、動作原理は非常に単純です。すべての書き込み操作 (新しいデータの出現) を禁止し、読み取り (復元) と削除 (保持) を残す必要があります。

両方のモードを同時に使用できますが、メンテナンスの方が優先されることに注意してください。

例として、XNUMX つのエクステントで構成される SOBR を考えてみましょう。 最初の XNUMX 日間は Forward Forever Incremental モードでバックアップを作成し、その後エクステントを封印すると、XNUMX 番目に使用可能なエクステントで新しいアクティブなフル エクステントの作成を開始すると仮定します。 保持が XNUMX の場合、封印された範囲にあるチェーン全体がその制限を超えた場合、明確な良心のもとに削除されます。

場合によっては、削除が早く行われる場合があります。 たとえば、これは定期的なフルによるフォワード増分です。 最初の XNUMX 日間の完全バックアップを作成し、木曜日にリポジトリを封印することにした場合、金曜日に新しいバックアップが作成されると、月曜日のファイルは削除されます。 この時点までの依存関係はありません。 そして、その点自体は誰にも依存しません。 次に、使用可能な範囲に XNUMX つのポイントが作成されるまで待機し、残りの XNUMX つを削除します。これらのポイントはそれぞれ独立して削除できません。

逆インクリメンタルを使用すると、物事がより簡単になります。 その中で、最も古いポイントは何にも依存しないため、安全に削除できます。 したがって、新しいエクステントに新しい .vbk が作成されるとすぐに、古い .vrbs は XNUMX つずつ削除されます。

ところで、なぜ毎回新しい .vbk を作成するのでしょうか。作成せずに古い増分チェーンを継続すると、古い .vbk はどのモードでも無限に長時間フリーズし、削除できなくなります。 したがって、エクステントが封印され次第、空きエクステントに完全バックアップを作成することが決定されました。

定員制の射撃場では事態はさらに複雑になります。

まず、コピーモードについて見てみましょう。 XNUMX 日間バックアップを積極的に作成していたのに、射撃場が閉鎖されてしまったとしましょう。 何も削除することはありませんが、保持は謙虚に耐え、その後、キャパシティー射撃場からデータを削除します。

移動モードでもほぼ同じことが起こります。レタッチを待ち、ローカル ストレージにある古いものを削除し、オブジェクト ストレージに保存されているものを削除します。

Forever forward incremental を使用した興味深い例です。 XNUMX つのポイントに保持をインストールし、月曜日からバックアップの作成を開始します。バックアップは定期的にクラウドにコピーされます。 ストレージを封印した後も、バックアップは作成され続け、XNUMX つのポイントが維持されますが、容量ダッシュに保存されたデータは依存したままであり、削除できません。 したがって、.vbk が保存期間を超える木曜日まで待ってから、保存されたチェーン全体を静かに削除します。

小さな免責事項: ここでのすべての例は XNUMX 台のマシンで示されています。 バックアップに複数のファイルがある場合、Active Full が作成されたかどうかによってレタッチが異なります。

基本的にはこれだけです。 それでは、最もハードコアな機能に移りましょう -

不変性

前の点と同様に、まず、この機能がどのような問題を解決するかです。 バックアップを保管場所にアップロードするとすぐに、バックアップの安全性を保証したい、つまり、一定の保存期間中はバックアップの削除や変更を物理的に禁止したいという強い要望が生まれます。 管理者 (root アカウント下を含む) も含まれます。 これにより、偶発的または意図的な損傷から保護できます。 AWS を使用している人なら誰でも、オブジェクト ロックと呼ばれる同様の機能に遭遇したことがあるかもしれません。

ここでモードを一般的に見てから、詳細を掘り下げてみましょう。 この例では、キャパシティー射撃場に対して不変性が有効になり、保持期間は XNUMX 日間になります。 また、バックアップではコピー モードが有効になります。

不変性は、一般的な保持とはいかなる形でも相互作用しません。 例えば、追加点などはありません。 ただ、バックアップ ファイルを XNUMX 日以内に削除することはできません。 月曜日にバックアップを作成した場合、そのファイルを削除できるのは金曜日に限られます。

これまでに説明したデハイドレーション、インデックス、メタデータの概念はすべて、引き続きまったく同じように機能します。 ただし、条件が XNUMX つあります。ブロックはデータだけでなくメタデータにも設定されます。 これは、狡猾な攻撃者がメタデータ データベースを消去することを決定した場合に備えて、データ ブロックが役に立たないバイナリのドロドロになるのを防ぐために行われます。

ここで、ブロック生成テクノロジーについて説明します。 またはブロック生成。 これを行うには、その出現に至った状況を考慮してください。

2 日の時間スケールを考えてみましょう。それより下に、不変性の予想有効期限が切れる時間をマークします。 初日は、データ ブロック a とそのメタデータから構成されるファイルを取得して作成します。 不変性が 3 日間に設定されている場合、XNUMX 日目にデータのロックが解除され、削除されると考えるのが自然です。 XNUMX 日目には、同じ設定のブロック b で構成される新しいファイル XNUMX を追加します。 ブロック a は XNUMX 日目にも削除する必要があります。 しかし、XNUMX 日目に何か恐ろしいことが起こります。新しいブロック d と古いブロック a へのリンクで構成される FileXNUMX ファイルが作成されます。 これは、ブロックとその不変フラグを新しい日付 (XNUMX 日目にシフト) にリセットする必要があることを意味します。 そして、ここで問題が発生します。実際のバックアップには、そのようなブロックが膨大な数あります。 また、不変期間を延長するには、毎回膨大な数のリクエストを行う必要があります。 そして実際、これはほぼ終わりのない毎日のプロセスになるでしょう。なぜなら、高い確率で各コピーで重複排除されたブロックの大量のスタックが見つかるからです。 オブジェクト ストレージ プロバイダーからの大量のリクエストは何を意味しますか? 右！ 月末に高額な請求。

そして、お気に入りのクライアントを突然多額の金銭にさらさないようにするために、ブロック生成メカニズムが発明されました。 これは、設定された不変期間に追加される追加の期間です。 以下の例では、この期間は XNUMX 日です。 しかし、これは単なる一例です。 実際には、彼らは独自の計算式を使用しており、毎月のロック中に約 XNUMX 日の追加時間が与えられます。

同じ状況を、ブロック生成について引き続き検討してみましょう。 初日は、ブロック a とメタデータから file1 を作成します。 生成期間と不変性を合計します。これは、ファイルを削除できる機会が 2 日目になることを意味します。 3 日目にブロック b とブロック a へのリンクで構成される File2 を作成すると、削除予定日には何も起こりません。 彼女は1日目と同じように立っていた。 したがって、リクエストの数を節約しようとしています。 期限をずらすことができる唯一の状況は、生成期間が終了した場合です。 つまり、XNUMX 日目に新しい FileXNUMX にブロック a へのリンクが含まれている場合、GenXNUMX の有効期限がすでに切れているため、世代 XNUMX が追加されます。 そしてブロックaの削除予定日はXNUMX日目にずれます。 これにより、リクエストの数を大幅に減らし、重複排除されたブロックの寿命を延ばすことができ、クライアントのコストを大幅に節約できます。

このテクノロジー自体は、S3 および S3 互換ハードウェアのユーザーが利用でき、その実装が Amazon のものと変わらないことをメーカーが保証しています。 したがって、なぜ Azure がサポートされないのかという正当な質問に対する答えが得られます。Azure には同様の機能がありますが、個々のオブジェクトではなくコンテナー レベルで機能します。 ちなみに、Amazon自体はコンプライアンスとガバナンスのXNUMXつのモードでオブジェクトロックを行っています。 XNUMX 番目のケースでは、管理者よりも上位の管理者、およびルートよりも上位のルートが、オブジェクト ロックにもかかわらずデータを削除する可能性が残ります。 コンプライアンスの場合、すべてがしっかりと固定されており、誰もバックアップを削除できません。 Amazonの管理者さえも（公式声明によると）。 これは私たちがサポートしているモードです。

そして、いつものように、いくつかの役立つリンクがあります:

• オン ブロック生成 細部まで。
• に関するすべての情報 Veeam バックアップ & レプリケーション 10 その最高の状態で
• О 容量階層 詳細に

出所： habr.com