ホームサーバー復旧チェックリスト：パスワード、ネットワーク、起動、ストレージ

ホームサーバーの回復はランダムなコマンドから始めるべきではありません。パスワードを忘れた、IPアドレスを失った、起動経路を壊した、ストレージが見えない場合は、最初にどの層が故障したか（アクセス、ネットワーク、起動、ストレージ）を特定するのが最も安全な方法です。

順序が重要です。資格情報を変更する前にローカルコンソールアクセスを回復してください。SSHに頼る前にネットワークを復旧してください。OSドライブを確認してから起動を修復してください。ストレージは最後に触ってください。劣化したプール、RAIDアレイ、マウントされたファイルシステムに誤った修復コマンドを実行すると、回復可能な問題がデータ損失に変わる可能性があります。

問題を悪化させる前に止めましょう

最初の回復ステップは修復ではなく、被害の拡大防止です。何が故障したか分かるまでは、再起動を繰り返したり、ドライブを入れ替えたり、アレイを再構築したり、「不明」なディスクをフォーマットしたり、OSを再インストールしたりしないでください。

見たものを書き留めてください。エラー画面、BIOSの起動順序、ドライブベイの位置、ケーブルの配置、ルーターのIPリース、ストレージの警告の写真を撮ってください。回復の試みが失敗する多くの原因は、元の状態を記録する前にユーザーが多くの変更を加えてしまうことです。

データが重要な場合、最初の目標はまだ読み取れるものを保護することです。正常に見えるサーバーよりも回復経路を元に戻せる状態に保つことが重要です。

間違った層を修復する前に故障した層を見つけましょう

多くのホームサーバーの問題は外見上同じように見えます：ウェブUIが開かない。しかし、それは同じ部分が故障したことを意味しません。ケーブル断線、IPアドレスの変更、ウェブサービス停止、アカウントロック、ブートローダー破損、マウントされていないストレージプール、またはDockerボリュームの故障など、すべて「サーバーがダウンしている」ように見えます。

リスクの低いチェックから始めましょう。デバイスの電源は入っていますか？ルーターはそれを認識していますか？NICのリンクランプは点灯していますか？モニターとキーボードを接続できますか？BIOSまたはUEFIは起動ドライブを認識していますか？システムはログイン画面まで到達しますか？データディスクは見えていますか？

その後で回復方法を選択してください。パスワード回復はネットワーク修復ではありません。ネットワーク修復は起動修復ではありません。起動修復はストレージ修復ではありません。これらを早急に混同すると回避可能なリスクが生じます。

パスワード回復にはまずローカルアクセスが必要です

管理者パスワードを忘れた場合、まずはOSの再インストールから始めないでください。まずは、まだログイン中のウェブセッションがあるか、別の管理者ユーザーがいるか、SSHキーがあるか、パスワードマネージャーのエントリーがあるか、物理コンソールアクセスが可能かを確認してください。

パスワードリセットは、自分が所有または管理するデバイスでのみ行うべきです。Linuxシステムの場合、フォーラムのランダムなブートコマンドをコピーするのではなく、OSの公式なレスキュープロセスに従ってください。FedoraルートパスワードリセットドキュメントはOS固有の回復参考例ですが、正確な手順はディストリビューションやブート設定によって異なります。

アクセスが復元されたら、回復が必要になった理由を整理します。パスワードマネージャーを更新し、バックアップ管理者アカウントを作成し、必要に応じて公開されたSSHキーをローテーションし、二要素認証設定を確認し、次回ローカルアクセスを回復する方法を記録してください。

ネットワークの回復はリモート修復より先に行います。

ネットワーク経由で到達できないサーバーでも、完全に正常な場合があります。ストレージ、ブートローダー、アプリを変更する前に、ローカル通信を復元してください。

ルーターのクライアントリスト、リンクランプ、ローカルIPスキャン、直接モニター出力、基本コマンド（例： ip a, ping、および ssh目標を絞りましょう：まず信頼できるLANアクセスを確保し、その後にリモートアクセス、VPN、トンネル、DNS、リバースプロキシを修正します。

ブート修復はデータプールではなくブートパスに関するものです。

ブート失敗は必ずしもデータディスクの損傷を意味しません。OSドライブ、ブートローダー、BIOSの順序、UEFIエントリ、USBデバイス、回復パーティション、またはカーネルの更新が問題の原因である可能性があります。

ストレージに触れる前にブート順序を確認してください。どのディスクにOSがあり、どのディスクにデータがあるかを確認します。システムに回復パーティション、バックアップブートスロット、またはレスキューオプションがある場合は、再インストールの前にそれを使用してください。デュアルブートスロットをサポートするシステムでは、回復パスによりユーザーデータを分離したまま、既知の正常なシステムパーティションからサーバーを起動できる場合があります。

ZimaOSユーザー向けに、ZimaOSシステム回復ガイドでは、バックアップブートパーティションを使ったシステムの迅速な回復方法を説明しています。この回復方法は、データディスクを最初の修復対象とせず、OSの再起動に重点を置いているため有用です。

一般的なLinuxサーバーを使用している場合、ブート修復はライブUSBの起動、正しいルートパーティションのマウント、リカバリー環境への入り、ブートローダーの修復を含むことがあります。これはブートディスクを特定した後にのみ行ってください。誤ってデータディスクにブートローダーやOSをインストールすることは回復を悪化させる最も簡単な方法の一つです。

ストレージ回復は最もリスクが高いため最後に行います

ストレージは回復ミスが高額になる場所です。作業しているストレージ層を把握するまでは初期化、フォーマット、強制アセンブル、リビルド、修復を行わないでください。

読み取り専用の質問から始めます。すべてのディスクは検出されていますか？どのディスクが欠損していますか？プールはインポートされていますか？ファイルシステムはマウントされていますか？SMART警告はありますか？アレイは劣化していますか？共有フォルダが欠けているのはプールの故障によるものですか、それともOSがマウントせずに起動したためですか？

重要なファイルが読み取れる場合は、リスクのある修復を試みる前にコピーしてください。最初のストレージ回復の目標はサーバーを正常に見せることではなく、状況が変わる前に読み取れるデータを保護することです。

ZFS、RAID、単一ドライブは異なる対応が必要です

単一のext4またはXFSドライブ、ZFSプール、mdadm RAIDアレイ、USBバックアップドライブ、Dockerアプリボリュームは同じ方法で修復すべきではありません。

OracleのZFSトラブルシューティングとプールの回復ドキュメントは、ZFSの問題を欠損デバイス、損傷デバイス、破損データに分類しているため役立ちます。この区別は重要です。欠損デバイス、損傷したドライブ、破損したデータは同じ対応を必要としません。

ZFSは従来のfsckモデルも使用しません。ZFSシステムでは、ステータスチェック、スクラブ、インポート、リシルバリング、バックアップがリカバリーの考え方に含まれます。非ZFSファイルシステムの場合は、ボリュームとマウント状態を確認した後に、正しいファイルシステム固有の修復ツールを使用してください。

アプリのリカバリーは基本システムが安定するまで待つべきです

Docker、メディアアプリ、同期ツール、ダッシュボードから始めないでください。アプリは基本システムの上にあります。OS、ネットワーク、ストレージマウント、権限が壊れていると、アプリは再起動後に再び失敗します。

まず基本スタックを確認します：サーバーが起動し、ローカルネットワークが機能し、ストレージがマウントされ、権限が正常で、重要なデータがバックアップされていること。その後、アプリケーションサービス、コンテナ、ポート、リバースプロキシルール、データベースファイル、アプリボリュームをチェックします。

リカバリー後の多くのアプリ障害はパスの問題です。ストレージプールが別の場所にマウントされている。Dockerボリュームが古いフォルダを指している。データベースファイルは存在するが所有者が間違っている。メディアアプリは起動するがライブラリが見えない。アプリを再インストールする前にストレージパスを修正してください。

次の障害に備えてリカバリーキットを作成する

最良のリカバリーはサーバーが壊れる前に準備されます。ホームサーバーは重要な詳細がサーバー外に保存されていると修復が容易です。

このキットは、故障したサーバーがアクセスする必要のない場所に保管してください。故障したNASにのみ保存されたリカバリーノートはリカバリーノートとは言えません。

DIYリカバリーを中止すべきタイミングを知る

一部の障害はもはやトラブルシューティングの課題ではなく、データ復旧の状況です。重要なデータの唯一のコピーがサーバー上にある場合、すべてのコマンドはリスクとして扱うべきです。

複数のドライブが見つからない、ドライブがカチカチ音を立てている、RAIDやプールが劣化していて不明瞭、誤ったドライブが交換された可能性がある、プールのインポートで破壊的なオプションを求められる、またはデータがバックアップのない業務上重要な場合は、DIYリカバリーを中止してください。

その時点で適切なら電源を切り、ドライブにラベルを貼り、現在の状態を記録し、繰り返しの再構築を避け、回復の可能性が下がる前に助けを求めてください。ホームサーバーの回復は自分で全てを直せることを証明することではなく、別のコマンドが回復の可能性を下げるかもしれないことを知ることです。

最終回復チェックリスト

回復は地味な作業ほど効果的です。アクセスからネットワークへ、ネットワークからブートへ、ブートからストレージへ、ストレージからアプリへと進めてください。どの層が故障したか正確に分かっている場合のみ、この順序を省略して構いません。

よくある質問

ホームサーバーにアクセスできない場合、最初に何をすべきですか？

物理的およびネットワークのチェックから始めてください：電源、ケーブル、ルーターのリース、ディスプレイ出力、キーボードアクセス、ローカルコンソール。アクセス、ネットワーク、ブート、ストレージのどれが問題か分かるまでストレージの修復は開始しないでください。

ホームサーバーのパスワードを忘れた場合はどう回復しますか？

既存の管理者セッション、バックアップ管理者アカウント、SSHキー、ローカルコンソール、またはOS固有のレスキューモードを使用してください。パスワードのリセットは自分が所有または管理しているデバイスでのみ行い、その後パスワードマネージャーを更新してください。

ホームサーバーにはpingできるのにウェブUIが開けないのはなぜですか？

ネットワークは動作していても、ウェブサービス、コンテナ、リバースプロキシ、ファイアウォール、またはアプリのポートが壊れている場合があります。ストレージプールとアプリのパスが利用可能であることを確認した後にサービスの状態をチェックしてください。

不正なシャットダウン後にfsckを実行すべきですか？

自動的には行われません。まずファイルシステムを特定し、ボリュームが安全に修復可能か確認してください。ZFSは従来のファイルシステムのfsckモデルとは異なるため、プール固有のステータスと回復ツールを使用してください。

ZFSプールが劣化した場合はどうすればいいですか？

まずプールの状態を確認し、欠損または故障したデバイスを特定し、新しいプールを作成したりラベルを上書きしたりしないでください。データが重要でバックアップがない場合は、リスクのある修復を試みる前に読み取り可能なファイルを保護してください。

OSを再インストールするとNASのデータは消えますか？

ディスクのレイアウトやインストーラーの選択によります。多くのホームサーバーはOSドライブとデータドライブを分けていますが、再インストール時に誤ったディスクを選ぶとデータが消失する可能性があります。再インストール前にブートドライブとデータドライブを必ず確認してください。