なぜ増分バックアップがフルバックアップとほぼ同じサイズになるのですか？

ソースが多くのブロックを書き換えた場合、バックアップエンジンが以前の変更ベースラインを失った場合、保護範囲が変わった場合、または読んでいる数値が現在の増分ペイロードではなくリポジトリの成長である場合、増分バックアップはほぼフルバックアップと同じ大きさになることがあります。復元ポイントの削除、ジョブのリセット、新しいフルバックアップの開始前にこれらの可能性を個別に診断してください。

まずどの数値が大きすぎるか特定する

「増分がフルサイズである」は4つの異なる測定値を指すことがあります。これらは互換性がなく、それぞれ異なる原因を示します。

1回の実行で4つの数値すべてを記録します。8 TBをスキャンして12 GBを転送するジョブは、7 TBを転送・書き込みするジョブとは大きく異なります。

ワークロードが本当にそれほど変化したか確認する

ボリュームレベルのバックアップソフトウェアは、編集されたドキュメントのユーザーが見るサイズではなく、変更されたストレージブロックを保護します。小さな編集でも大きなブロックが変わることがあり、稼働中のサービスはログ、インデックス、データベース、キャッシュ、OSファイルを継続的に変更します。最近の管理者の議論では、1バイトの変更が含まれるバックアップブロックを次の増分に含める理由が説明されています。

大きな処理がこれらのイベントのいずれかに続いて発生したか確認してください：

• データベースのメンテナンス、圧縮、再インデックス作成、またはトランザクションログの増加
• 仮想マシンの更新、スワップ活動、ウイルススキャン、またはゲストのデフラグメンテーション
• メディアのトランスコーディング、写真ライブラリの再インデックス作成、サムネイルの再生成、またはメタデータの書き換え
• 大きなアーカイブ、暗号化コンテナ、メールボックス、またはディスクイメージファイルのインプレース書き換え
• ファイルシステムのバランス調整、プールの拡張、ブロックの再配置、またはスナップショットの統合

バックアップウィンドウをアプリケーションログやストレージ書き込みグラフと比較します。ソースの書き込みが同時に増加していれば、バックアップは障害ではなく実際の差分を報告している可能性があります。

変更追跡がベースラインを失っていないか確認する

ブロック追跡システムは現在の状態を既知の以前の変更IDと比較します。スナップショットの復元、追跡のリセット、無効な変更マップ、ホストの移行、前回のセッションの失敗、またはバックアップジョブの再作成はその関係を壊す可能性があります。次の実行では安全なベースラインを確立するためにソース全体を読み取りまたは保護することがあります。実用的なCBT回復の手順では、変更追跡のリセットは通常の増分が再開される前に新しいアクティブフルを必要とすることがあると説明しています。

次のようなログ用語を探す CBTリセット, 変更IDが無効, ジャーナルがラップ, ベースラインが欠落, 新しいチェーン、または フルスキャンが必要ログを保存せずに追跡を繰り返しリセットしないでください。繰り返しのリセットは元のトリガーを隠し、繰り返しフルサイズの実行を引き起こす可能性があります。

バックアップの範囲とソースの識別が変更されていないことを確認する

ジョブは依然として増分とラベル付けされていても、以前とは異なるソースを保護している場合があります。含まれるパスの下に新しいマウントがある、ファイルシステムのサイズ変更、デバイス識別子の変更、異なるホスト名、新しい共有パス、または拡張された含めるルールにより、エンジンは新しい内部構造を構築することがあります。コミュニティのトラブルシューティングでは、追加のボリュームやマウントポイントが変更されていないように見えるジョブに取り込まれることがあると示されています。

前回と現在のジョブ定義をエクスポートして比較する：

• 保護されたルート、マウント、共有、データセット、および仮想ディスク
• ホスト、ボリューム、およびファイルシステムの識別子
• 含めるパターンと除外パターン
• スナップショットプロバイダーと整合性モード
• 暗号化、圧縮、および重複排除の設定

ソースが意図的に拡張された場合、1回のフルサイズの増分が予想されます。以降のすべての実行が大きいままであれば、診断を続けてください。

バックアップの粒度がファイルに適しているかどうかを判断する

ファイルレベル、ブロックレベル、およびコンテンツ定義チャンクエンジンは、編集、名前変更、書き換えに対して異なる反応を示します。ブロック重複排除システムはフォルダが移動された場合にメタデータのみを記録することがありますが、より単純なファイルレベルエンジンは移動されたパスを削除されたファイルと新しいファイルとして扱うかもしれません。あるブロックベースの例では、ディレクトリの名前変更は、変更されていないすべてのデータブロックを再アップロードせずにパスメタデータを変更します。

大きな可変ファイルは特別な注意が必要です。データベース、VMイメージ、暗号化ボールト、またはモノリシックアーカイブは、小さな内部変更を検出するために完全に読み取られることがあり、最終的に保存される量はチャンクの境界と重複排除に依存します。大規模データベースの議論では、数ギガバイトのデータベースファイルが変更されたチャンクのみが転送される場合でも完全に読み取られることがあることを説明しています。

アプリケーションが一貫したエクスポート、トランザクションログバックアップ、またはアプリケーション対応バックアップ方法を提供している場合は、そのワークフローとライブのモノリシックファイルのバックアップを比較してください。

大きな増分を合成フルおよび保持アクティビティから分離する

合成フルは、以前のフルバックアップと後の増分からリポジトリ内で組み立てられます。これにより、ソース全体を再度読み込まずにフルサイズの復旧オブジェクトを作成できます。バックアップタイプの概要では、合成フルバックアップは既存のフルと増分チェーンから構築されることを説明しています。

古い復元ポイントがロックされたまま、プルーニングが実行されていない、削除されたスナップショットがまだチャンクを参照している、またはマージが一時的に作業スペースを必要とする場合、リポジトリの成長も高いままであることがあります。1つのディレクトリリストだけで判断せず、ジョブのタイムラインを確認してください。

バックアップチェーンを再構築する前に1変数テストを実行します。

1. 現在のジョブ構成、詳細ログ、復元ポイントリスト、およびリポジトリ容量を保存します。
2. 静かなテスト時間帯を選び、安全であれば既知の高書き込みアプリケーションを一時停止します。
3. 小さなテストファイルを1つ作成し、一度変更してから、設定を変更せずに同じ増分ジョブを実行します。
4. スキャンされたバイト数、転送されたバイト数、書き込まれたバイト数、重複排除されたバイト数、および保持されたバイト数を記録します。
5. ソースの変更なしで2回目の増分バックアップを実行します。

両方の制御された実行がフルサイズのままであれば、トラッキング、ソースの識別、またはジョブチェーンの構成に注目してください。サイズが小さくなった場合は、変更率が戻るまで通常のワークロードを一度に一つずつ復元します。これにより、バックアップエンジンの動作とアプリケーションの変動を区別できます。

原因に合わせた修正を行う

宛先のサイズを決める際は、バージョン履歴と保持期間によりリポジトリがアクティブなソースより大きくなることを覚えておいてください。同じ区別はZimaSpaceのバージョンとバックアップ履歴のためのNAS容量計画ガイドでも説明されています。

毎回新しいベースラインが作成される場合は停止してエスカレーションしてください

ログに繰り返しベースラインの無効化が表示されたり、ソース識別子が予期せず変わったり、復元ポイントが消えたり、リポジトリメタデータが破損を報告したり、変更なしのテストでもほぼ全ソースを書き込む場合は、チェーンを削除する前にエスカレーションしてください。少なくとも1つの代表的な復元がテストされるまで現在の復元ポイントを保持してください。ジョブを再作成すると証拠が隠され、唯一の回復可能な履歴が失われることがあります。

よくある質問

大きなフォルダの移動や名前変更でフルサイズの増分が発生することはありますか？

バックアップエンジンによります。コンテンツまたはブロック重複排除ツールは既存データを再利用し、主にパスメタデータを保存することがありますが、ファイルレベルのツールは移動したファイルを新しいオブジェクトとして扱うことがあります。大規模なデータセットを再編成する前に、代表的なフォルダで製品をテストしてください。

シンセティックフルはNASがソース全体を再アップロードしたことを意味しますか？

必ずしもそうとは限りません。シンセティックフルは通常、リポジトリ内の既存データから組み立てられます。ソース読み取りとネットワーク転送のカウンターをリポジトリ書き込みカウンターと比較して、どこで処理が行われたかを確認してください。

なぜ小さなデータベースの編集で大きな増分が発生するのですか？

アプリケーションは、目に見えるレコードの変更が小さくても、多くのストレージブロックを書き換えたり、データベースを圧縮したり、ログをローテーションしたり、チャンクの境界を変更したりすることがあります。アプリケーション整合性のあるバックアップやエクスポートを使用し、その差分をライブのデータベースファイルと比較してください。