はい、同じタイムスタンプ時点のデータセットの使用量、参照量または論理サイズ、スナップショットが保持する領域、プールの空き領域を比較することで区別できます。
この判断が重要になるのは、NASが、表示されるフォルダーの内容量よりもはるかに少ない空き容量しか報告しない場合です。競合する2つの状態は、ライブデータセットの割り当てと、スナップショットだけによって保持されているブロックです。保存済みの構成と破棄可能なデータから始め、一度に1つの分岐だけを確認し、データ損失、権限、可用性のリスクが高まる場合は中止してください。
スナップショットとライブファイルの容量判断の前提条件を定義する
変更を加える前に、ソフトウェアとファームウェアのバージョン、デバイス識別情報、マウントパスまたはネットワークパス、空き容量、権限、観測された症状など、環境を記録します。ベースラインには、NASが表示されるフォルダーの内容量よりもはるかに少ない空き容量を報告する状態を再現できるだけの詳細を残す必要があります。
最初の候補はライブデータセットの割り当てです。2番目は、スナップショットだけによって保持されているブロックです。現在のOpenZFSの容量プロパティは、テストで使用する仕組みまたはコマンドの境界を定義しますが、この特定のホームサーバーでの観測に置き換わるものではありません。
判別テストを実行する前に、合格条件と中止条件を記述します。合格とは、一方の分岐が予測する証拠が変化し、無関係なサービスは変わらないことです。不合格の場合は、推測に基づく修正を連鎖的に行うのではなく、保存済みの状態に戻せなければなりません。
元の要件を下げずに主張を検証する
次の判別テストを使用します。プールとデータセットのアカウンティングを記録し、破棄可能な大容量ファイルを1つ削除してから、スナップショットを破棄せずに前後を比較します。結果を変更した変数に帰属できるよう、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。
ZFSの割り当てアカウンティングを使用して、2つの分岐を実際に分離できるフィールドを選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、レイテンシ、転送バイト数、権限、復旧状態を取得します。テスト対象が識別情報、耐久性、アプリケーション状態に関する主張である場合、コマンドが正常終了しただけでは不十分です。
再起動、再接続、再マウント、またはキャッシュのクリアが元の条件の一部である場合は、そのイベントの後にテストを1回繰り返します。初回実行が破壊的である場合、または環境を復元できない場合は中止し、代わりに破棄可能なコピーで再現してください。
zfs list -o name,used,refer,usedbysnapshots,usedbydataset,usedbychildren
合格、不合格、例外の結果を解釈する
合格:スナップショットが引き続きブロックを参照しているため、使用量は維持されたまま、参照量が減少します。結論が普遍的な主張にならないよう、合格した正確なバージョン、識別情報、ワークロードを記録し、条件付きのものとして扱います。
不合格:参照量と使用量の両方が高いままであるか、別のデータセット、クローン、予約、またはメタデータの割り当てが容量を所有しています。ネットワーク、メモリ、権限、ソースの整合性が両方の分岐に影響する可能性があるため、不合格は自動的に反対の分岐を証明するものではありません。エスカレーションする前に、これらの共通依存要素を切り分けます。
例外または曖昧な結果:削除を中止し、クリーンアップの前にすべてのデータセット、スナップショット、クローン、予約を把握します。復元可能なコピーが存在するまで、ログを保持し、修復、整理、破棄、再パーティション、再帰的な所有権変更のコマンドを実行しないでください。
元のワークロードで判断を確認する
観測された分岐に対応するアクションを適用し、その後、縮小した代替条件ではなく、元の条件を再実行します。スナップショットが引き続きブロックを参照しているため、使用量が維持されたままライブの参照量が減少する状態が、2サイクル、または該当する再起動、スリープ、中断、負荷遷移をまたいで確認できた場合にのみ、判断は有効です。
イミュータブルバックアップのウィンドウを使用して、最も近い依存ワークフローを確認します。ただし、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、復旧ポイントでは、以前のアクセスとタイミングが維持されなければなりません。
中止の境界は明確です。参照量と使用量の両方が高いままであるか、別のデータセット、クローン、予約、またはメタデータの割り当てが容量を所有している場合は、最後に検証済みの構成へ戻し、証拠を保持します。その分岐が再現可能な場合に限り、より詳細なプラットフォームまたはハードウェアのテストへエスカレーションしてください。
目的の結果が得られたら、バックアップ検証の頻度と比較し、リスクが隣接するサービスへ移らないようにします。新たなバックアップ、識別情報、タイムアウト、または可用性の障害が発生した場合、目的のテストが成功していても、変更としては失敗です。
よくある質問
スナップショットとライブファイルの容量について、残る検索課題は通常、「ファイルを削除してもプールの空き容量が増えないのはなぜか」、「logicalusedは物理容量と同じか」、「削除前にスナップショットの容量を予測できるか」です。以下では、これらのエッジケースを主要な判断から分けて扱います。
合格条件の境界は変わりません。スナップショットが引き続きブロックを参照しているため、使用量が維持されたままライブの参照量が減少することです。後続の条件によってファイルシステム、識別情報、ネットワークパス、またはアプリケーションのバージョンが変わった場合は、その変更の影響を受ける判別テストだけを繰り返してください。
参照量と使用量の両方が高いままであるか、別のデータセット、クローン、予約、またはメタデータの割り当てが容量を所有している場合は、実験を拡大しないでください。その時点で削除を中止し、クリーンアップの前にすべてのデータセット、スナップショット、クローン、予約を把握します。プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に、証拠を保持してください。
ファイルを削除してもプールの空き容量が増えないのはなぜですか?
スナップショットがそのブロックを引き続き参照しているか、クローン、予約、または別のデータセットが割り当てを所有している可能性があります。
logicalusedは物理容量と同じですか?
いいえ。圧縮、コピー数、メタデータ、共有によって、論理値と割り当て済みの値は異なります。
削除前にスナップショットの容量を予測できますか?
参照量と固有量のプロパティは役立ちますが、共有ブロックがあるため、回収できる容量はスナップショットチェーン全体に左右されます。
スナップショットとライブファイルの容量について、実際の答えは引き続き条件付きです。スナップショットが引き続きブロックを参照しているため、使用量が維持されたままライブの参照量が減少します。参照量と使用量の両方が高いままであるか、別のデータセット、クローン、予約、またはメタデータの割り当てが容量を所有している場合は、削除を中止し、クリーンアップの前にすべてのデータセット、スナップショット、クローン、予約を把握してください。元のワークロードに耐えられない部分的な成功は、互換性があるとはいえません。
サポートとヒント
もっと読む

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

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

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

