障害後のデータ復元

障害にもいろいろあるよね：ハードウェアの故障、停電、コードのバグ、あるいは「なんか古いの消しとくか」って適当にDBを消しちゃううっかり管理者の手違いとか。こういう時、バックアップとちゃんと練習した復元プロセスがまさに「魔法の杖」になるんだ。

じゃあ、IKEAの家具を組み立てるみたいに、パニックにならずに手順通り復元プロセスを見ていこう！

ステップ1. 障害の原因を分析する

いきなり全力でデータを復元しに走る前に、何が起きたのかちゃんと把握しよう。

1. アプリケーションエラー？それともDBのエラー？
   アプリやPostgreSQLのログをチェックしよう（たいてい/var/log/postgresql/とか、OSによって似たようなディレクトリにある）。エラーのサインを探してみて。

2. ハードウェアの故障？
   もしサーバーが物理的に壊れてる（例えばHDDのトラブルとか）なら、まずハードがちゃんと動くか確認しよう。ディスクが壊れてたら、別のディスクをつないでそこから全部復元しよう。

3. ネットワークやアクセスの問題？
   もし障害がネットワーク由来なら、サーバー自体は今のところ復元作業は必要ないかも。

4. ヒューマンエラー：
   正直に言って...誰かDROP DATABASEやっちゃった？もしそうなら、まだバックアップからデータを復元できるチャンスはあるよ。

障害の原因を正確に理解することで、今後同じことを防げるからね。

ステップ2. バックアップの有無を確認する

さあ、ちゃんとしたバックアップがあるか確認しよう。pg_dumpやpg_basebackupで作った最新のDBバックアップを探して、整合性をチェック！やり方を忘れた人のために、簡単におさらい：

• ls -lコマンドでファイルサイズを確認。サイズがやけに小さいときは要注意。
• fileコマンドでファイルの中身をチェック。例えば：

  file backup_file.sql
  

  SQLダンプだって分かる情報が出てくるはず。

tarアーカイブなら、ちゃんと展開できるかも確認しよう：

tar -tf backup.tar

エラーが出なければOK！次に進もう。

ステップ3. PostgreSQLを停止する

復元を始める前に、PostgreSQLサーバーを止めて安全に作業しよう。サーバー管理者で次のコマンドを実行：

sudo systemctl stop postgresql

DBを止めておけば、他のプロセスが復元を邪魔しないよ。

ステップ4. 復元用の新しいDBを用意する

もしDBが完全に消えた・壊れた場合は、まず新しく作り直そう。コマンド例：

createdb -U postgres new_database

new_databaseは自分のDB名に変えてね。

ステップ5. バックアップから復元する

主な復元シナリオは2つあるよ：

1. SQLバックアップ（pg_dump）の場合：
   復元はこのコマンドでOK

   psql -U username -d new_database -f backup_file.sql
   

• username — PostgreSQLのユーザー名
• new_database — データをインポートするDB名
• backup_file.sql — バックアップファイル名

2. バイナリバックアップ（pg_basebackupやpg_dumpのcustom形式）の場合：
   復元はこうやってやる：
   

   pg_restore -U username -d new_database backup_file.dump
   

   これらのバックアップはテキストじゃなくて「パックされた」データだから注意！

さらに：

• データだけ復元したいなら--data-onlyを使おう。
• 構造だけ復元したいなら--schema-onlyを追加しよう。

ステップ6. PostgreSQLを起動してテストする

復元コマンドを実行したら、サーバーを起動しよう：

sudo systemctl start postgresql

次はテストだよ。psqlやpgAdminで復元したDBに接続して、いくつかSELECTしてデータがちゃんと入ってるか確認しよう：

SELECT * FROM your_table_name LIMIT 10;

問題なさそうなら、おめでとう！データ復元完了！

ステップ7. データの整合性チェック

復元後はデータが壊れてないかも確認しよう。例えば：

1. テーブルの行数をバックアップと比較する：

   SELECT COUNT(*) FROM your_table_name;
   

   バックアップの記録と比べてみて。

2. チェックサムを使う：
   もし前もってテーブルのチェックサムを作ってたなら、今こそ照合しよう：

   md5sum backup_file.sql
   

3. テーブル間のリレーションを確認：
   復元したFOREIGN KEYがちゃんと動いてるかもチェックしよう。

ステップ8. アプリケーションのテスト

最後に、このDBを使ってるアプリがちゃんと動くかも確認しよう。主要な操作をざっと試して、エラーがないか、表示が正しいかチェック！

実際の復元エラー例

じゃあ、いくつかケースを見て、どうやってトラブルを避けるか紹介するね：

1. PostgreSQLバージョンの不一致。
   例えばバージョン12でバックアップを取って、サーバーが15にアップグレードされてたら、復元時にエラーが出るよ。
   解決策： バックアップを作ったのと同じバージョンのPostgreSQLを使うか、互換性については公式ドキュメントをチェック：PostgreSQL Documentation。

2. 壊れたバックアップ。
   バックアップが壊れてたら、一部データが失われることも。
   解決策： バックアップの複製（例えば複数バージョンを保存）を使おう。

3. 特定テーブルの復元エラー。
   特定のテーブルだけ復元しようとして、他の依存（例えば外部キー）がなかったら、エラーで止まることも。
   解決策： テーブルは必ず親テーブルから順番に復元しよう。