安全なアプローチは、インベントリのスナップショットを確認し、それらを復旧目標と依存関係に対応付けたうえで、観測可能なゲートを順に確認する、可逆的なパイロットとして保持期間を変更することです。単一のコマンドで済ませるものではありません。
ZFSまたはBtrfsのホームNASでスナップショットスケジュールを運用する場合、実際のリスクは、スナップショット履歴、容量使用量、復旧範囲が現在のニーズに合わなくなることです。現在の識別情報と復旧ポイントを記録し、最も影響の少ない判別から始め、別の変数を変更する前に合否結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが1つしかなく、それが危険にさらされる場合は停止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーションの境界に達した時点でのみ完了します。
スケジュール、所有者、実際のスナップショットを棚卸しする
すべてのスナップショットジョブ、データセットまたはサブボリューム、頻度、命名規則、保持ルール、所有者、最後に成功した実行を一覧にします。次に、実際に存在するスナップショットを一覧にします。差異から、無効化されたスケジュール、手動で保持された例外、重複するツール、またはポリシーがもはや管理していないスナップショットが明らかになります。
スナップショットはファイルシステムの特定時点のビューですが、ライブデータが変化すると、その容量コストは増加します。Princetonのストレージガイドでは、スナップショットの容量動作と、ライブツリーに表示されなくなった場合でも、保持されたブロックが使用可能容量を消費する理由について説明しています。
棚卸し中は何も削除しないでください。作成者、レプリケーション上の役割、復元価値が判明するまでは、不明なスナップショットを保護対象として扱います。すべてのスナップショットが文書化されたポリシーまたは明示的な例外に属していれば、この段階は合格です。
各階層を復旧に関する質問に対応付ける
各データセットについて、答えられる必要がある復旧に関する質問を書き出します。たとえば、今日のファイル変更を元に戻す、先週削除したフォルダーを復旧する、アプリの更新をロールバックする、オフサイトレプリケーションの初期データを作成するといった質問です。時間単位、日単位、週単位、月単位の階層は、実際の復旧ニーズに合う場合にのみ構築します。
スケジュール上の名称ではなく、成功した復旧ポイントを数えます。3日前から停止している高頻度の階層は、短い復旧目標を満たせません。また、頻繁に変更されるアプリデータの月次スナップショットは、古いものであっても粗すぎる可能性があります。不変バックアップやホスト外のバックアップは、ローカルスナップショットが独立したコピーではないため、別途扱います。
誰も復元事例を挙げられない提案階層は、計画から削除します。重要なデータセットに、その変更速度に合ったスナップショットまたはバックアップがない場合は、カバレッジを追加します。ただし、不足しているバックアップをローカルスナップショットの無期限保持で補おうとしてはいけません。
削減前に容量とレプリケーションの依存関係を確認する
同じ時刻に、スナップショットが保持している容量、ライブで参照されているデータ、プールの空き容量、最近の変更速度を測定します。ZFSでは、スナップショットごとの使用容量と参照容量を確認します。Btrfsでは、サブボリュームの一覧、信頼できる場合はqgroupのデータ、ファイルシステムの割り当てを比較します。スナップショットに見えるサイズだけから、回収できる容量を予測しないでください。
保持期間を変更する前に、スナップショットまたはごみ箱がNAS容量を使用しているかを判断するためのZimaSpaceのワークフローを使用します。これにより、表示されているフォルダーの推定値を、スナップショットやごみ箱レイヤーが保持するブロックと取り違えるのを防げます。
増分レプリケーションのベース、受信再開の依存関係、ブックマーク、クローン、現在のメンテナンス用のロールバックポイントとして使用されているスナップショットを特定します。削除によって完全な再シードが必要になったり、クローンが壊れたりする場合は、まずレプリケーション計画を変更し、新しいチェーンが検証されるまで共有ベースを保持します。
新しいルールを試験導入し、復旧が引き続き機能することを証明する
新しい保持ルールを、リスクの低い1つのデータセットに適用するか、ツールがドライランに対応している場合は削除リストをプレビューします。残るスナップショットの名前とタイムスタンプを保存し、確定する前に、最も古い復旧要件と最も新しい復旧要件が引き続き満たされていることを確認します。
削除後は、空き容量の変化、次回のスケジュール済みスナップショット、増分レプリケーション、最近のファイル1つと古いファイル1つの復元を確認します。容量を節約できても、送信チェーンを壊したり、アップグレード前の唯一のポイントを削除したりするポリシーは失敗です。
2回のスケジュールサイクルで意図した階層が作成され、スナップショットの欠落を検知するアラートが機能することを確認してから、そのルールを正式採用します。レプリケーションがフルサイズになった場合、復旧インターフェースからスナップショットが消えた場合、または残った履歴が記述した復旧に関する質問を満たさなくなった場合は、停止して以前のポリシーに戻します。
サポートとヒント
もっと読む

新しいストレージへリポジトリを移行するためのBorg Backup移行ガイド
Borgリポジトリを一貫性のある1つのオブジェクトとして移行します。書き込みを停止し、鍵とIDを保持し、リストアを検証してから、移行元を維持したままクライアントを更新します。

Resticリポジトリのメンテナンスワークフロー:チェック、プルーニング、コンパクト化、復元テスト
Resticには個別のcompactコマンドはありません。pruneが再パッキングを実行します。ロックと空き容量を確保し、完了後に再確認して、最後に分離環境で復元テストを行ってください。

壊れた、または放置されたバックアップ履歴からのTime Machine NAS復元ガイド
古いバンドルはそのままにしてください。修復するか新しいチェーンを作るかを決める前に、NASアクセス、宛先ID、イメージの損傷、放棄された履歴を切り分けてください。

