Veeam B＆R保持ポリシー-テクニカルサポートによるバックアップチェーンの解明

私たちのブログの読者の皆さん、こんにちは！私たちはすでに部分的に精通しています-私の英語の投稿は私の親愛なる同僚の翻訳でここに表示されましたポラロウ..。今回は、ロシア語を話す聴衆に直接話しかけることにしました。



デビューのために、私は可能な限り幅広い聴衆に興味があり、詳細な検討が必要なトピックを見つけたかったのです。ダニエル・デフォーは、死と税金は誰でも待っていると主張しました。私としては、サポートエンジニアなら誰でも、リカバリポイントのストレージポリシー（または、より簡単に言えば、保持）について質問があると言えます。リテンションの仕組みについては、4年前に第1レベルのジュニアエンジニアとして説明を始め、現在もスペイン語とイタリア語を話すチームのチームリーダーとして説明を続けています。 2番目と3番目のレベルのサポートの同僚も定期的に同じ質問に答えていると確信しています。



この観点から、私は、ロシア語を話すユーザーが参照として何度も何度も戻ってくることができる、最後の最も詳細な投稿を書きたかったのです。その瞬間は正しいです-最近リリースされた10周年記念バージョンは、何年も変わっていない基本的な機能に新しい機能を追加しました。私の投稿は主にこのバージョンに焦点を当てています-書かれた内容のほとんどは以前のバージョンに当てはまりますが、そこに記載されている機能の一部が見つからないだけです。最後に、少し先を見据えて、次のバージョンでは変更が予想されると思いますが、その時期が来たらお知らせします。それでは始めましょう。

バックアップジョブ

まず、バージョン10で変更されていない部分を見てみましょう。保持ポリシーはいくつかのパラメーターによって決定されます。新しいタスクを作成するためのウィンドウを開いて、[ストレージ]タブに移動しましょう。ここに、必要な回復ポイントの数を決定するパラメーターが表示されます。







ただし、これは方程式の一部にすぎません。実際のポイント数は、タスクに設定されているバックアップモードによっても決まります。このパラメータを選択するには、同じタブの[詳細設定]ボタンをクリックする必要があります。これにより、多くのオプションを含む新しいウィンドウが開きます。それらに番号を付けて、順番に検討してみましょう。







オプション1のみが有効になっている場合、ジョブは「永久転送増分」モードで実行されます。ここでは問題はありません。タスクは、完全バックアップ（VBK拡張子のファイル）から最後の増分（VIB拡張子のファイル）までの設定された数の復元ポイントを保存します。ポイント数が指定された値を超えると、最も古い増分が完全バックアップとマージされます。つまり、タスクが3ポイントを格納するように設定されている場合、次のセッションの直後にリポジトリに4ポイントがあり、その後、完全バックアップが最も古い増分とマージされ、ポイントの総数は3に戻ります。







「リバースインクリメンタル」モード（オプション2）の保持も非常に簡単です。この場合、最新のポイントは完全バックアップであり、その後にいわゆるロールバック（VRB拡張子を持つファイル）のチェーンが続くため、保持を適用するには、最も古いロールバックを削除する必要があります。状況は同じです。セッションの直後に、ポイント数が設定値を1超え、その後、目的の値に戻ります。







リバースインクリメンタルモードでは、定期的なフルバックアップ（オプション4）を有効にすることもできますが、これによって本質が変わることはありません。はい、完全な復元ポイントがチェーンに表示されますが、それでも最も古いポイントを1つずつ削除します。



最後に、興味深い部分に行き着きます。インクリメンタルバックアップをアクティブ化するが、さらにオプション3または4（または両方を同時に）を有効にすると、タスクは「アクティブ」または合成方法を使用して定期的なフルバックアップの作成を開始します。フルバックアップを作成する方法は重要ではありません。同じデータが含まれ、インクリメンタルチェーンはサブチェーンに分割されます。この方法はフォワードインクリメンタルと呼ばれ、クライアントからの質問の重要な部分を提起するのは彼です。



ここで保持は、チェーンの最も古い部分を削除することによって使用されます（完全バックアップから増分まで）。同時に、中空のバックアップのみ、または増分の一部のみを削除することはありません。 「サブセット」全体が一度に完全に削除されます。ポイント数を設定する意味も変わります。他の方法でこれが最大許容数であり、その後保持を適用する必要がある場合、この設定によって最小数が決まります。つまり、最も古い「サブストリング」を削除した後、残りの部分のポイント数がこの最小値を下回ってはなりません。



この概念をグラフィカルに表現しようと思います。保持が3ポイントに設定されているとすると、タスクは毎日実行され、月曜日に完全バックアップが行われます。この場合、ポイントの総数が10に達すると、保持が適用されます。







彼らが3をあげたのになぜ10人もいるのですか？月曜日に完全バックアップが作成されました。火曜日から日曜日まで、ジョブは増分を作成しました。最後に、次の月曜日に完全バックアップが再度作成されます。2つの増分が作成された場合にのみ、残りのポイント数がセット3を下回らないため、チェーンの古い部分全体を最終的に削除できます。



アイデアが明確な場合は、保持を自分で計算することをお勧めします。次の条件を考えてみましょう。タスクは木曜日に初めて起動されます（もちろん、完全なバックアップが作成されます）。タスクは、水曜日と日曜日に完全バックアップを作成し、8つの復元ポイントを保存するように設定されています。保持が初めて適用されるのはいつですか？



この質問に答えるには、紙を1枚取り、曜日ごとに並べて、毎日作成されるポイントを書き留めておくことをお勧めします。答えは明らかになります





一部の読者は、「rps.dewin.meがあるのに、なぜこれがすべてなのか」と主張するかもしれません。間違いなく、これは非常に便利なツールであり、場合によっては使用しますが、制限もあります。まず第一に、初期条件を指定することはできません。多くの場合、問題はまさに「そのようなチェーンがあります。そのような設定を変更するとどうなりますか？」です。第二に、ツールはまだ明確さを欠いています。RPSページをクライアントに見せても理解できませんでしたが、例のように（同じペイントを使っていても）ペイントすると、毎日、すべてが明らかになりました。



最後に、「以前のバックアップチェーンをロールバックに変換する」オプション（5でマーク）については説明していません。このオプションは、「自動的に」アクティブ化するクライアントを混乱させ、合成バックアップを有効にしたい場合があります。一方、このオプションは非常に特別なバックアップモードをアクティブにします。詳細に立ち入ることなく、製品開発のこの段階では、「以前のバックアップチェーンをロールバックに変換する」というのは時代遅れのオプションであり、いつ使用すべきかという単一のシナリオを考えることはできません。その価値は非常に疑わしいので、しばらくの間、アントン・ゴステフ自身がフォーラムを通して叫び声を上げ、その有用な使用例を送ってくれるように頼みました（もしあれば、コメントを書いてください、私は非常に興味があります）。ない場合（そうなると思います）、オプションは将来のバージョンで削除されます。



ジョブは、合成完全バックアップがスケジュールされる日まで増分（VIB）を作成します。この日、VBKは実際に作成されますが、このVBKより前のすべてのポイントがロールバック（VRB）に変換されます。その後、タスクは次の合成バックアップまで完全バックアップへの増分を作成し続けます。その結果、VBK、VBR、およびVIBファイルの爆発的な混合がチェーン内に作成されます。保持は非常に簡単に適用されます-最後のVBRを削除することによって：

問題

それがどのように機能するかを理解することに加えて、インクリメンタルモードを使用するときに発生する問題のほとんどは、通常、完全バックアップに関連しています。このモードでは、定期的な完全バックアップが必要です。そうでない場合、リポジトリはオーバーフローするまでポイントを蓄積します。



たとえば、完全バックアップが作成されることはめったにありません。タスクが10ポイントを保存するように設定されており、完全なバックアップが月に1回作成されるとします。ここでの実際のポイント数は、1セットよりもはるかに多いことは明らかです。または、タスクは通常、無限増分モードで動作し、50ポイントを保存するように設定されています。次に、誰かが誤って完全バックアップを作成しました。これで、タスクは、フルポイントが49の増分を累積するまで待機し、その後、保持を適用して、無限フルモードに戻ります。



その他の場合、完全バックアップは定期的に作成されるように設定されていますが、何らかの理由で作成されません。ここで最も人気のある理由を書き留めておきます。一部のお客様は、「後実行」スケジューリングオプションを使用して、チェーンで実行するようにジョブを設定することを好みます。この例を見てみましょう。毎日実行され、日曜日に完全バックアップを作成する3つのジョブがあります。最初のタスクは22.30に開始され、残りはチェーンで起動されます。増分バックアップには10分かかるため、23.00までにすべてのタスクが完了します。ただし、完全バックアップには1時間かかるため、日曜日に次のことが発生します。最初のタスクは22.30から23.30まで実行されます。次は23.30から00.30までです。しかし、3番目のタスクは月曜日に始まります。完全バックアップは日曜日に設定されているため、この場合は単純に存在しません。タスクは、完全バックアップが保持を適用するのを待ちます。したがって、「実行後」オプションを使用する場合は注意するか、まったく使用しないでください。ジョブを同時に開始するように設定し、リソーススケジューラにそのジョブを実行させます。

難しいオプション「削除されたアイテムを削除する」

[ストレージ]-[詳細]-[メンテナンス]タスクの設定を確認すると、日数で計算される「削除されたアイテムのデータを後で削除する」オプションに出くわすことができます。







一部のクライアントは、これが保持であると期待しています。実際、これは完全に別個のオプションであり、その誤解は予期しない結果につながる可能性があります。ただし、最初のステップは、セッション中に少数のマシンのみが正常にバックアップされた状況にB＆Rがどのように反応するかを説明することです。



このシナリオを考えてみましょう。6ポイントを格納するように構成された無限増分ジョブ。このタスクには2台のマシンがあり、1台は常に正常にバックアップされ、もう1台はエラーが発生することがありました。その結果、7番目のポイントまでに次の状況が発生しました。







保持を適用する時間ですが、1台の車は7ポイントで、もう1台は4ポイントしかありません。ここで保持が適用されますか？答えはイエスです。少なくとも1つのオブジェクトがバックアップされている場合、B＆Rはポイントが作成されたと見なします。



特定のセッション中に特定のマシンがタスクに含まれていなかった場合にも、同様の状況が発生する可能性があります。これは、たとえば、マシンがタスクに個別に追加されるのではなく、コンテナ（フォルダ、ストレージ）の一部として追加され、一部のマシンが一時的に別のコンテナに移行される場合に発生します。この場合、タスクは成功したと見なされますが、統計には、そのようなマシンがタスクによって処理されなくなったことに注意するように促すメッセージが表示されます。







これに注意を払わないとどうなりますか？無限インクリメンタルモードまたは逆インクリメンタルモードの場合、「問題のある」マシンのリカバリポイントの数は、VBKに格納されている1に達するまで、セッションごとに減少します。つまり、マシンが長期間バックアップされていなくても、1つの復元ポイントが残ります。これは、定期的な完全バックアップが有効になっている場合には当てはまりません。 B＆Rからの信号を無視すると、チェーンの古い部分とともに最後のポイントを削除できます。



これらの詳細が明確になったので、最終的に「削除されたアイテムのデータを後で削除する」オプションを確認できます。特定の車両がX日間バックアップされていない場合、その車両のすべてのポイントが削除されます。この設定はエラーに応答しないことに注意してください（試してみました-機能しませんでした）。マシンをバックアップしようとする試みすらあってはなりません。このオプションは便利であり、常にオンにしておく必要があるようです。管理者がマシンをタスクから削除した場合は、しばらくして不要なデータからチェーンをクリアするのが論理的です。ただし、チューニングには規律と注意が必要です。



実践からの例を挙げましょう。いくつかのコンテナがタスクに追加され、その構成は非常に動的でした。 B＆R RAMが不足しているため、サーバーで見過ごされていた問題が発生していました。タスクが開始され、その時点でコンテナに存在していなかったマシンを除いて、マシンのバックアップを試みました。多くのマシンでエラーが発生したため、デフォルトでは、B＆Rは「問題のある」マシンをバックアップするためにさらに3回試行する必要があります。 RAMの問題が解決しないため、これらの試行には数日かかりました。欠落しているVMのバックアップを繰り返し試行することはありませんでした（VMがないことはエラーではありません）。その結果、いずれかの再試行中に「削除済みアイテムの削除」条件が満たされ、マシンのすべてのポイントが削除されました。



この点で、私は次のように言うことができます：タスクの結果に関する通知を構成した場合、またはさらに良いことに、Veeam ONEとの統合を使用している場合、これはおそらく発生しません。週に1回B＆Rサーバーをチェックしてすべてが機能していることを確認する場合は、バックアップの削除につながる可能性のあるオプションを拒否することをお勧めします。

v.10で追加されたもの

以前お話ししたことは、多くのバージョンのB＆Rに存在していました。これらの仕事の原則を理解したので、今度は記念日「10」に何が追加されたかを見てみましょう。

毎日の保持

上記では、ポイント数に基づいて「クラシック」ストレージポリシーを検討しました。別のアプローチは、同じメニューで「ポイントの復元」ではなく「日」を設定することです。







アイデアは名前から明らかです-保持は設定された日数を保存しますが、毎日のポイント数は重要ではありません。その際、次の点に注意してください。

• 保持を計算するときに当日は考慮されません
• タスクがまったく機能しなかった日もカウントされます。これは、不規則に機能するタスクのポイントを誤って失うことがないように留意する必要があります。
• リカバリポイントは、作成が開始された日からカウントされます（つまり、タスクが月曜日に作業を開始し、火曜日に終了した場合、このポイントは月曜日からです）

残りの部分については、タスクによる保持の適用の原則も、選択したバックアップ方法によって決定されます。同じインクリメンタルメソッドを使用して、別の計算タスクを試してみましょう。保持が8日間に設定されているとすると、タスクは6時間ごとに実行され、水曜日に完全バックアップが実行されます。ただし、このタスクは日曜日には機能しません。仕事は月曜日に初めて始まります。保持はいつ適用されますか？

通常のジョブのGFSアーカイブ

v.10より前は、Grandfather-Father-Son（GFS）ストレージ方式は、バックアップコピーおよびテープコピージョブでのみ使用可能でした。現在、定期的なバックアップにも使用できます。

これは現在のトピックとは関係ありませんが、新しい機能は3-2-1戦略からの逸脱を意味するものではないと言わざるを得ません。メインリポジトリにアーカイブポイントが存在しても、その信頼性にはまったく影響しません。GFSをスケールアウトリポジトリと組み合わせて使用​​して、これらのポイントをS3および同様のリポジトリにオフロードすることを目的としています。使用しない場合は、プライマリポイントとアーカイブポイントを引き続き別のリポジトリに保存することをお勧めします。

次に、GFSポイントの作成の原則を見てみましょう。タスク設定の[ストレージ]ステップで、次のメニューを呼び出す特別なボタンが表示されます







。GFSの本質をいくつかのポイントに減らすことができます（GFSは他のタイプのタスクでは動作が異なりますが、後で詳しく説明します）。

• このタスクでは、GFSポイントの個別の完全バックアップは作成されません。代わりに、利用可能な最も適切な完全バックアップが使用されます。したがって、タスクは定期的なフルバックアップを使用してインクリメンタルモードで動作するか、ユーザーがフルバックアップを手動で作成する必要があります。
• 1つの期間（たとえば、1週間）のみが有効になっている場合、GFS期間の開始時に、タスクは完全なバックアップの待機を開始し、最初の適切な期間をGFSとしてマークします。

例：水曜日のバックアップを使用して毎週のGFSを保存するようにジョブが構成されています。タスクは毎日実行されますが、完全バックアップは金曜日に予定されています。この場合、GFS期間は水曜日に開始され、ジョブは適切なポイントを待機し始めます。金曜日に表示され、GFSフラグが付けられます。

• (, ), B&R , GFS ( ). , .

例：毎週のGFSは水曜日に請求され、毎月のGFSはその月の最後の週に請求されます。タスクは毎日実行され、月曜日と金曜日に完全なバックアップを作成します。



簡単にするために、月の最後から2番目の週から数え始めましょう。今週、完全バックアップは月曜日に作成されますが、毎週のGFS間隔は水曜日に開始されるため、無視されます。ただし、金曜日の完全バックアップはGFSポイントに完全に適しています。このシステムはすでに私たちに馴染みがあります。







今月の最後の週に何が起こるかを考えてみましょう。月次GFS間隔は月曜日に開始されますが、ジョブは1つのVBKを月次および週次GFSポイントとしてマークしようとするため、月曜日VBKはGFSとしてフラグが立てられません。この場合、検索は正確に週単位で開始されるため、定義上、月単位になることもあります。







この場合、週次と年次の間隔のみを含めると、それらは互いに独立して動作し、GFS間隔に対応するものとして2つの別々のVBKをマークできます。

バックアップコピータスク

多くの場合、仕事の明確化を必要とする別のタイプの割り当て。まず、革新のない「古典的な」作業方法を分析しましょうv.10

簡単な保持方法

デフォルトでは、このようなジョブは無限増分モードで実行されます。ポイントの作成は、コピー間隔と必要な回復ポイントの数の2つのパラメーターによって決定されます（日数による保持はありません）。コピー間隔は、ジョブ作成時の最初の[ジョブ]タブで設定されます。







ポイント数は、[ターゲット]タブでもう少し決定されます







。ジョブは、間隔ごとに1つの新しいポイントを作成します（元のジョブによってVMに作成されたポイントの数は関係ありません）。間隔の終わりに、新しいポイントが確定され、必要に応じて、VBKと最も古い増分を組み合わせて保持が適用されます。私たちはすでにこのメカニズムに精通しています。

GFSを使用した保持方法

BCJは、アーカイブポイントを保存する方法も知っています。これは、リカバリポイント数の設定のすぐ下にある、同じ[ターゲット]タブで構成されます







。GFSポイントは、2つの方法で作成できます。合成、セカンダリリポジトリのデータを使用する方法、または完全バックアップをシミュレートしてプライマリリポジトリからすべてのデータを読み取る方法（番号3でマークされたオプションでアクティブ化）です。 ..。どちらの場合も保持は大きく異なるため、個別に検討します。

合成GFS

この場合、GFSポイントは正確な日付に作成されません。代わりに、GFSポイントの作成がスケジュールされた日のVIBが完全バックアップとマージされるときに、GFSポイントが作成されます。時間が経過するため、これにより混乱が生じることがありますが、それでもGFSポイントはありません。そして、技術サポートの強力なシャーマンだけが、ポイントが表示される日を予測できます。実際、魔法は必要ありません。設定されたポイント数と同期間隔（毎日作成されるポイント数）を確認するだけです。この例を使用して自分で計算してみてください。タスクは7ポイントを格納するように設定されており、同期間隔は12時間です（つまり、1日あたり2ポイント）。現在、チェーンにはすでに7つのポイントがあり、今日は月曜日であり、GFSポイントの作成はこの日に予定されています。何日に作成されますか？

「ポイント全体を読み取る」オプションを使用したGFSポイントの作成

上記で、BCJは無限インクリメンタルモードで動作すると述べました。ここで、このルールの唯一の例外を分析します。 「ポイント全体を読み取る」オプションを有効にすると、GFSポイントはスケジュールされた日に正確に作成されます。タスク自体は、上記で説明した定期的な完全バックアップを使用したインクリメンタルモードで動作します。チェーンの最も古い部分を削除することによっても保持が適用されます。ただし、この場合、増分のみが削除され、完全バックアップはGFSポイントとして残されます。したがって、GFSフラグでマークされたポイントは、保持を計算するときに考慮されません。



タスクが7ポイントを保存し、月曜日に毎週GFSポイントを作成するように設定されているとします。この場合、毎週月曜日にジョブは完全なバックアップを作成し、それをGFSとしてマークします。最も古い部分から増分を削除した後、残りの増分の数が7を下回らない場合、保持が適用されます。これは、図でどのように表示されるかを示しています。







したがって、第2週の終わりまでに、チェーンには14ポイントがあります。 2週目に、タスクは7ポイントを作成しました。単純な作業であれば、保持はすでに適用されているはずです。ただし、これはGFS保持のあるBCJであるため、GFSポイントはカウントされません。つまり、6つしかないため、保持を適用することはできません。 3週目に、GFSフラグを使用して別の完全バックアップを作成します。 15ポイントですが、これは再度カウントしません。最後に、第3週の火曜日に、増分を作成します。ここで、最初の週のチェーン増分を削除すると、増分の総数は設定された保持を満たします。



上記のように、この方法では、完全なバックアップを定期的に作成することが非常に重要です。たとえば、メインの保持期間を7日間に設定し、年間ポイントが1つしかない場合、増分が7をはるかに超える強力な累積になることは容易に想像できます。このような場合は、GFSを作成する合成方法を使用することをお勧めします。

そして再び「削除されたアイテムを削除する」

このオプションはBCJにも存在します。このオプション







のロジックは、通常のバックアップジョブの場合と同じです。マシンが指定された日数処理されない場合、そのデータはチェーンから削除されます。ただし、BCJの場合、このオプションの有用性は客観的に高く、その理由は次のとおりです。



通常モードでは、BCJは無限増分モードで動作するため、ある時点でマシンがタスクから削除されると、VBKで残りが1つになるまで、保持によってすべての復元ポイントが徐々に削除されます。ここで、合成GFSポイントを作成するようにジョブが構成されていると想像してください。時が来たら、ジョブはチェーン内のすべてのマシンのGFSを作成する必要があります。一部の車に新しいポイントがまったくない場合は、新しいポイントを使用する必要があります。そして毎回。その結果、次の状況が発生する可能性があります。







ファイルセクションに注意してください。メインのVBKと2週間のGFSポイントがあります。そして今、復元ポイントのセクションにあります-実際、これらのファイルにはマシンの同じイメージが含まれています。当然、そのようなGFSポイントにはポイントがなく、スペースを占有するだけです。



この状況は、合成GFSを使用している場合にのみ可能です。これを防ぐには、「削除されたアイテムを削除する」オプションを使用します。十分な日数を設定することを忘れないでください。テクニカルサポートでは、オプションが同期間隔よりも短い日数に設定されている場合があります。BCJは、ポイントを作成する前に、ポイントを暴れ回って削除し始めました。



このオプションは既存のGFSポイントには影響しないことにも注意してください。アーカイブをクリーンアップする場合は、手動で行う必要があります。マシンを右クリックして[ディスクから削除]を選択します（表示されるウィンドウで、[GFSフルバックアップの削除]チェックボックスをオンにすることを忘れないでください）。

v.10の新機能-即時コピー

「クラシック」機能を扱ったので、新しい機能に移りましょう。イノベーションは1つですが、非常に重要です。これは新しい操作モードです。







「同期間隔」のようなものはありません。タスクは常に新しいポイントが出現したかどうかを監視し、それらの数に関係なく、それらすべてをコピーします。ただし、ジョブは増分のままです。つまり、メインジョブがVBKまたはVRBを作成した場合でも、これらのポイントはVIBとしてコピーされます。それ以外の場合、このモードで驚くことはありません。標準とGFSの両方の保持は、上記のルールに従って機能します（ただし、ここでは合成GFSのみを使用できます）。

ディスクが回転しています。回転ドライブリポジトリの機能

ランサムウェアウイルスの絶え間ない脅威により、ウイルスが到達できない媒体にデータのコピーを置くことが事実上のセキュリティ標準になっています。 1つのオプションは、ディスクが順番に使用されるロータリーディスクリポジトリを使用することです。1つのディスクが接続されて書き込み可能である間、残りは安全な場所に保存されます。

B＆Rにそのようなリポジトリを操作するように教えるには、リポジトリ設定の[リポジトリ]ステップで、[詳細設定]ボタンをクリックし、適切なオプションを選択します。







その後、VBRは、定期的に存在するチェーンがリポジトリから消えることを期待します。これは、ディスクのローテーションを意味します。 B＆Rは、リポジトリのタイプとジョブのタイプに応じて異なる動作をします。これは、次の表で表すことができ







ます。各オプションを検討してください。

通常のジョブとWindowsリポジトリ

したがって、チェーンを最初のディスクに保存するタスクがあります。ローテーション中に、作成されたチェーンは実際に消えます。タスクは、この損失をなんとかして生き残る必要があります。完全なバックアップを作成することで慰めを見つけます。したがって、各ローテーションは完全なバックアップを意味します。しかし、切断されたディスク上のポイントはどうなりますか？それらは記憶され、保持を計算するときに考慮されます。したがって、タスクで設定されたポイント数は、すべてのディスクに保持する必要のあるポイント数です。次に例を示します



。ジョブは無限増分モードで実行されており、3つの復元ポイントを格納するように構成されています。ただし、2枚目のディスクもあり、週に1回ローテーションします（ディスクが増える場合がありますが、本質は変わりません）。



最初の週に、タスクは最初のディスクにポイントを作成し、余分なディスクをマージします。したがって、ポイントの総数は3つになります。







次に、2番目のディスクを接続します。起動時に、B＆Rはディスクが変更されたことを認識します。最初のディスクのチェーンはインターフェイスから消えますが、それに関する情報はデータベースに残ります。これで、タスクは2番目のディスクに3ポイントを保持します。一般的な状況は次のとおりです。







最後に、最初のドライブを再接続します。新しいポイントを作成する前に、タスクは保持に何があるかを確認します。そして、保持は、3ポイントを保存するように設定されていることを思い出します。その間、ディスク2には3つのポイントがあり（ただし、無効にされ、B＆Rが到達できない安全な場所に保存されます）、ディスク1には3つのポイントがあります（これは接続されています）。これは、保持を超えているため、ディスク1から3つのポイントを安全に削除できることを意味します。その後、タスクは再び完全なバックアップを作成し、チェーンは次のようになります。







保持がポイント数ではなく日数を格納するように構成されている場合、ロジックは変更されません。また、ローテーションされたリポジトリを使用する場合、GFSの保持はまったくサポートされません。

共通のジョブとLinuxリポジトリ\ネットワークストレージ

このオプションも可能ですが、制限が課せられるため、通常はあまりお勧めしません。タスクは、ディスクのローテーションとチェーンの消失に同じように反応し、完全なバックアップを作成します。制限は、トリミングされた保持メカニズムによるものです。



ここでは、ローテーション中に、切断されたディスク上のチェーン全体がB＆Rデータベースから単純に削除されます。注意してください-データベースから、ファイル自体はディスクに残ります。それらをインポートしてリカバリに使用することはできますが、遅かれ早かれ、そのような忘れられたチェーンがリポジトリ全体を埋め尽くすことを推測するのは難しいことではありません。



解決策は、次のページに示されているようにDWORD ForceDeleteBackupFilesを追加することです：www.veeam.com/kb1154..。その後、ジョブは、各ローテーションでジョブフォルダーまたはリポジトリフォルダー（値に応じて）のすべてのコンテンツを削除するだけで開始されます。



ただし、これはエレガントな保持ではなく、すべてのコンテンツの削除です。残念ながら、テクニカルサポートでは、ディスクのルートディレクトリのみがリポジトリとして指定され、バックアップに加えて他のデータも保存されている場合がありました。これはすべて、ローテーション中に破壊されました。



さらに、ForceDeleteBackupFilesを有効にすると、すべてのタイプのリポジトリで機能します。つまり、Windows上のリポジトリでさえ、保持の適用を停止し、コンテンツの削除を開始します。つまり、このようなバックアップストレージシステムには、Windows上のローカルディスクが最適です。

バックアップコピーとWindowsリポジトリ

BCJで物事はさらに面白くなります。本格的な保持があるだけでなく、ディスクを変更するたびに完全なバックアップを作成する必要はありません。これは



次のように機能します。最初のB＆Rは、最初のディスクにポイントの作成を開始します。保持を3ポイントに設定したとしましょう。タスクは無限増分モードで動作し、不要なものをすべて組み合わせます（この場合、GFSの保持はサポートされていないことに注意してください）。







次に、2番目のドライブを接続します。まだチェーンがないため、完全なバックアップを作成し、その後に3つのポイントからなる2番目のチェーンを作成します。







最後に、最初のディスクを再接続します。そして、これが魔法の始まりです。ジョブは完全なバックアップを作成せず、代わりにインクリメンタルチェーンを継続するだけです。







その後、事実上すべてのディスクに独自の独立したチェーンがあります。したがって、ここでの保持は、すべてのディスクのポイント数を意味するのではなく、各ディスクの個別のポイント数を意味します。

バックアップコピーとLinuxリポジトリ\ネットワークストレージ

繰り返しますが、リポジトリがローカルWindowsドライブ上にない場合、すべてのエレガンスが失われます。このスクリプトは、簡単なタスクで上記のスクリプトと同様に機能します。ローテーションごとに、BCJは完全なバックアップを作成し、既存のポイントは忘れられます。空き領域が残らないようにするには、DWORDForceDeleteBackupFilesを使用する必要があります。

結論

そのため、このような長いテキストの結果として、2つのタイプのタスクを検討しました。もちろん、他にもたくさんのタスクがありますが、それらすべてを1つの記事の形式で検討することはできません。読んだ後でも質問がある場合は、コメントに書き込んでください。個人的にお答えさせていただきます。