安全なアプローチは、マップされたシリアル番号と永続IDを基準にし、確認済みのメンバーを1台交換してから、再構築と元のワークロードを、単一のコマンドではなく、観測可能なゲートの連続として検証することです。
ZFS、mdraid、Btrfsを使用するLinuxホームNASでは、変化するLinuxデバイス文字を混同せずにNASドライブを交換する必要があることが実際のリスクになります。現在の識別情報と復旧ポイントを記録し、最も侵襲性の低い識別方法から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが1つしかなく、それを危険にさらすことになる場合は停止します。以下のワークフローは、元のワークロードが正常に完了するか、証拠がエスカレーションの境界に達した時点でのみ終了します。
シリアル番号とベイの交換マップを作成する
すべてのメンバーについて、アレイまたはプールの状態、デバイストポロジー、SMARTの識別情報、エンクロージャのスロット、シリアル番号、WWN、/dev/disk/by-idのシンボリックリンクを保存します。Linuxのデバイス文字は再起動やホットプラグ後に変わる可能性があるため、/dev/sdXは今回の起動中の観測結果であり、交換記録で使用する永続的な識別情報ではありません。
実用的なZFSホームサーバーガイドでは、永続的なby-idパスを使った交換と、一時的なデバイス文字を信用せずにリシルバリングを監視する方法を紹介しています。mdraidとBtrfsでは交換コマンドが異なりますが、同じ識別原則が適用されます。
ソフトウェア上の故障メンバーと物理ラベルを2回照合します。1回目はオフラインにする前、2回目はハードウェアを取り外す前です。シリアル番号のパススルー情報がない場合、2つのスロットが同じブリッジ識別情報を報告する場合、またはプールが別のメンバーのオフライン化に耐えられない場合は停止します。
冗長性を早期に低下させずに交換ドライブを準備する
新しいドライブの使用可能セクター数が少なくとも同じであること、想定されるセクター形式であること、可能であればアレイ外で基本的なヘルスチェックに合格することを確認します。挿入前にシリアル番号とby-idパスを記録します。暗号化されたメンバーやブート可能なメンバーの場合は、そのプラットフォームに必要なパーティションレイアウト、キー、ブートメタデータも保持します。
交換ドライブが異なる論理セクターサイズまたは物理セクターサイズを報告する場合は、ZimaSpaceのZFSミラーにおける異なるセクターサイズに関する解説を参照してください。筐体に表示された容量だけでは不十分です。実際のサイズ、ashiftまたはアライメントの要件、パーティションテーブル、NASプラットフォームのルールによって、交換が有効かどうかが決まります。
一度に交換するデバイスは1台だけにします。古いディスクがまだ読み取り可能で、プラットフォームが接続してから切り離す操作に対応している場合は、冗長性を維持できる可能性があります。それ以外の場合は、確認済みのメンバーをオフラインにし、筐体がホットスワップに対応していない場合は電源を切り、取り外したドライブにすぐラベルを付けます。
プラットフォーム固有の再構築を開始して監視する
各プールまたはアレイのステータスコマンドに表示されるメンバー識別情報を、新しい永続的なby-idパスと組み合わせて使用します。トポロジーを確認せずに汎用コマンドを貼り付けないでください。ZFSミラーの交換、mdraidメンバーの追加、Btrfsデバイスの交換では、状態遷移と障害時の挙動が異なります。
進行状況、読み取りエラー、チェックサム修復、SMARTの変化、温度、コントローラーのリセットを監視します。ある独立した交換手順では、故障したディスクのシリアル番号を記録し、次のメンバーを交換する前にリシルバリングの完了を待つことを重視しています。
新しいディスクが消える、残存メンバーのエラーが増える、または再構築が繰り返し再開される場合は、不要な負荷を停止し、ログを保全します。故障しているコンポーネントと現在の冗長性を把握するまで、別のディスクを取り外したり、エラーを消去したり、完了を強制したりしないでください。
古いドライブを廃棄する前に修復済みNASを検証する
進行状況バーが完了しただけでは十分ではありません。プールまたはアレイが正常であること、意図したすべてのメンバーが想定した永続的な識別情報を使用していること、パーティションに不足したサイズのものが残っていないこと、スケジュールされたマウント、共有、コンテナ、バックアップが2回の再起動後も維持されることを確認します。
安全な手順に従って、再構築後にプラットフォームの整合性チェックまたはスクラブを実行し、代表的なファイルを復元して、障害の原因となったワークロードを再現します。継続的な読み取りと書き込み中もエラーカウンターが安定していることを確認します。
新しいメンバーが通常のワークロードとバックアップサイクルに合格するまで、古いディスクはオフラインのままラベルを付けて保管します。トポロジー、データチェック、デバイスの健全性、アプリケーションのパスがすべて合格した時点で復旧は完了です。識別情報がなお不明確な場合や、再構築中に残存メンバーで新たなエラーが発生した場合は、エスカレーションしてください。
サポートとヒント
もっと読む

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

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

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

