スナップショットやごみ箱がNASの容量を使用しているかどうかを確認する方法

スペースの使用者を特定するには、NASから別のファイルやリカバリポイントを削除する前に、ライブ共有の使用状況、ゴミ箱の内容、およびスナップショット専用の使用状況を比較してください。

ゴミ箱は通常のファイルを隠しリポジトリに保持し、スナップショットはライブファイルが消えた後も参照される古いブロックを保持します。したがって、最も安全な確認方法は制御された比較であり、容量を記録し、両方の保持レイヤーを検査し、保持ルールを変更する前にどの数値が変化するかを確認することです。

まずはすべての数値を同じストレージ範囲に合わせる

まずは、空き容量が不足していると報告されたストレージプールまたはボリュームから始めます。共有フォルダは縮小しても親プールは変わらないことがあるため、共有サイズの数値とプール全体の空き容量を比較すると誤った矛盾が生じる可能性があります。

同時に4つの値を記録してください：プールの使用済み容量、ライブデータセットまたは共有の使用量、ゴミ箱の使用量、スナップショット専用の使用量。インターフェースで4つすべてが表示されない場合は、ファイルマネージャーでゴミ箱リポジトリを、スナップショットマネージャーで保持または専用のスナップショット容量を確認してください。

絶対的な数値よりもパターンが重要です。バックグラウンドの集計が完了した後に同じ画面を更新し、以下のサインを使ってどのレイヤーを詳しく調べるべきか判断してください。

ゴミ箱を保存されたファイルとして確認する

NASのゴミ箱は通常、ファイルを削除したコンピュータ側のゴミ箱ではなく、サーバー側のストレージです。影響を受けた共有フォルダ内やNASのファイルマネージャーで、隠しゴミ箱、トラッシュ、またはユーザーごとのリカバリフォルダを探してください。

Sambaスタイルのリサイクルサービスは削除を傍受し、ファイルをサーバー側のリサイクルディレクトリに移動することがあります。ファイル名は元のパスから消えるかもしれませんが、データは同じプール内に残っています。

リポジトリを空にする前にサイズを測定してください。すべての共有とユーザー範囲を確認しましょう。1つの見えるゴミ箱フォルダがNAS全体を代表しているとは限りません。また、繰り返し削除で複数のファイルバージョンが保持されているか、自動保持ジョブが実際に実行されたかも確認してください。

スナップショットを参照されているブロックとして確認する

スナップショットはすべてのファイルの2つ目の通常コピーを保持する必要はありません。古いブロックへの参照を保持するため、削除されたファイルはライブ共有から消えても、そのブロックは再利用できない状態で残ることがあります。

まず影響を受けたデータセットのスナップショットマネージャーの合計値を使用してください。ZFSシステムでは、スナップショットの使用容量をデータセットレベルで確認し、特定のファイルやディレクトリを含むスナップショットに絞り込むことができます。

1つのスナップショットの表示使用量を、その中に見えるすべてのもののサイズとして扱わないでください。複数のスナップショットが同じブロックを参照していることがあり、1つのリカバリポイントを削除しても、別のスナップショットが最後の参照を保持していればほとんど容量は解放されません。

何かを削除する前に制御されたチェックを行う

既知の削除済みファイルやフォルダをプローブとして使います。おおよその元のサイズと削除時刻が基準になりますが、圧縮、メタデータ、共有スナップショットブロックのため、最終的な容量変化はファイルサイズと完全に一致しないことがあります。

1. 新しい大容量転送を一時停止し、プール、ライブデータ、ゴミ箱、スナップショットの数値を記録します。
2. 関連するすべてのゴミ箱リポジトリで既知の削除パスを検索し、保存サイズをメモします。
3. 見つからなければ、削除前に作成されたスナップショットを調査し、スナップショットの合計使用量を比較します。
4. NASにドライランや見積もり機能があれば、期限切れスナップショット1つの回収見積もりをプレビューします。
5. データが不要と確認できたら、特定したゴミ箱アイテムまたは期限切れリカバリポイントのみを削除し、同じ4つの数値を更新します。

ゴミ箱の数値が減れば、通常のファイルが保持されていたことになります。スナップショット専用の使用量が減れば、保持されたブロックが原因です。どちらも変わらなければ、リカバリデータの削除を中止し、開いているファイルハンドル、アプリのバージョンストア、レプリケーション保持、予約容量、子データセットを調査してください。

定期的な保持でプールがほぼ満杯になる場合、現実的な解決策は繰り返しの緊急削除ではなく、スナップショット容量の余裕を確保することです。保持は回復目標を守りつつ、アクティブなサービスに必要な作業領域を消費しないようにすべきです。

よくある質問

なぜスナップショットの使用容量がほとんどないのに削除済みデータが保持されているのですか？

表示されている値は、そのリカバリポイント固有の容量を示している可能性があり、読み取れるすべてのブロックの容量ではありません。別のスナップショットが同じ削除済みデータを参照している場合、1つのスナップショットだけを削除してもほとんど容量は解放されません。

ゴミ箱を空にするとスナップショットも削除されますか？

いいえ。ゴミ箱のクリーンアップはライブリポジトリからファイルを削除しますが、スナップショットは別の保持システムに従います。ただし、そのリポジトリ自体がスナップショットに含まれている場合は、関連するスナップショットが期限切れになるまで古いブロックが保持されることがあります。

なぜ回収された空き容量が削除したファイルより小さいことがあるのですか？

論理的なファイルサイズと割り当てられたプール容量は必ずしも一致しません。圧縮、ブロック共有、メタデータ、パリティ、重複排除、遅延集計などが結果に影響を与えるため、正確なバイト単位の一致を期待せず、ストレージ層の指標を比較してください。