はじめに
システム管理において、データ損失は「起きるかどうか」ではなく、「いつ起きるか」が問題です。ハードウェア障害、ソフトウェアのバグ、人為的ミスなど、原因にかかわらず、重要なデータの損失は深刻な事態につながります。そのため、バックアップと復旧はデータベースを扱ううえで最も重要なスキルの一つです。
この実験では、完全な「災害復旧」のシミュレーションを行います。まず正常なデータベースを用意し、安全にバックアップします。次にデータベースを削除して災害を再現し、バックアップからデータベースを復元します。
この実験では、次の方法を学びます。
mysqldumpユーティリティを使用して論理バックアップを作成する。- データベースを削除して、重大な障害をシミュレートする。
- バックアップファイルからデータベースを元の状態に復元する。
論理バックアップには、スキーマとデータを再作成するための SQL 文が保存されます。データベースの生ファイルをコピーする物理バックアップとは異なります。どちらの方法も利用できますが、論理バックアップは初心者でも内容を読みやすく、理解しやすい方法です。
この違いは重要です。バックアップの種類によって解決できる問題が少しずつ異なるためです。論理バックアップは移植性が高く、人間が読みやすい形式です。一方、物理バックアップは通常、ストレージエンジンや復旧処理の内部に近い方法です。
バックアップを作成する
まず、保存する価値のあるデータベースが存在することを確認します。ここでは、ユーザーデータを含む app_db というデータベースをあらかじめ用意しています。
現在のデータを確認します。
sudo mysql -e "SELECT * FROM app_db.users;"
ユーザー（Alice、Bob、Charlie）の一覧が表示されます。
次に、mysqldump ツールを使用して論理バックアップを作成します。論理バックアップは基本的に、データベースをゼロから再構築するために必要なすべての SQL コマンド（CREATE TABLE や INSERT など）を含むテキストファイルをエクスポートしたものです。
つまり、バックアップファイルは正体不明のバイナリデータではありません。通常は SQL スクリプトとして保存され、後からデータベースサーバーで実行して、スキーマとデータを再構築できます。
次のコマンドを実行して、データベースを backup.sql というファイルに保存します。
sudo mysqldump app_db > ~/project/backup.sql
コマンドの内容：
mysqldump: データベースの内容をエクスポートするためのユーティリティです。app_db: バックアップ対象のデータベースです。>: コマンドの出力をファイルに送る Linux のリダイレクト演算子です。~/project/backup.sql: 保存先のファイルパスです。
バックアップファイルが作成されたことを確認します。
ls -l ~/project/backup.sql
ファイルの先頭を表示して、SQL コマンドの内容を確認することもできます。
head -n 20 ~/project/backup.sql
データ損失をシミュレートする
ここから、注意が必要な操作を行います。復旧計画をテストするため、障害を発生させます。ここでは、本番データベースを誤って削除した状況をシミュレートします。
警告： 以下のコマンドを実行すると、データが完全に削除されます。実際の本番環境では、データを破棄する意思が完全にある場合を除き、このコマンドを実行してはいけません。
この破壊的な手順を行うのは、実際にデータを失った後でも復旧できることを証明できて初めて、バックアップに意味があるためです。一度もテストしていないバックアップ戦略は、単なる思い込みにすぎません。
app_db データベースを削除します。
sudo mysql -e "DROP DATABASE app_db;"
データベースにアクセスして、障害が発生したことを確認します。
sudo mysql -e "USE app_db;"
次のエラーが表示されます。
ERROR 1049 (42000): Unknown database 'app_db'
これで、データベースが削除されたことを確認できます。バックアップのない本番サーバーで同じことが起きた場合、非常に深刻な事態です。
データベースを復元する
幸い、backup.sql ファイルがあります。このファイルを使用してデータを復元できます。
ただし、mysqldump はデフォルトでは、データベース自体を作成するコマンドではなく、データベースの内容だけをエクスポートします。app_db を完全に削除したため、まずデータを格納する空のデータベースを作成する必要があります。
この点を理解すると、バックアップに実際に何が保存されているのかが分かります。使用したコマンドとオプションに明示的に含めない限り、バックアップはすべてを保存した完全なスナップショットではありません。
空のデータベースを作成します。
sudo mysql -e "CREATE DATABASE app_db;"
バックアップファイルからデータをインポートします。
sudo mysql app_db < ~/project/backup.sql
復元コマンドの内容：
sudo mysql: データベースサーバーに接続します。app_db: 復元先として使用するデータベースを MySQL に指定します。<: Linux の入力リダイレクト演算子です。ファイルの内容を読み取り、入力したかのようにmysqlコマンドへ渡します。
コマンドを実行して何も表示されない場合、通常は成功しています。
復元処理では、SQL 文をデータベースサーバーに再び渡しています。つまり、復旧とは、論理バックアップに保存された命令を制御された形で再実行することです。
データが復旧したことを確認する
バックアップ計画で最後に行う、そして最も重要な手順は検証です。復元コマンドでエラーが発生しなかったからといって、データが正しいとは限りません。実際に確認する必要があります。
これは、システム運用全般で特に重要な習慣の一つです。成功とは「コマンドが終了したこと」ではありません。「その後のシステム状態が正しいこと」が成功です。
もう一度 users テーブルを検索します。
sudo mysql -e "SELECT * FROM app_db.users;"
成功条件：
元のデータが表示されます。
+----+---------+---------------------+
| id | name | email |
+----+---------+---------------------+
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.com |
| 3 | Charlie | charlie@example.com |
+----+---------+---------------------+
Alice、Bob、Charlie が表示されれば、災害からの復旧に成功しています。
まとめ
この実験では、完全な災害復旧サイクルを正常に完了しました。次の方法を学びました。
- バックアップ:
mysqldumpを使用してデータベースをファイルにエクスポートする。 - 破棄:
DROP DATABASEを使用してデータ損失をシミュレートする。 - 復元: 入力リダイレクト
<を使用して SQL ダンプファイルをインポートする。 - 検証: 復元したデータの整合性を確認する。
定期的なバックアップは、データ損失に対する最も重要な防御策です。実際の環境では、この処理を自動化し、復元テストを頻繁に行う必要があります。
