疑問
データベースのバックアップとリカバリは、どのように実施すればよいのでしょうか？災害対策の基礎について一緒に学んでいきましょう。
導入
データベースのバックアップとリカバリは、データ損失を防ぐための重要な対策です。適切なバックアップ戦略により、システム障害や人的ミスからデータを保護できます。
本記事では、バックアップの種類から、リカバリ手順、災害対策まで、実践的な方法を詳しく解説していきます。
解説
1. バックアップの種類
データベースのバックアップには、フルバックアップ、差分バックアップ、増分バックアップなど、様々な種類があります。それぞれの特徴を理解し、用途に応じて適切な方法を選択することが重要です。
フルバックアップ
フルバックアップは、データベース全体を完全にコピーする方法です。最もシンプルで確実な方法ですが、データ量が多い場合、時間とストレージ容量を多く消費します。通常、定期的に（例：週1回）実行し、他のバックアップ方法のベースとして使用されます。
差分バックアップ
差分バックアップは、最後のフルバックアップ以降に変更されたデータのみをバックアップします。フルバックアップと最新の差分バックアップを組み合わせることで、データを復元できます。増分バックアップよりもバックアップサイズは大きくなりますが、リカバリが簡単です。
増分バックアップ
増分バックアップは、最後のバックアップ以降に変更されたデータのみをバックアップします。バックアップサイズが小さく、時間も短縮できますが、リカバリ時にはフルバックアップとすべての増分バックアップが必要になります。頻繁にバックアップを取得する場合に適しています。
スナップショット
スナップショットは、特定の時点でのデータベースの状態を保存します。ストレージレベルで実装されることが多く、高速に作成・復元できます。ただし、ストレージシステムに依存するため、すべての環境で利用できるわけではありません。
フルバックアップの実行例
これらの例では、MySQLとPostgreSQLでフルバックアップと特定データベースのバックアップを実行しています。日付を含むファイル名で保存し、圧縮も可能です。
# MySQL: フルバックアップ
mysqldump -u root -p --all-databases > full_backup_$(date +%Y%m%d).sql
# MySQL: 特定のデータベースのバックアップ
mysqldump -u root -p mydatabase > mydatabase_backup_$(date +%Y%m%d).sql
# PostgreSQL: フルバックアップ
pg_dumpall -U postgres > full_backup_$(date +%Y%m%d).sql
# PostgreSQL: 特定のデータベースのバックアップ
pg_dump -U postgres mydatabase > mydatabase_backup_$(date +%Y%m%d).sql
# 圧縮してバックアップ
mysqldump -u root -p mydatabase | gzip > mydatabase_backup_$(date +%Y%m%d).sql.gz参考リンク： MySQL公式ドキュメント - バックアップとリカバリ - MySQLのバックアップとリカバリに関する公式ドキュメント
2. バックアップ戦略
適切なバックアップ戦略を立てることで、データ損失のリスクを最小限に抑えられます。3-2-1ルールに従い、定期的なバックアップとテストを実施することが重要です。
3-2-1ルール
3-2-1ルールとは、データのコピーを3つ作成し、2つの異なるメディアに保存し、1つはオフサイトに保存するというルールです。これにより、ハードウェア障害、ソフトウェア障害、災害など、様々なリスクからデータを保護できます。
バックアップスケジュール
バックアップスケジュールは、データの重要度と変更頻度に応じて設定します。重要なデータは頻繁に（例：毎日）、それほど重要でないデータは定期的に（例：週1回）バックアップします。また、業務時間外にバックアップを実行することで、パフォーマンスへの影響を最小限に抑えられます。
バックアップの保存場所
バックアップは、ローカルストレージ、ネットワークストレージ、クラウドストレージなど、複数の場所に保存します。オフサイトバックアップにより、災害時にもデータを保護できます。また、暗号化により、バックアップのセキュリティを確保します。
バックアップの検証
バックアップが正常に作成されていることを確認するため、定期的にバックアップファイルの整合性をチェックします。また、実際にリカバリテストを実施し、バックアップからデータを復元できることを確認します。
自動バックアップスクリプト
この例では、自動バックアップスクリプトを示しています。データベースのバックアップ、古いバックアップの削除、クラウドストレージへのアップロード、バックアップの検証を行っています。
#!/bin/bash
# 自動バックアップスクリプトの例
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mydatabase"
RETENTION_DAYS=30
# バックアップディレクトリの作成
mkdir -p $BACKUP_DIR
# データベースのバックアップ
mysqldump -u root -p$MYSQL_PASSWORD $DB_NAME | gzip > $BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz
# 古いバックアップの削除（30日以上前）
find $BACKUP_DIR -name "${DB_NAME}_*.sql.gz" -mtime +$RETENTION_DAYS -delete
# クラウドストレージへのアップロード（例：AWS S3）
aws s3 cp $BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz s3://my-backup-bucket/mysql/
# バックアップの検証（ファイルサイズの確認）
if [ -s $BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz ]; then
echo "バックアップが正常に作成されました: ${DB_NAME}_${DATE}.sql.gz"
else
echo "エラー: バックアップファイルが空です"
exit 1
fi3. リカバリ手順
適切なリカバリ手順を理解し、実際にリカバリテストを実施することで、災害時に迅速にデータを復元できます。フルバックアップからのリカバリとポイントインタイムリカバリ（PITR）の方法を理解することが重要です。
フルバックアップからのリカバリ
フルバックアップからデータベースを復元するには、まずデータベースを停止し、既存のデータを削除または移動します。その後、バックアップファイルをインポートします。MySQLではmysqlコマンド、PostgreSQLではpsqlコマンドを使用します。
ポイントインタイムリカバリ（PITR）
ポイントインタイムリカバリ（PITR）は、特定の時点までのデータを復元する方法です。バイナリログ（MySQL）やWAL（PostgreSQL）を使用して、フルバックアップ以降の変更を適用します。これにより、データ損失を最小限に抑えられます。
リカバリテスト
リカバリテストは、バックアップの有効性を確認するために重要です。定期的に（例：月1回）テスト環境でリカバリを実施し、手順を文書化し、所要時間を記録します。これにより、実際の災害時に迅速に対応できます。
リカバリ時間目標（RTO）とリカバリポイント目標（RPO）
RTO（Recovery Time Objective）は、システムを復旧するまでの目標時間です。RPO（Recovery Point Objective）は、許容できるデータ損失の最大時間です。これらの目標に基づいて、バックアップの頻度と方法を決定します。
フルバックアップからのリカバリ手順
これらの例では、MySQLとPostgreSQLでフルバックアップからデータベースを復元する手順を示しています。既存データのバックアップを取ってから復元を実行します。
# MySQL: フルバックアップからのリカバリ
# 1. データベースの停止（必要に応じて）
systemctl stop mysql
# 2. 既存データのバックアップ（念のため）
mv /var/lib/mysql /var/lib/mysql.old
# 3. データベースの復元
mysql -u root -p < full_backup_20240222.sql
# または、特定のデータベースのみ復元
mysql -u root -p mydatabase < mydatabase_backup_20240222.sql
# 4. データベースの起動
systemctl start mysql
# PostgreSQL: フルバックアップからのリカバリ
# 1. データベースの停止
systemctl stop postgresql
# 2. 既存データのバックアップ
mv /var/lib/postgresql/data /var/lib/postgresql/data.old
# 3. データベースの復元
psql -U postgres < full_backup_20240222.sql
# または、特定のデータベースのみ復元
psql -U postgres -d mydatabase < mydatabase_backup_20240222.sql
# 4. データベースの起動
systemctl start postgresqlポイントインタイムリカバリ（PITR）の手順
これらの例では、MySQLとPostgreSQLでポイントインタイムリカバリ（PITR）を実行する手順を示しています。特定の時点までのデータを復元できます。
# MySQL: ポイントインタイムリカバリ（PITR）
# 1. フルバックアップの復元
mysql -u root -p < full_backup_20240222.sql
# 2. バイナリログの確認
mysqlbinlog --start-datetime="2024-02-22 10:00:00" \
--stop-datetime="2024-02-22 14:30:00" \
/var/log/mysql/mysql-bin.000001 | mysql -u root -p
# PostgreSQL: ポイントインタイムリカバリ（PITR）
# 1. recovery.confの設定
cat > /var/lib/postgresql/data/recovery.conf << EOF
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2024-02-22 14:30:00'
EOF
# 2. フルバックアップの復元
pg_basebackup -D /var/lib/postgresql/data -Ft -z -P
# 3. PostgreSQLの起動（自動的にリカバリが実行される）
systemctl start postgresql参考リンク： PostgreSQL公式ドキュメント - 継続的アーカイブとポイントインタイムリカバリ - PostgreSQLのポイントインタイムリカバリに関する公式ドキュメント
4. レプリケーション
レプリケーションは、データベースの可用性とパフォーマンスを向上させるための技術です。マスター・スレーブレプリケーションにより、バックアップの代替手段としても使用できます。
マスター・スレーブレプリケーション
マスター・スレーブレプリケーションでは、マスターデータベースが書き込みを処理し、スレーブデータベースが読み取りを処理します。マスターに障害が発生した場合、スレーブをマスターに昇格させることで、迅速にサービスを復旧できます。また、スレーブをバックアップの取得に使用することもできます。
マスター・マスターレプリケーション
マスター・マスターレプリケーションでは、複数のマスターデータベースが相互にレプリケーションを行います。書き込みの負荷分散が可能ですが、競合解決が必要になる場合があります。
レプリケーションの設定
MySQLでは、バイナリログを有効にし、スレーブサーバーでCHANGE MASTERコマンドを実行します。PostgreSQLでは、WALアーカイブを有効にし、pg_basebackupとrecovery.confを使用してスレーブを設定します。
MySQLレプリケーションの設定
この例では、MySQLでマスター・スレーブレプリケーションを設定する手順を示しています。マスター側でレプリケーション用ユーザーを作成し、スレーブ側でCHANGE MASTERコマンドを実行します。
-- MySQL: マスター・スレーブレプリケーションの設定
-- マスター側の設定（my.cnf）
-- [mysqld]
-- server-id = 1
-- log-bin = mysql-bin
-- binlog-format = ROW
-- レプリケーション用ユーザーの作成
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
-- マスターの状態を確認
SHOW MASTER STATUS;
-- スレーブ側の設定
CHANGE MASTER TO
MASTER_HOST='master.example.com',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
-- レプリケーションの開始
START SLAVE;
-- レプリケーションの状態を確認
SHOW SLAVE STATUS\GPostgreSQLレプリケーションの設定
この例では、PostgreSQLでマスター・スレーブレプリケーションを設定する手順を示しています。WALアーカイブを有効にし、pg_basebackupでベースバックアップを取得します。
# PostgreSQL: マスター・スレーブレプリケーションの設定
# マスター側の設定（postgresql.conf）
# wal_level = replica
# max_wal_senders = 3
# archive_mode = on
# archive_command = 'cp %p /backup/wal/%f'
# レプリケーション用ユーザーの作成
psql -U postgres -c "CREATE USER repl WITH REPLICATION PASSWORD 'password';"
# pg_hba.confに追加
# host replication repl 0.0.0.0/0 md5
# スレーブ側の設定
# 1. ベースバックアップの取得
pg_basebackup -h master.example.com -D /var/lib/postgresql/data -U repl -P -W
# 2. recovery.confの作成
cat > /var/lib/postgresql/data/recovery.conf << EOF
standby_mode = 'on'
primary_conninfo = 'host=master.example.com port=5432 user=repl password=password'
trigger_file = '/tmp/postgresql.trigger'
EOF
# 3. PostgreSQLの起動（自動的にスタンバイモードで起動）5. 災害対策とBCP
災害対策とBCP（事業継続計画）は、組織全体で取り組むべき重要な課題です。データベースのバックアップとリカバリは、BCPの重要な要素の一つです。
災害の種類
- 自然災害: 地震、洪水、火災などの自然災害により、データセンターが被害を受ける可能性があります。オフサイトバックアップにより、データを保護できます。
- ハードウェア障害: ディスク障害、メモリ障害、ネットワーク障害などのハードウェア障害により、データが損失する可能性があります。レプリケーションやRAIDにより、可用性を向上させます。
- ソフトウェア障害: バグ、クラッシュ、データ破損などのソフトウェア障害により、データが損失する可能性があります。定期的なバックアップにより、データを保護できます。
- 人的ミス: 誤削除、誤更新、設定ミスなどの人的ミスにより、データが損失する可能性があります。アクセス制御と監査ログにより、リスクを軽減します。
- サイバー攻撃: ランサムウェア、SQLインジェクション、不正アクセスなどのサイバー攻撃により、データが損失または改ざんされる可能性があります。セキュリティ対策とバックアップにより、リスクを軽減します。
BCP（事業継続計画）
BCP（Business Continuity Plan）は、災害時に事業を継続するための計画です。データベースのバックアップとリカバリは、BCPの重要な要素の一つです。RTOとRPOを定義し、バックアップ戦略を最適化します。また、定期的にBCPの訓練を実施し、計画の有効性を確認します。
DR（災害復旧）計画
DR（Disaster Recovery）計画は、災害後にシステムを復旧するための計画です。バックアップの場所、リカバリ手順、担当者の役割、連絡先などを文書化します。また、定期的にDR訓練を実施し、計画の有効性を確認します。
6. クラウド環境でのバックアップ
クラウド環境では、マネージドサービスのバックアップ機能を活用することで、効率的にバックアップとリカバリを実施できます。AWS RDS、Azure Database、Google Cloud SQLなどのサービスでは、自動バックアップ機能が提供されています。
AWS RDSのバックアップ
AWS RDSでは、自動バックアップが有効になっている場合、毎日自動的にバックアップが作成されます。バックアップは、指定した保持期間（最大35日）保存されます。また、手動スナップショットを作成することで、任意の時点でのバックアップを取得できます。スナップショットは、削除するまで永続的に保存されます。
Azure Databaseのバックアップ
Azure Databaseでは、自動バックアップが有効になっており、最大35日間のバックアップが保存されます。ポイントインタイムリカバリ（PITR）により、任意の時点までのデータを復元できます。また、長期保持オプションにより、最大10年間バックアップを保存できます。
Google Cloud SQLのバックアップ
Google Cloud SQLでは、自動バックアップが有効になっている場合、毎日自動的にバックアップが作成されます。バックアップは、指定した保持期間（最大365日）保存されます。また、オンデマンドバックアップを作成することで、任意の時点でのバックアップを取得できます。
クラウド環境でのバックアップとリカバリ
これらの例では、AWS RDS、Azure Database、Google Cloud SQLでバックアップとリカバリを実行する方法を示しています。
# AWS RDS: 手動スナップショットの作成
aws rds create-db-snapshot \
--db-instance-identifier mydbinstance \
--db-snapshot-identifier mydbinstance-snapshot-$(date +%Y%m%d)
# AWS RDS: スナップショットからの復元
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier mydbinstance-restored \
--db-snapshot-identifier mydbinstance-snapshot-20240222
# Azure Database: ポイントインタイムリカバリ
az mysql flexible-server restore \
--resource-group myResourceGroup \
--name mydbserver-restored \
--source-server mydbserver \
--restore-time "2024-02-22T14:30:00Z"
# Google Cloud SQL: オンデマンドバックアップの作成
gcloud sql backups create \
--instance=mydbinstance \
--description="Manual backup $(date +%Y%m%d)"
# Google Cloud SQL: バックアップからの復元
gcloud sql backups restore BACKUP_ID \
--backup-instance=mydbinstance参考リンク： AWS RDS公式ドキュメント - バックアップとリカバリ - AWS RDSのバックアップとリカバリに関する公式ドキュメント
7. ベストプラクティス
データベースのバックアップとリカバリを効率的に実施するためには、いくつかのベストプラクティスに従うことが重要です。定期的なバックアップ、リカバリテスト、適切な保存場所の選択など、実践的なアドバイスを提供します。
- 定期的なバックアップ: データの重要度と変更頻度に応じて、適切な頻度でバックアップを実施します。重要なデータは毎日、それほど重要でないデータは週1回など、スケジュールを設定します。
- 3-2-1ルールの遵守: データのコピーを3つ作成し、2つの異なるメディアに保存し、1つはオフサイトに保存します。これにより、様々なリスクからデータを保護できます。
- リカバリテストの実施: 定期的にリカバリテストを実施し、バックアップからデータを復元できることを確認します。手順を文書化し、所要時間を記録します。
- バックアップの検証: バックアップが正常に作成されていることを確認するため、定期的にバックアップファイルの整合性をチェックします。ファイルサイズ、チェックサム、実際のリカバリテストなどで検証します。
- 自動化: バックアッププロセスを自動化することで、人的ミスを防ぎ、一貫性を保つことができます。cronジョブやスケジューラーを使用して、自動バックアップを設定します。
- セキュリティ: バックアップファイルを暗号化し、適切なアクセス制御を実施します。また、バックアップの保存場所もセキュアにします。
- 監視とアラート: バックアップの成功・失敗を監視し、失敗時にはアラートを送信します。これにより、問題を早期に発見し、対応できます。
- 文書化: バックアップとリカバリの手順を文書化し、担当者が変更になっても対応できるようにします。また、BCPやDR計画も文書化します。
まとめ
データベースのバックアップとリカバリは、データ損失を防ぐための重要な対策です。3-2-1ルールに従ったバックアップ戦略、定期的なバックアップ、ポイントインタイムリカバリなど、適切な手法を実装することで、災害からデータを保護できます。
レプリケーションにより、可用性とパフォーマンスを向上させ、バックアップの代替手段としても使用できます。クラウド環境では、マネージドサービスのバックアップ機能を活用することで、効率的にバックアップとリカバリを実施できます。
定期的にリカバリテストを実施し、バックアップの有効性を確認することが重要です。実践的なプロジェクトでバックアップ戦略を実装し、経験を積むことで、より安全なデータベース運用ができるようになります。