データ復元時の問題とエラー

バックアップって、雨の日の傘みたいなもんだと思いがちだよね。「これさえあれば大丈夫！」って。でも、その傘に穴が空いてたら結局濡れちゃう。バックアップとリストアも同じで、何かミスるとデータを失ったり、もっとヤバいと壊れたDBができちゃう。だから、エラーの仕組みを知って防ぐのが超大事なんだ。

データ復元時の問題

1. PostgreSQLバージョンの非互換性

一番よくあるし厄介なのが、あるバージョンのPostgreSQLで作ったデータを別のバージョンで復元しようとすること（例えば、11のバックアップを15でリストアしようとする）。PostgreSQLはバージョン間の下位互換性を保証してないんだ。

なぜこうなるの？

• バージョン間でデータフォーマットが変わることがある。
• 一部の関数やパラメータが削除・変更されることがある。

どうやって防ぐ？

• 必ずpg_dumpでバックアップを作ろう。PostgreSQLのディレクトリを直接コピーするのはNG。pg_dumpはどの互換バージョンでもリストアできる汎用SQLスクリプトを作ってくれる。
• リストア前にバージョン互換性をチェックしよう。PostgreSQL公式ドキュメントで調べられるよ。

例を挙げるね。 PostgreSQL 14でバックアップを作ったとする：

pg_dump -U user -d my_database -f backup.sql

で、今度はそれをPostgreSQL 15でリストアしようとする：

psql -U user -d my_database -f backup.sql

すると、こんなエラーが出ることがある：

ERROR:  unrecognized configuration parameter "old_function"

解決策：サーバーのPostgreSQLバージョンをアップデートするか、pg_upgradeユーティリティを使って移行しよう。

2. 必要なWALファイルがない

時々、増分や差分バックアップからリストアしようとすると、突然復元が止まることがある——原因はWALファイル（Write-Ahead Logging）が足りないから。PostgreSQLはこれで最後のフルバックアップ以降の変更を「巻き戻す」んだ。もしファイルがなかったり壊れてたら、DBは復元を完了できない。

例えば、WALファイルのアーカイブを有効にしてなかったり、誰かが容量確保のためにフォルダを消しちゃった場合に起きる。だから、増分バックアップを使うなら、postgresql.confでアーカイブを必ず有効にしよう：

archive_mode = on
archive_command = 'cp %p /path/to/wal_archive/%f'

あと、アーカイブがちゃんと動いてるか、ファイルが壊れてないか定期的にチェックしよう。これだけで、リストア時の安心感が全然違うよ。

3. バックアップファイルの破損

バックアップファイル自体が壊れてると、リストアに使えなくなっちゃう。

なぜこうなるの？

• 転送や保存中にファイルの整合性が崩れる。
• バックアップ作成中に予期しない障害が起きる。

どうやって防ぐ？

圧縮やチェックサムでバックアップの整合性を確認しよう。例えば、作成後にMD5ハッシュを作る：

md5sum backup.sql > backup.sql.md5

リストア前にバックアップファイルを必ずチェック：

md5sum -c backup.sql.md5

問題とその解決

壊れたファイルをリストアしようとすると：

pg_restore -U user -d my_database backup.dump

こんなエラーが出る：

pg_restore: fatal error: input file appears to be a text file, but you are using the 'pg_restore' command-line tool; try using psql instead

解決策：テキストエディタでファイルを開いて、中身が無事か確認しよう。もし壊れてる部分が少なければ、手動でSQLファイルを修正できるかも。

4. ユーザー権限不足.

リストア時に権限不足でエラーになることがある。特に権限が制限されたユーザーでリストアしようとした場合に多い。

なぜこうなるの？

ユーザーにテーブルやスキーマ、DBオブジェクト作成権限がない。

どうやって防ぐ？

必要な権限を持つユーザーでリストアしよう：

pg_restore -U postgres -d my_database backup.dump

5. 既存DBの上書き

もう一つよくあるのが、既にデータがあるDBにバックアップをリストアして、データを「上書き」しちゃうこと。一度上書きしたら元に戻せないよ。

なぜこうなるの？

--cleanフラグを使わずにリストアして、古いデータの上に新しいバックアップが追加されちゃう。

どうやって防ぐ？

リストア時は--cleanフラグを使って、既存の構造を削除しよう：

pg_restore --clean -U user -d my_database backup.dump

6. 未完了トランザクションのエラー

リストア時に、未完了トランザクションに絡むデータで問題が起きることがある。特に大きなDBでありがち。

なぜこうなるの？

サーバー障害でトランザクションが「壊れた」状態になる。

どうやって防ぐ？

PostgreSQLサーバーが全てのトランザクションをきれいに完了してからリストアしよう。問題が起きたら、サーバーを再起動してみて：

sudo service postgresql restart

リストアエラーを防ぐ方法

個別の問題の防ぎ方は話したけど、ほとんどのトラブルを防ぐための共通テクもあるよ：

リストアのテストを定期的にやろう。 テスト用DBを作って、そこにリストアしてみるといい。

バックアップは複数箇所に保存しよう。 クラウド、ローカル、リモートサーバーなどを組み合わせてね。

バックアップ作成を自動化しよう。 cronとかでスケジュールを組むと楽だよ。

ファイルの整合性をチェックしよう。 チェックサムでバックアップが壊れてないか確認しよう。

PostgreSQLのバージョンを同期しよう。 PostgreSQLのアップデートは後回しにしないで。将来の不整合の元になるから。

リアルなケースとその解決策

ケース1: WALファイルの紛失. サーバーが突然落ちて、必要なWALファイルがないことに気づいた。この場合、フルバックアップがないと復元は無理。シンプルな解決策は、WALアーカイブ設定を定期的にチェックすること。

ケース2: 壊れたバックアップ。 バックアップをサーバーにアップロードしたけど、チェックしたらファイルが空っぽだった。こういう時は他のストレージのバックアップを使うか、部分的に壊れたコピーから復元できないか試してみよう。

ケース3: バージョン非互換。 PostgreSQL 12からPostgreSQL 14にデータを移す時にエラーが出た。pg_dumpでデータをエクスポートして、新しいバージョンでリストアしよう。