安全でないシャットダウン後にNASボリュームが読み取り専用になる場合の最初の確認事項

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

安全でないシャットダウン後に読み取り専用になるNASボリュームは、通常、破損したメタデータを保護しているかストレージI/Oエラーに反応しているのであり、単に権限を変更しているわけではありません。

共有は開けるがアップロード、アプリデータベース、メディアスキャンが失敗する場合、強制的な読み書き再マウントは避けてください。最も安全な方法は読み取り可能なデータを保護し、ブロックが共有、ファイルシステム、プール、またはドライブのどのレイヤーで発生しているかを特定し、そのストレージスタックに適した修復方法を使うことです。

まず、変更を凍結し読み取り可能なデータを保護する

読み取り専用モードは問題そのものではなく警告として扱います。同期ジョブ、コンテナ、メディアインデックス、ダウンロード、バックアップローテーションを一時停止し、繰り返しの再試行が元のエラーを隠したり弱いドライブに負荷をかけたりしないようにします。

重要なファイルがまだ読み取り可能な場合は、修復を試みる前に最も代替不可能なデータを別の健全なストレージにコピーしてください。報告されたケースでは、停電後の読み取り専用ファイルシステムが一時的な修復後に再発し、再発は未解決として扱うべき理由を示しています。

  1. サービスとクライアントの書き込みを一時停止する。
  2. 重要な読み取り可能ファイルを別の場所にコピーする。
  3. ストレージ状態の画面とイベントログを保存する。
  4. プールのレイアウトとファイルシステムの種類を記録する。
  5. アレイを変更せずにチェックを開始する。

この順序はデータと証拠の両方を保護します。再起動、強制アセンブル、修復、または再マウントは診断に必要な状態を変える可能性があるため、最初の実験にしないでください。

実際に読み取り専用になったのはどこか?

アップロードの失敗はボリューム全体が読み取り専用であることを証明しません。共有、データセット、アプリケーションディレクトリ、ファイルシステム、ストレージプール、または物理デバイスが書き込みをブロックする可能性があり、それぞれのレイヤーで異なる修正が必要です。

NASダッシュボードと複数のクライアントからの障害を比較します。以下のパターンは、ディスクに触れたりファイルシステム修復ツールを実行する前に、アクセス問題とストレージ保護イベントを区別します。

目に見える結果 可能性のあるレイヤー 最初の安全なチェック 次のアクション
一人のユーザーは保存できず、別のユーザーは可能 アカウント、ACL、または共有の権限 ユーザーとグループのアクセスを比較する ストレージを修復せずにアクセスを正す
一つのアプリまたは共有が失敗し、他は書き込み可能 データセット、共有、またはアプリケーション そのサービスのパスとクォータを確認する 孤立したサービスレイヤーを修正する
すべてのローカルおよびネットワーク書き込みが失敗する ファイルシステムまたはボリューム マウントとボリュームの状態を確認する 修復前にログを確認する
プールが劣化、停止、またはデバイスが欠落している RAID、プール、コントローラー、またはドライブ メンバーとエラー状態を確認する まず下位レイヤーを安定させる

NAS自体はテストファイルを作成できるがクライアントができない場合は、ファイルシステム層の上で作業を続けてください。ローカル書き込みも失敗し、ダッシュボードが読み取り専用ボリュームを報告している場合は、ログとプールの健康状態の確認を続けてください。

ログが消える前に読み取ってください。

最初の有用な証拠は、ボリュームが読み取り専用になる直前のイベントです。影響を受けた起動時とその前の起動時のシステムイベントログ、ストレージマネージャの履歴、カーネルメッセージを確認してください。

一部のファイルシステムはエラー検出後に書き込みを停止します。システムが突然読み取り専用になった場合、対応者は新しいジャーナルエントリがディスクに到達しない可能性を警告しています。可能な限り再起動前に現在のカーネルメッセージをキャプチャしてください。

ファイルシステムエラー、ジャーナル中断、チェックサム失敗、デバイスリセット、タイムアウト、読み書きI/Oエラーを含むエントリを保存してください。デバイス識別子とタイムスタンプを記録し、同じメンバーで繰り返される障害は一般的な「不正シャットダウン」通知より重要です。

ファイルシステムの前にプールまたはRAIDを確認してください。

ファイルシステムはプール、RAIDセット、論理ボリューム、コントローラー、ドライブの上に存在します。下位レイヤーが不完全または不安定な場合、ファイルシステムの修復は不整合なデータを読み込んだり、最悪のタイミングで負荷を増やしたりする可能性があります。

LinuxのソフトウェアRAIDでは、汚れた(dirty)かつ劣化した(degraded)RAID 5またはRAID 6アレイは検出不能な破損リスクを伴うことがあります。汚れた劣化アレイルールは、自動起動が拒否される理由を説明しています。ダッシュボードの警告を消すためだけにアセンブリを強制しないでください。

すべてのメンバーが存在するか、リビルドやリシルバーがアクティブか、読み取り、書き込み、チェックサムカウンターが上昇しているかを確認します。プールのメンバー順序と正確な状態を、アセンブリの強制、ディスクの交換、スクラブの開始をせずに記録してください。上位のファイルシステムを確認する前にプールを安定させます。

ドライブの健康状態、配線、電源を確認してください。

キャッシュやメタデバイスを含むすべてのHDD、SSD、NVMeデバイスを確認してください。NASのヘルスページを使ってSMARTやNVMeの健康状態、最近のセルフテスト、温度、メディアエラー、シャットダウン後にデバイスが消えたかどうかを調べます。

緑色の「正常」バッジだけに頼らないでください。カーネルのI/Oエラー、デバイスのリセット、ボリュームの状態変化の時間と健康状態の結果を関連付けて確認してください。合格の概要は、ストレージパスの他の場所で記録された障害を説明しません。

アクセス可能なデータまたは電源接続を再接続する前にNASの電源を正常にシャットダウンし、一度に1つの変数だけを変更してください。複数のドライブが同時に消えたり、ディスクではなくポートに続くエラーが発生した場合は、個々のドライブを責めるのをやめて共有パスを調査してください。

修復ツールをファイルシステムに合わせる

Ext4とXFS:ネイティブツールでオフライン修復

Ext4はe2fsckを使用し、XFSはxfs_repairを使用します。どちらもマウントされたボリュームや不確かなデバイスパスを対象にすべきではありません。NASが安全にボリュームをアンマウントできない場合は、そのメンテナンスワークフローやサポートされたリカバリ環境を使用してください。

実用的なファイルシステムトラブルシューティングガイドでは、ext系のチェックをXFS修復から分離し、アンマウントされたファイルシステムでチェックを行うことを推奨しています。バックアップを保存し、正確なデバイスを特定し、可能な場合はファイルシステムのネイティブな変更を加えないモードから開始してください。

Btrfs:読み取り専用チェックと専門家の指導を優先する

Btrfsはスクラブ、構造チェック、修復を分離しています。スクラブはチェックサムを検証し良好なレプリカを使用することがありますが、構造チェックはファイルシステムオブジェクトを検査します。どちらも損傷したボリュームを単に書き込み可能にする一般的なスイッチとして扱うべきではありません。

公式のBtrfsチェック警告では、最初にアンマウントすることを推奨し、経験豊富な指導なしに--repairを使用することを明確に警告しています。読み取り可能なデータの回復と変更を加えないチェックから始め、NASベンダーの文書化された回復手順に従ってください。

ZFS:スクラブ前にプールを安定させる

ZFSは従来のfsckワークフローを使用しません。まずプールの状態を読み取り、重要なファイルを保護し、欠落または障害のあるデバイスを解決してから、スクラブによる持続的なI/O負荷をかけてください。

OpenZFSのプールスクラブはブロックのチェックサムを検証し、良好なレプリカから修復することがありますが、I/O負荷が高く、冗長性が失われた場合に有効なコピーを作成することはできません。プールが安定し、重要なデータが保護されてから開始してください。

書き込みを復元するタイミングと停止すべきタイミング

プールが安定し、関連するオフラインチェックまたはネイティブリカバリが完了し、新しいログに再発するI/Oやメタデータエラーがないことを確認してから、読み書きサービスを復元します。その後、リスクの低いサービスを1つ起動し、使い捨てファイルでテストしてから通常のワークロードを再開してください。

強制再マウントが失敗するか、ボリュームがすぐに読み取り専用に戻る場合は、その結果を新たな証拠として受け入れてください。同じコマンドを繰り返しても原因は除去されず、書き込み、熱、回復の負荷が増すだけです。

複数のプールメンバーが欠落している、エラーカウンターが増え続けている、ドライブがカチカチ音を立てるか繰り返し切断される、チェックサムが回復不能、または唯一の読み取り可能なコピーが重要な場合はDIY修理を中止してください。ログとデバイスの順序を保存し、ハードウェアが不安定な場合はシステムの電源を切り、資格のあるストレージ回復またはプラットフォームサポートに連絡してください。

次の安全でないシャットダウンを防ぐ

通信ポートが未使用のバッテリーだけでなく、NASに自動シャットダウンを通知できるUPSを使用してください。このNAS停電チェックリストはシャットダウン通信、停電後のチェック、回復中に安定した電力が重要な理由をカバーしています。

回復用コピーはライブプールの外に保管してください。RAIDは一部のドライブ障害後の可用性を維持できますが、ライブの破損に従い、以前のクリーンなバージョンを提供しません。修復が成功しない場合に最も重要なのはRAIDとバックアップ回復の違いです。

最後に、ディスク、プール、UPSのアラートを有効にし、ファイルシステムに適したチェックやスクラブをスケジュールし、小規模なリストアを定期的にテストしてください。起動が成功することは有用ですが、検証された回復経路こそが次のシャットダウンを危機から制御されたイベントに変えます。

よくある質問

再起動で読み取り専用のNASボリュームは修復できますか?

再起動はジャーナルの再生を完了したり、一時的なサービス状態をクリアしたりできますが、ストレージが正常である証明にはなりません。特にボリュームがすでに複数回読み取り専用に変更されている場合は、保存されたログとプールの状態を最初に確認してください。

ファイルをコピーするために読み書き可能な再マウントを強制できますか?

既存の読み取り専用状態からのコピーを優先してください。強制的な書き込み可能マウントは新しいメタデータの更新を引き起こす可能性があり、カーネルがまだエラーを検出している場合はすぐに失敗することがあります。最良のコピーを保護した後、ファイルシステム固有の回復計画内でのみ使用してください。

SMARTが正常でもログにI/Oエラーが表示される場合はどうすればよいですか?

ログは未解決の証拠として扱ってください。障害はインターフェース、ケーブル、バックプレーン、コントローラー、電源経路、または全体のSMART結果にまとめられていないドライブの問題に関係している可能性があります。1つずつコンポーネントを切り離し、エラーが続く場合は停止してください。

最も安全な最初のチェックは、オプションを保持するものです:読み取り可能なデータを保護し、ブロックされたレイヤーを特定し、強制的な再マウントではなく検証された証拠に基づいて次の行動を決定します。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.