データが消えた：段階的な対処法

データ損失が起きた直後の行動が、その後のすべてよりも重要です。以下では、復旧の可能性を失わないための手順を説明します。

まずはディスクへの書き込みを止める

削除されたファイルは、その領域が新しいデータで上書きされるまでディスク上に残っています。パッケージのインストール、稼働中のウェブサイト、増え続けるログなど、あらゆる書き込みが復旧の可能性を下げます。

• 書き込みを行っているものを停止します。ウェブサーバー、データベース、キューワーカーなどです。
• 同じディスクに復旧ソフトウェアをインストールしないでください。
• システムを再インストールしないでください。再インストールはディスクを完全かつ不可逆的に破壊します。

データが重要でバックアップがない場合は、実験を行う前にマシンを停止し、サポートに連絡してください。

何が起きたのかを正確に把握する

バックアップがある場合

これが最も速い方法であり、ほぼ常に唯一成功する方法です。独自の方式で復元してください。rsyncやresticなどを使用し、展開が成功したかどうかではなく、中身を確認します。サイズ、行数、データベースが開くかどうかです。

restic -r /path/to/repo snapshots
restic -r /path/to/repo restore latest --target /restore

まずは稼働中のディレクトリに上書きするのではなく、別のディレクトリに復元してください。バックアップも不完全な場合があり、それで残存データを上書きしてしまうと、両方の選択肢を失うことになります。

バックアップがない場合

当社はお客様のマシンの自動バックアップを保持しておらず、スナップショットもありません。仮想マシンのディスクはお客様のディスクであり、そこで起きたことはそこで起きたことです。だからこそ、バックアップは初日から設定するものです。何をバックアップすべきかをご覧ください。

ご自身で試せるその他の方法:

• ファイルがまだプロセスによって開かれている場合。 プログラムが削除されたファイルを保持している場合、/proc 経由でアクセスできます。

  lsof +L1
  cp /proc/<pid>/fd/<n> /root/recovered-file
  

  これはプロセスが稼働している間のみ有効です。再起動しないでください。
• データベースのログ内のデータ。 PostgreSQL と MySQL には書き込み前ログがあり、専門家がクラッシュ前の状態を再構築できます。データベースを修復モードで盲目的に起動しないでください。ログも失うことになります。
• レスキューディスクで起動し、extundelete や photorec などのツールを試す前に、ディスクを別のマシンにイメージとしてコピーしてください。作業は稼働中のディスクではなく、イメージに対して行う必要があります。

やってはいけないこと

• データが必要かどうかを判断する前に、システムを「やり直すために」再インストールする。
• 出力を同じディスクに書き込む復旧プログラムを実行する。
• イメージを取得せずに、稼働中のディスクで fsck に自動で「yes」と回答してファイルシステムを修復する。
• 1週間待ってから復旧を依頼する。マシンが稼働している時間が長いほど、残るデータは少なくなります。

同じことを繰り返さないために

同じ会話はいつも同じ結末を迎えます。バックアップがあるか、ないかです。今日設定し、四半期に一度リストア演習でテストしてください。一度も復元されたことのないバックアップは、バックアップとして数えられません。