Veeam B&R ストレージ ポリシー - テクニカル サポートとともにバックアップ チェーンを解きほぐします

ブログ読者の皆様、こんにちは！ 私たちは部分的にはすでによく知っています - 私の英語の投稿は私の親愛なる同僚によって翻訳されてここに掲載されています ポーラフクロウ。 今回私はロシア語を話す聴衆に直接話しかけることにしました。

デビュー作として、できるだけ幅広い聴衆が興味を持ち、詳細な検討が必要なトピックを見つけたいと思いました。 ダニエル・デフォーは、死と税金がすべての人に待ち受けていると主張した。 私としては、サポート エンジニアなら誰でも、復旧ポイントのストレージ ポリシー (より単純に言えば、保持) について疑問を抱くと言えます。 私は 4 年前、初級エンジニアとしてリテンションの仕組みについて説明し始めました。現在もスペイン語とイタリア語を話すチームのリーダーとして説明を続けています。 第 XNUMX レベル、さらには第 XNUMX レベルのサポートの同僚も、定期的に同じ質問に答えていると思います。

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

バックアップジョブ

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

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

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

「逆増分」モード (オプション 2) の保持も非常に簡単です。 この場合、最新のポイントは完全なバックアップであり、その後に一連のいわゆるロールバック (VRB 拡張子を持つファイル) が続くため、保持を適用するには、最も古いロールバックを削除するだけで十分です。 状況は同じで、セッション直後はポイント数が設定値を 1 超えますが、その後は希望の値に戻ります。

逆増分モードでは、定期的な完全バックアップ (オプション 4) を有効にすることもできますが、本質は変わりません。 はい、完全な復元ポイントがチェーンに表示されますが、それでも最も古いポイントを一度に XNUMX つずつ削除するだけです。

いよいよ興味深い部分に入ります。 増分バックアップを有効にし、オプション 3 または 4 (または両方を同時に) も有効にすると、タスクは「アクティブ」または合成方式を使用して定期的な完全バックアップの作成を開始します。 完全バックアップの作成方法は重要ではありません。完全バックアップには同じデータが含まれ、増分チェーンは「サブチェーン」に分割されます。 この方法はフォワード インクリメンタルと呼ばれ、お客様からの質問のかなりの部分を引き起こすのは彼です。

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

この概念を図で表現してみます。 保持期間が 3 ポイントに設定されており、月曜日に完全バックアップを作成してタスクが毎日実行されるとします。 この場合、保持は合計ポイント数が 10 に達したときに適用されます。

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

アイデアが明確であれば、自分で定着率を計算してみることをお勧めします。 次の条件を考えてみましょう: タスクは木曜日に初めて起動されます (当然、完全バックアップが作成されます)。 このタスクは、水曜日と日曜日に完全バックアップを作成し、8 つの回復ポイントを保存するように設定されています。 保持が初めて適用されるのはいつですか?

この質問に答えるには、一枚の紙を曜日ごとに描き、毎日どのポイントが作成されるかを書き留めることをお勧めします。 答えは明らかになるだろう

答え

説明: 答えを得るには、「保持はいつ適用されるのか」を自問してください。 答えは、最初の 3 点 (VBK、VIB、VIB) を削除でき、チェーンの残りの部分が必要な 8 点を下回らない場合です。 合計11ポイントを獲得したとき、つまりXNUMX週目の日曜日にそれができることが明らかになります。

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

最後に、「以前のバックアップ チェーンをロールバックに変換する」オプション (番号 5 のマーク) は考慮しませんでした。 このオプションは、単純に合成バックアップを有効にしたいために「自動的に」アクティブ化するクライアントを混乱させることがあります。 一方、このオプションは非常に特殊なバックアップ モードを有効にします。 詳細には触れずに、製品開発の現段階では、「以前のバックアップ チェーンをロールバックに変換する」というのは時代遅れのオプションであり、いつそれを使用すべきか、単一のシナリオが思いつきません。 その価値は非常に疑わしいため、しばらくの間、アントン・ゴステフ自身がフォーラムを通じて、その有用な使用例を送ってほしいと呼びかけました（もし持っているなら、コメントに書いてください、私は非常に興味があります）。 何もない場合 (おそらくそうなると思います)、このオプションは将来のバージョンで削除される予定です。

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

問題

実際にその仕組みを理解することは別として、増分モードの使用時に発生する問題のほとんどは、通常、完全バックアップに関連しています。 このモードでは定期的な完全バックアップが必要です。そうしないと、リポジトリがいっぱいになるまでポイントが蓄積されます。

たとえば、完全バックアップが作成されることは非常にまれです。 タスクが 10 ポイントを保存するように設定されており、完全バックアップが月に 50 回作成されるとします。 ここでの実際のポイント数が、表示されているポイント数よりも大幅に大きくなるのは明らかです。 または、タスクは通常、無限増分モードで動作し、49 ポイントを保存するように設定されています。 その後、誰かが誤って完全バックアップを作成してしまいました。 以上です。今後、タスクはフル ポイントが XNUMX 増分を蓄積するまで待機し、その後保持を適用して無限フル モードに戻ります。

完全バックアップが定期的に作成されるように設定されているにもかかわらず、何らかの理由で作成されない場合もあります。 ここでは最も一般的な理由をリストします。 一部のクライアントは、「後で実行」スケジュール オプションを使用し、ジョブをチェーンで実行するように設定することを好みます。 この例を考えてみましょう。毎日実行され、日曜日に完全バックアップを作成する 3 つのジョブがあります。 最初のタスクは 22.30 時 10 分に開始され、残りのタスクは連鎖的に開始されます。 増分バックアップには 23.00 分かかるため、22.30 時までにすべてのジョブが完了します。 ただし、完全バックアップには 23.30 時間かかるため、日曜日には次のことが起こります。最初のタスクは 23.30:00.30 から XNUMX:XNUMX まで実行されます。 次はXNUMX時半からXNUMX時XNUMX分まで。 しかし、XNUMX 番目のタスクは月曜日に開始されます。 完全バックアップは日曜日に設定されているため、この場合はバックアップが実行されません。 タスクは完全バックアップが保存期間を適用するまで待機します。 したがって、「後で実行」オプションを使用する場合は注意するか、まったく使用しないでください。ジョブを同時に開始するように設定し、リソース スケジューラにそのジョブを実行させるだけです。

難しいオプション「削除済みアイテムを削除」

「ストレージ」→「詳細設定」→「メンテナンス」タスクの設定を確認すると、「削除されたアイテムのデータを次の時間に削除する」というオプションが表示されます。このオプションは日数でカウントできます。

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

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

リテンションを適用する時期ですが、7 台の車には 4 ポイントがあり、もう XNUMX 台には XNUMX しかありません。ここでリテンションが適用されますか? 答えは「はい、そうなります」です。 少なくとも XNUMX つのオブジェクトがバックアップされている場合、B&R はポイントが作成されたとみなします。

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

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

これらの詳細を理解したら、最後に「削除済みアイテムのデータをその後削除する」オプションを検討できます。 特定のマシンが X 日間バックアップされなかった場合、そのマシンのすべてのポイントが削除されます。 この設定はエラーには対応しないことに注意してください (試してみましたが、機能しませんでした)。 マシンをバックアップしようとすることさえあってはなりません。 このオプションは便利なので、常に有効にしておく必要があると思われます。 管理者がタスクからマシンを削除した場合、しばらくしてから不要なデータのチェーンを消去するのが合理的です。 ただし、カスタマイズには規律と注意が必要です。

実際の例を示しましょう。いくつかのコンテナがタスクに追加され、その構成は非常に動的でした。 RAM の不足により、B&R サーバーで検出されない問題が発生していました。 タスクが開始され、マシンのバックアップを作成しようとしましたが、3 台を除き、その時点ではコンテナーには存在していませんでした。 多くのマシンでエラーが発生したため、B&R はデフォルトで「問題のある」マシンのバックアップをさらに XNUMX 回試行する必要があります。 RAM に問題が絶えず発生したため、この試みは数日間続きました。 見つからない VM のバックアップを作成する試みが繰り返し行われることはありませんでした (VM が存在しないことはエラーではありません)。 その結果、繰り返し試行中に「削除済みアイテムの削除」条件が満たされ、マシン上のすべてのポイントが削除されました。

これに関して、次のことが言えます。タスクの結果に関する通知が設定されており、さらに良いのは、Veeam ONE との統合を使用している場合、おそらくこのようなことは起こらないでしょう。 週に XNUMX 回 B&R サーバーを参照して、すべてが機能していることを確認する場合は、バックアップの削除につながる可能性のあるオプションを拒否することをお勧めします。

v.10 の新機能

私たちがこれまで話してきたことは、B&R の多くのバージョンに存在していました。 これらの仕事の原則を理解したところで、記念日の「トップXNUMX」に何が追加されたかを見てみましょう。

毎日の保持

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

アイデアは名前から明らかです。保持には設定された日数が保存されますが、毎日のポイント数は重要ではありません。 この場合、次の点に注意する必要があります。

• 現在の日は保持期間の計算時に考慮されません。
• タスクがまったく機能しなかった日もカウントされます。 不規則に動作するタスクのポイントを誤って失わないように、この点に留意する必要があります。
• 回復ポイントは、作成が開始された日からカウントされます (つまり、タスクが月曜日に作業を開始し、火曜日に終了した場合、これは月曜日からのポイントです)

それ以外の場合、タスクごとに保持を適用するための原則も、選択したバックアップ方法によって決まります。 同じ増分法を使用して別の計算タスクを試してみましょう。 保持期間が 8 日に設定されており、タスクが 6 時間ごとに実行され、水曜日に完全バックアップが作成されるとします。 この場合、タスクは日曜日には機能しません。 ジョブは月曜日に初めて実行されます。 保持はいつ適用されますか?

答え
いつものように、サインを描くのが最善です。 ここでは 4 日あたりのポイント数は重要ではないので、タスクを単純化して、毎日作成されるすべてのポイントを描画しません。 私たちにとって重要なのは、最初の月曜日と水曜日には最初のポイントが完全バックアップになり、それ以外の日にはタスクによって単純に XNUMX つの増分ポイントが作成されるということだけです。

月曜日の完全バックアップとその増分を削除することで、保持期間が適用されることを明確にします。 それはいつ起こりますか? チェーンの残りに 8 日が含まれる場合。 同時に、今日の日は数えませんが、逆に日曜日を数えます。 したがって、答えは第 XNUMX 週の木曜日になります。

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

v.10 より前は、Grandfather-Father-Son (GFS) ストレージ方式は、バックアップ コピー ジョブとテープ コピー ジョブでのみ使用できました。 これで定期的なバックアップが可能になりました。

今回のテーマとは関係ありませんが、新機能が3-2-1戦略からの脱却を意味するものではないとは言えません。 メイン リポジトリにアーカイブ ポイントが存在しても、その信頼性にはまったく影響しません。 GFS はスケールアウト リポジトリと組み合わせて使用​​され、これらのポイントを S3 および同様のストレージに配布することが理解されています。 これを使用しない場合は、引き続きプライマリ ポイントとアーカイブ ポイントを別のリポジトリに保存することをお勧めします。

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

GFS の本質はいくつかの点に要約できます (GFS は他のタイプのタスクでは動作が異なることに注意してください。これについては後ほど説明します)。

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

例: ジョブは、水曜日のバックアップを使用して毎週の GFS を保存するように構成されています。 タスクは毎日実行されますが、完全バックアップは金曜日にスケジュールされています。 この場合、GFS 期間は水曜日に開始され、タスクは適切な時点を待機し始めます。 それは金曜日に登場し、GFSの旗が付けられます。

• 複数の期間が一度に含まれる場合 (たとえば、週次と月次)、B&R は (スペースを節約するために) 同じポイントを複数の間隔の GFS として使用できる方法を使用します。 フラグは若いものから順番に割り当てられます。

例: 週次 GFS は水曜日に設定され、月次 GFS は月の最終週に設定されます。 タスクは毎日実行され、月曜日と金曜日に完全バックアップが作成されます。

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

それでは、月の最終週に何が起こるかを見てみましょう。 月次 GFS 間隔は月曜日に開始されますが、ジョブは XNUMX つの VBK を月次および週次の両方の GFS ポイントとしてマークしようとするため、月曜の VBK は GFS としてマークされません。 この場合、定義により月次検索にもなり得るため、検索は週次検索から始まります。

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

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

作業についての説明が必要になることが多い、もう 10 つのタイプのタスク。 まず、イノベーションのない「古典的な」作業方法 v.XNUMX を見てみましょう。

シンプルな保存方法

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

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

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

GFSを利用した保存方法

BCJではアーカイブポイントも保管できます。 これは、同じ [ターゲット] タブの復旧ポイント数の設定のすぐ下で構成されます。

GFS ポイントは 3 つの方法で作成できます。XNUMX つはセカンダリ リポジトリ上のデータを使用して合成する方法、もう XNUMX つは完全バックアップをシミュレートしてプライマリ リポジトリからすべてのデータを読み取る方法です (XNUMX のマークが付いたオプションで有効になります)。 どちらの場合でも保持率は大きく異なるため、個別に検討します。

合成GFS

この場合、GFS ポイントは指定された日に正確に作成されません。 代わりに、GFS ポイントの作成がスケジュールされていた日の VIB が完全バックアップとマージされるときに、GFS ポイントが作成されます。 時間が経つため時々誤解を招くことがありますが、GFSポイントはまだありません。 そして、ドットがまだ表示される日を予測できるのは、テクニカル サポートの強力なシャーマンだけです。 実際、魔法は必要ありません。設定されたポイント数と同期間隔 (毎日作成されるポイントの数) を確認するだけです。 この例を使用して自分で計算してみてください。タスクは 7 ポイントを保存するように設定されており、同期間隔は 12 時間です (つまり、2 日あたり 7 ポイント)。 現時点では、チェーンにはすでに XNUMX つのポイントがあり、今日は月曜日であり、GFS ポイントの作成はこの日に予定されています。 何日に作成されるのでしょうか？

答え
ここでは、チェーンが時間の経過とともに日々どのように変化するかを説明する方が適切です。

したがって、月曜日には、チェーン内の最後の増分が GFS としてマークされますが、他に目に見える変化は発生しません。 毎日、タスクによって 2 つの新しいポイントが作成され、その保持によりチェーンが容赦なく前進します。 最後に、木曜日に、同じ増分に保持を適用します。 このセッションは、タスクがチェーンから必要なブロックを「プル」し、新しい完全なポイントを作成するため、通常よりも時間がかかります。 今後、チェーンにはメイン チェーンの 8 ポイント + GFS の 7 ポイントが存在します。

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

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

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

したがって、14 週目の終わりまでに、チェーンには合計 7 ポイントが存在します。 6 週目では、このタスクにより 15 ポイントが作成されました。 これが単純なタスクであれば、保持はすでに適用されているはずです。 ただし、これは GFS 保持を備えた BCJ であるため、GFS ポイントはカウントされません。つまり、GFS ポイントは XNUMX つしかなく、まだ保持を適用できません。 XNUMX 週目では、GFS フラグを使用して別の完全バックアップを作成します。 XNUMX ポイントですが、これもカウントしません。 そして最後に、第 XNUMX 週の火曜日に増分を作成します。 ここで、最初の週のチェーン増分を削除すると、増分の合計数は確立された保持期間を満たします。

上で述べたように、この方法では完全バックアップを定期的に作成することが非常に重要です。 たとえば、メインの保持期間を 7 日間に設定し、年間ポイントが 1 のみである場合、増分が 7 日間よりはるかに多く蓄積されることは容易に想像できます。そのような場合は、次の合成方法を使用することをお勧めします。 GFS。

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

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

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

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

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

この状況は、合成 GFS を使用する場合にのみ発生します。 これを防ぐには、「削除済みアイテムを削除」オプションを使用します。 適切な日数に設定することを忘れないでください。 技術サポートでは、このオプションが同期間隔よりも日数未満に設定されているケースを確認しています。BCJ は暴走し始め、ポイントを作成する前にポイントを削除してしまいました。

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

イノベーション v.10 – 即時コピー

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

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

ディスクが回転しています。 ローテーションドライブを備えたリポジトリの機能

ランサムウェア ウイルスの絶え間ない脅威により、ウイルスが到達できない媒体にデータのコピーを保存することが事実上のセキュリティ標準となっています。 XNUMX つのオプションは、ディスク ローテーション リポジトリを使用することです。この場合、ディスクは一度に XNUMX つずつ使用されます。XNUMX つのディスクが接続されて書き込み可能である間、残りのディスクは安全な場所に保存されます。
B&R にそのようなリポジトリを操作できるようにするには、リポジトリ設定の [リポジトリ] ステップで [詳細設定] ボタンをクリックし、適切なオプションを選択する必要があります。

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

それぞれのオプションを検討してみましょう。

通常のタスクと Windows リポジトリ

したがって、チェーンを最初のディスクに保存するタスクがあります。 回転中、作成されたチェーンは実際に消滅するため、タスクは何らかの方法でこの損失を乗り越える必要があります。 彼女は完全バックアップを作成することに慰めを感じています。 したがって、各ローテーションは完全なバックアップを意味します。 しかし、切断されたディスク上のポイントはどうなるでしょうか? これらは記憶され、保持率を計算するときに考慮されます。 したがって、タスク内の設定されたポイント数は、すべてのディスク上に保持する必要があるポイントの数になります。 以下に例を示します。

ジョブは無限増分モードで実行され、3 つの復元ポイントを保存するように構成されています。 ただし、XNUMX 番目のディスクもあり、週に XNUMX 回ローテーションします (さらにディスクがある可能性がありますが、本質は変わりません)。

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

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

最後に、最初のドライブを再接続します。 新しいポイントを作成する前に、タスクは保持に何があるかを確認します。 そして、リテンションは 3 ポイントを保存するように設定されていることを思い出してください。 一方、ディスク 3 には 2 つのポイントがあり (ただし、切断されており、B&R が到達できない安全な場所に保管されています)、ディスク 3 には 1 つのポイントがあります (ただし、これは接続されています)。 したがって、保持期間を超えているため、ディスク 3 から 1 つのポイントを安全に削除できます。 その後、タスクは完全バックアップを再度作成し、チェーンは次のようになります。

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

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

このオプションも可能ですが、制限が課されるため、一般にはあまり推奨されません。 タスクは、完全バックアップを作成することにより、ディスクの回転とチェーンの消失に同じ方法で応答します。 この制限は、切り詰められた保持メカニズムに関係しています。

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

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

ただし、これはエレガントな保持ではなく、すべてのコンテンツのクリーニングです。 残念ながら、テクニカル サポートでは、リポジトリが単にディスクのルート ディレクトリであり、バックアップに加えて他のデータが配置されているケースに遭遇しました。 これらはすべて回転中に破壊されました。

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

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

BCJ ではさらに面白くなります。 本格的な保存機能があるだけでなく、ディスクを交換するたびに完全バックアップを作成する必要はありません。 それはこのように動作します：

まず、B&R は最初のディスク上でポイントの作成を開始します。 リテンションを 3 ポイントに設定したとしましょう。 タスクは無限増分モードで動作し、不要なものはすべてマージされます (この場合、GFS 保持はサポートされていないことに注意してください)。

次に、XNUMX 番目のディスクを接続します。 まだチェーンが存在しないため、完全バックアップを作成し、その後 XNUMX 点の XNUMX 番目のチェーンを作成します。

最後に、最初のドライブを再接続します。 そして、ここからが魔法の始まりです。タスクは完全バックアップを作成するのではなく、単に増分チェーンを継続するだけだからです。

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

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

繰り返しますが、リポジトリがローカル Windows ドライブ上にない場合、すべての優雅さは失われます。 このスクリプトは、上記の単純なタスクと同様に機能します。 ローテーションごとに、BCJ は完全なバックアップを作成し、既存のポイントは無視されます。 空き領域がなくなってしまわないようにするには、DWORD ForceDeleteBackupFiles を使用する必要があります。

まとめ

このように長い文章を書いた結果、XNUMX 種類のタスクを検討しました。 もちろん、他にも多くのタスクがありますが、それらすべてを XNUMX つの記事の形式で検討することはできません。 読んだ後でも質問がある場合は、コメントに書いてください。喜んで個別にお答えします。

出所： habr.com