ほぼ満杯のホームサーバー向けBtrfsメタデータ復旧チェックリスト

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Btrfs Metadata Recovery Checklist for a Nearly Full Home Server - Zima Store Online

安全なアプローチは、書き込みを安定させ、作業領域を回復し、フィルターをかけたバランスのみを実行し、通常のサービスに戻す前にデータを検証するという手順を、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。

ほぼ満杯のBtrfsホームサーバーファイルシステムでは、メタデータ領域が枯渇するとBtrfsがENOSPCを報告したり、読み取り専用になったりすることが現実的なリスクです。現在の状態と復旧ポイントを記録し、最も侵襲性の低い判別から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが1つしかなく、それが危険にさらされる場合は停止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーションの境界に達するまで完了しません。

修復を試みる前にファイルシステムを安定させる

影響を受けたファイルシステムに書き込むコンテナ、ダウンロード、スナップショット、ログの多いジョブを停止します。カーネルエラーとbtrfs device statsの出力を別の場所に保存します。ファイルシステムが読み取り専用で再マウントされた場合や、チェックサム、親トランザクションID、I/Oエラーが報告された場合は、復旧可能なコピーを確保するまで読み取り専用のままにします。

btrfs check --repair、完全なバランス、デフラグ、または大量削除から始めないでください。直ちに確認すべきなのは、有効なファイルシステム状態に割り当て用の作業領域が不足しているのか、それともストレージエラーがメタデータを損傷させているのかという点です。修復を優先すると、この区別が難しくなり、残りの領域を消費する可能性があります。

書き込みの多いサービスが停止され、重要なデータに別のコピーがあり、調査対象のブロックデバイスとマウントポイントが分かっていれば、安全性のゲートを通過できます。デバイスがリセットされたり、消失したり、読み取りエラーが蓄積したりする場合は、復旧用イメージの作成に進みます。

見かけ上の空き容量ではなく割り当てを確認する

btrfs filesystem usage -T /mount、btrfs filesystem df /mount、btrfs device usage /mountを実行し、最近のカーネルメッセージを確認します。各デバイスで、メタデータの割り当て量と使用量、および利用可能な未割り当て領域を比較します。通常のdfだけでは、Btrfsが別のメタデータチャンクを割り当てられるかどうかは分かりません。

対象を絞ったバランスには、完全に未使用の作業領域が必要です。詳しい対象を絞ったBtrfsバランスガイドでは、フィルターなしのバランスは対象となるすべてのブロックグループを書き換えること、そして目標は単に大きなファイルを削除してメタデータを拡張できると考えることではなく、デバイス単位で未割り当て領域を維持することだと説明されています。

メタデータの使用率が高くても未割り当て領域が残っている場合は、空または使用率の低いチャンクを再利用するために、小規模なフィルター付きバランスを実行できます。どのデバイスにも作業領域がない場合は、安全に削除できるデータやスナップショットを少量ずつ削除するか、ファイルシステムのプロファイルに適した一時デバイスを追加します。完了できない再配置を開始しないでください。

最も侵襲性の低い方法で作業領域を回復する

まず、スナップショットに保持されていない不要なファイルを削除し、次に不要であることを確認したスナップショットだけを削除します。小さな変更を行うたびに同期して使用量を再確認します。バランスが必要な場合は、btrfs balance start -dusage=0 -musage=0 /mount、または確認した割り当て状況に基づいて選んだ別の狭いフィルターから始め、完全なバランスは避けます。

フィルター付きバランスの動作に関するLinuxマニュアルの説明では、フィルターによって再配置の範囲が制限されること、またバランス自体に作業領域がない場合にENOSPCが発生する可能性があることが示されています。btrfs balance statusとカーネルログを監視します。再配置によってエラーが増加したり、デバイス障害で停止したり、最後の安全余裕まで消費したりする場合は、キャンセルして読み取り専用の復旧に戻ります。

各手順の間に測定せず、フィルターや削除を重ねて実行しないでください。メタデータに余裕が生まれ、必要なデバイスに未割り当て領域が存在し、小さな書き込みが新たなENOSPCや強制的な読み取り専用化なしに完了すれば、復旧ブランチは成功です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

データを検証し、直ちに再発しないようにする

まず、リスクの低いサービスを1つだけ再起動し、メタデータを最初に満杯にしたワークロードを再現します。たとえば、スナップショットの作成や多数の小さなファイル変更などです。ワークロードの実行後と再起動後に、使用量とカーネルログを再確認します。一度はマウントできても、通常の変更処理で読み取り専用に戻るなら、復旧したとはいえません。

保持期間を変更する前に、ZimaSpaceの方法を使って、NASの容量をスナップショットとライブファイルのどちらが使用しているかを切り分けます。スナップショットが保持するエクステントによって削除の効果がないように見える場合がある一方、ライブの小さなファイルの頻繁な変更によってメタデータへの圧力が高い状態が続くこともあります。適切なポリシーは、測定結果が示す状態によって決まります。

ファイルシステムが書き込み可能な状態を維持し、デバイス統計の増加が止まり、代表的なファイルを正しく復元またはハッシュ検証でき、同じ余裕が失われる前に監視アラートが発生することを確認してから、通常のサービスを再開します。構造的なエラーが続く場合は、Btrfsの復旧専門家にエスカレーションし、唯一のコピーに修復コマンドを繰り返し実行するのではなく、クローン上で作業します。