バックアップが壊れた時どうする？

Sheet happens. 前回の講義では、障害発生後のデータベース完全復元の手順も勉強したよね。でも現実は予想外のことが起きるもの。もしバックアップが壊れてたらどうする？今こそ、その対処法を見ていこう。

履歴書はどこに置くのがベスト？

冗談だよ。今からは技術的な話をするから。でも、冗談にも真実があるってことは忘れないでね :)

バックアップ破損の分析

壊れたバックアップ って、卒論ファイルが提出直前に開けなくなるのと同じ感じ。症状も似てるよ：

• 復元しようとするとエラーが出る：pg_restoreを実行した時、例えばこんなエラーが出るかも：

  pg_restore: [archiver] input file does not appear to be a valid archive

• データの一部が消えてたり、ファイルサイズが変（急に小さくなったり、ゼロになったり）。
• 展開したSQLファイルにデータの切れ目や変な文字、空っぽのセクションがある。

バックアップが壊れる原因はいろいろある：

• バックアップ中にプロセスが止まる（例えば電源が落ちたり、システムがシャットダウンしたり）。
• ファイル転送ミス（USBやネットワーク経由でコピー中にエラー）。
• ハードウェア障害（ディスク、RAM、RAIDのトラブル）。
• バックアップツールやシステム設定のミス。
• ウイルスやマルウェア、そしてもちろん「うっかりクリック」も。

壊れたバックアップからのデータ復元

ファイルが壊れてても、まだ終わりじゃない。何かしら復元できる場合もある。いくつかのアプローチを見てみよう。

pg_restoreで復元を試す

pg_dumpでcustomやdirectory形式で作ったファイルなら、pg_restoreコマンドで--ignore-errorsフラグを付けて復元を試してみて。コマンド例：

pg_restore --dbname=your_database --ignore-errors backup_file.dump

このフラグは、エラーが出ても無視して処理を続けるって意味。壊れてる部分のデータは失われるけど、少なくとも一部は取り戻せるかも。

もしこれでうまくいったら、復元後のデータをしっかりチェックして、何が足りないか記録しておこう。

部分的なデータの利用

例えば、テキスト形式のSQLバックアップがある場合。エディタ（できればVisual Studio CodeやNotepad++みたいな高機能なやつ）で開いて、どこで切れてるか確認しよう。もしファイルが読めて、ほとんどのSQL文が無事なら：

1. 壊れてる部分を削除する。
2. 残りのSQL文を手動で、またはpsqlコマンドで実行する：

psql -U username -d database_name -f partial_backup.sql

custom形式ファイルの読み取り

バックアップがcustom形式なら、中身を部分的に取り出すこともできる：

pg_restore --list backup_file.dump > file_list.txt

このコマンドでバックアップ内の全オブジェクト一覧ができる。その後、特定の要素（テーブルやスキーマなど）だけを復元するには、次のコマンドを使う：

pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump

file_list.txtを編集して、壊れてる要素を除外すればOK。

アーカイブログ（WAL）からの復元を試す

もしインクリメンタルや差分バックアップ（例えばpg_basebackup）を使ってるなら、アーカイブログ（WALファイル）があるはず。これは前回のバックアップ以降の全変更を記録してる。データを復元するには：

1. 最後の完全なバックアップを探す（例えばフルバックアップ）。
2. PostgreSQLにWALファイルの場所を指定する：

   restore_command = 'cp /path/to/wal_directory/%f %p'

3. 復元を実行する。

サードパーティーツールの利用

バックアップ破損を最小限に抑えるために、ファイル復元ツールを使うのもアリ。有名なのはddrescue。コマンド例：

ddrescue --force backup_file.dump recovered_dump.file

このツールはできるだけ多くのデータを救い出して、新しいファイルを作ってくれる。

バックアップ破損の予防

壊れたファイルと格闘するのはストレスだよね。じゃあ、どうやって防ぐか考えよう。

複数箇所へのバックアップ保存

プロジェクトでのバックアップは「卵を一つのカゴに入れるな」ルールが鉄則。バックアップは複製しよう：

• ローカルサーバーに。
• クラウド（Amazon S3、Google Cloud Storage、またはDropboxみたいなサービス）。
• 外部メディア（超安全志向なら）。

バックアップの定期的な整合性チェック

IT界の格言：「テストしてないバックアップは、バックアップじゃない」。定期的にテスト復元して、バックアップを確認しよう。やり方：

1. テストサーバーにバックアップをアップロード。
2. そこからデータを復元。
3. 内容が正しいかチェック。

チェックサムの利用

バックアップ作成時にファイルのチェックサム（例えばMD5やSHA256）を生成しよう：

md5sum backup_file.dump > backup_file.md5

復元時は、現在のチェックサムと元の値を比較する：

md5sum -c backup_file.md5

これでファイル破損を事前に発見できる。

壊れたバックアップからの復元例

実際のケースをいくつか見てみよう。

ケース1. ファイル転送ミス

FTPでバックアップを移動中、ファイルサイズが予想より小さいことに気づいた。pg_dumpのテキスト形式だったので：

1. エディタでファイルを開く。
2. 壊れてる部分を削除。
3. 残りの部分をpsqlで復元。

ケース2. WALの一部消失によるデータ部分喪失

サーバーはインクリメンタルバックアップとアーカイブWALファイルを使ってた。突然一部ファイルが消えたけど、pg_basebackupと残ってたWALファイルで、設定でパスを指定してデータを復元できた。

バックアップは「作るだけ」じゃなく「ちゃんと確認する」ことも大事。世界の終わりが来てからバックアップが役立たないと気づくのは遅いよ。もし壊れても、PostgreSQLにはデータを取り戻す方法がたくさんある。大事なのは、焦らず素早く行動すること！

それでもダメだったら…この講義の最初の項目をもう一度読んでみて。