Development

データベースバックアップ戦略：シンプルなダンプを超えて

Created   Updated
Database Backup MySQL PostgreSQL
  1. データベースバックアップの種類
  2. データベースバックアップの一般的な誤解
  3. 高度なデータベースバックアップ技術
  4. データベースバックアップ実装チェックリスト
  5. データベースバックアップ vs 一般データバックアップ
  6. データベース固有の考慮事項
  7. 選択を行う

データベースは単なるファイルではありません。それらは活発でトランザクショナルなシステムであり、データの整合性を保つために専門的なバックアップ手法が必要です。一般的なバックアップ戦略が基本的なフレームワークを提供する一方で、データベースバックアップには独特の技術的課題があります：ACID準拠、参照整合性、トランザクション整合性です。

この記事では、基本的なダンプ操作を超えて、データベース固有のバックアップ技術を深く掘り下げ、ポイントインタイムリカバリ、クロスデータベース整合性、パフォーマンス最適化されたバックアップ手法などの高度な戦略をカバーします。

包括的なデータ価値評価と一般的なバックアップ戦略については、データバックアップ戦略 - 計画から復旧までをご参照ください。

データベースバックアップの種類

論理バックアップ vs 物理バックアップ

論理バックアップ：データベース構造とデータをSQL文または特定の形式でエクスポートします。

利点：

  • 高い可搬性、異なるデータベースバージョン間で使用可能
  • 人間が読める形式で、デバッグや部分復旧が容易
  • 圧縮効果が高い
  • 特定のテーブルやデータを選択的にバックアップ可能

欠点：

  • 復旧速度が遅い、特に大規模データベースの場合
  • エクスポート/インポートでより多くのCPUリソースが必要
  • すべてのデータベースオブジェクト（ストアドプロシージャ、トリガーなど）をキャプチャできない場合がある

物理バックアップ：実際のデータベースファイルとログをコピーします。

利点：

  • 復旧速度が速い
  • 完全なバックアップ、すべてのデータベースオブジェクトを含む
  • 増分および差分バックアップをサポート
  • 大規模データベースに適している

欠点：

  • プラットフォーム依存性が強い
  • ファイルサイズが通常より大きい
  • 整合性を確保するためにデータベース停止または特別なツールが必要

完全バックアップ vs 増分バックアップ

バックアップタイプ データ量 復旧時間 ストレージ要件 複雑さ
完全バックアップ 全データ 高速 高 低
増分バックアップ 変更のみ 中程度（複数ファイル必要） 低 中程度
差分バックアップ 前回完全バックアップからの変更 中程度 中程度 中程度
トランザクションログバックアップ トランザクション記録 最速（ポイントインタイムリカバリ） 最低 高

データベースバックアップの一般的な誤解

🔄 vMotion/ライブマイグレーションはバックアップ

現実：VM移行技術は実行中のシステムを移動しますが、復旧ポイントは作成しません。

なぜ間違いか：vMotionはメンテナンスや負荷分散のためにVM間でホストを移動します。バックアップを作成せず、データ破損から保護せず、ポイントインタイムリカバリも提供しません。データベースが破損した場合、vMotionは破損したデータベースを別のホストに移動するだけです。

正しいアプローチ：高可用性とメンテナンスにはvMotionを使用し、データ保護には適切なデータベースバックアップ手法を使用します。

📁 ファイルシステムバックアップがデータベースを保護

現実：データベースが実行中にデータベースファイルをコピーすると、破損した使用不可能なバックアップが作成される可能性があります。

なぜ間違いか：データベースファイルは常に変更されています。アクティブな操作中のファイルレベルバックアップは、一部の変更が書き込まれているが他の変更が書き込まれていない不整合な状態をキャプチャし、ACID特性に違反する可能性があります。

正しいアプローチ：トランザクション整合性を確保するデータベース対応のバックアップ手法を使用します。

🔄 レプリケーションはバックアップ

現実：レプリケーションは高可用性を提供しますが、論理的な破損やユーザーエラーから保護しません。

なぜ間違いか：誰かがテーブルを削除したりデータを破損させたりすると、その破損はすべてのレプリカに複製されます。レプリケーションはポイントインタイムリカバリやデータを破損させるアプリケーションバグからの保護を提供しません。

正しいアプローチ：可用性にはレプリケーションを使用し、データ保護と復旧にはバックアップを使用します。

📊 読み取りレプリカはバックアップが不要

現実：読み取りレプリカは破損したり、遅延したり、プライマリとは独立して障害を起こす可能性があります。

なぜ間違いか：読み取りレプリカはバックアップではありません—それらは独自の障害を経験する可能性のあるライブコピーです。レプリカの遅延はデータ損失を引き起こし、レプリカの破損は復旧に使用できなくなる可能性があります。

正しいアプローチ：読み取りレプリカを独立してバックアップし、定期的にその整合性を検証します。

⏰ 計画停止時間がバックアップの必要性を排除

現実：メンテナンスウィンドウ中でも、データベースは破損や人的エラーを経験する可能性があります。

なぜ限定的か：計画メンテナンスはハードウェア障害、ソフトウェアバグ、人的ミスを防ぎません。破損はいつでも発生する可能性があり、迅速な復旧には最新のバックアップが不可欠です。

正しいアプローチ：メンテナンスウィンドウに関係なく、定期的なバックアップスケジュールを維持します。

🏥 災害復旧はデータベースバックアップ

現実：災害復旧（DR）は包括的な事業継続戦略であり、データベースバックアップはデータ保護の一つのコンポーネントです。

なぜ異なるか：DRにはフェイルオーバーシステム、代替サイト、ネットワーク冗長性、ビジネスプロセス継続性が含まれます。データベースバックアップは特にデータ復旧に焦点を当てます。DRシステムはライブレプリケーションを使用する場合があり、これはポイントインタイムリカバリや論理的破損からの保護を提供しません。

正しいアプローチ：事業継続性と高可用性にはDRを使用し、データ保護とポイントインタイムリカバリにはデータベースバックアップを使用します。それらは互いを補完しますが、異なる目的を果たします。

高度なデータベースバックアップ技術

ポイントインタイムリカバリ (PITR)

ベースバックアップとトランザクションログを使用して、データベースを任意の特定の時刻に復元します。

実装方法：

# PostgreSQL PITR 設定
# 1. ベースバックアップを取る
pg_basebackup -D /backup/base -Ft -z -P

# 2. 継続アーカイブを設定
# postgresql.conf で：
# archive_mode = on
# archive_command = 'cp %p /backup/wal/%f'

# 3. 特定時刻への復旧
cat > recovery.conf << EOF
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2022-10-11 15:45:00'
recovery_target_action = 'promote'
EOF

クロスデータベース整合性

バックアップ中に複数の関連データベース間の整合性を確保します。

協調バックアップ：

#!/bin/bash
# 複数データベースの協調バックアップ

# すべてのデータベースでトランザクションを開始
mysql db1 -e "START TRANSACTION WITH CONSISTENT SNAPSHOT;"
mysql db2 -e "START TRANSACTION WITH CONSISTENT SNAPSHOT;"

# 整合性のためにLSN/位置を記録
mysql db1 -e "SHOW MASTER STATUS;" > backup_position.txt
mysql db2 -e "SHOW MASTER STATUS;" >> backup_position.txt

# バックアップを実行
mysqldump --single-transaction db1 > db1_backup.sql &
mysqldump --single-transaction db2 > db2_backup.sql &

wait  # すべてのバックアップの完了を待つ

# トランザクションをコミット
mysql db1 -e "COMMIT;"
mysql db2 -e "COMMIT;"

バックアップの圧縮と暗号化

ストレージコストを削減し、機密データを保護します。

圧縮暗号化バックアップ：

# MySQL 圧縮と暗号化付きバックアップ
mysqldump --single-transaction --routines --triggers database_name | \
  gzip -9 | \
  gpg --symmetric --cipher-algo AES256 \
  > backup_$(date +%Y%m%d_%H%M%S).sql.gz.gpg

# PostgreSQL 内蔵圧縮付きバックアップ
pg_dump --format=custom --compress=9 database_name | \
  gpg --symmetric --cipher-algo AES256 \
  > backup_$(date +%Y%m%d_%H%M%S).dump.gpg

バックアップの検証とテスト

バックアップが有効で復元可能であることを確保します。

自動バックアップテスト：

#!/bin/bash
# 自動バックアップ検証スクリプト

BACKUP_FILE="$1"
TEST_DB="backup_test_$(date +%s)"

# テストデータベースを作成
mysql -e "CREATE DATABASE $TEST_DB;"

# バックアップをテストデータベースに復元
if mysql $TEST_DB < $BACKUP_FILE; then
    echo "成功: バックアップが正常に復元されました"
    
    # 整合性チェックを実行
    mysqlcheck --check --all-databases $TEST_DB
    
    # 行数が期待値と一致するか検証
    EXPECTED_ROWS=$(mysql -sN -e "SELECT COUNT(*) FROM production.users;")
    ACTUAL_ROWS=$(mysql -sN -e "SELECT COUNT(*) FROM $TEST_DB.users;")
    
    if [ "$EXPECTED_ROWS" -eq "$ACTUAL_ROWS" ]; then
        echo "成功: 行数検証が成功しました"
    else
        echo "エラー: 行数の不一致 - 期待値: $EXPECTED_ROWS, 実際: $ACTUAL_ROWS"
    fi
else
    echo "エラー: バックアップの復元に失敗しました"
fi

# テストデータベースをクリーンアップ
mysql -e "DROP DATABASE $TEST_DB;"

データベースバックアップ実装チェックリスト

バックアップ戦略：

  • ✅ データベース固有のRPOおRTO要件を定義
  • ✅ 適切なバックアップ手法を選択（論理、物理、トランザクションログ）
  • ✅ ポイントインタイムリカバリ機能を実装
  • ✅ クロスデータベース整合性戦略を設計

整合性と完全性：

  • ✅ トランザクション一貫性のあるバックアップ手法を使用
  • ✅ 復元後に参照整合性を検証
  • ✅ バックアップと復元手順を定期的にテスト
  • ✅ バックアップ完了と成功率を監視

パフォーマンスと可用性：

  • ✅ 本番システムへのバックアップ影響を最小化
  • ✅ 可能な限り読み取りレプリカをバックアップ操作に使用
  • ✅ 並列バックアップと復元プロセスを実装
  • ✅ 低活動期間にバックアップをスケジュール

セキュリティとコンプライアンス：

  • ✅ 機密データベースバックアップを暗号化
  • ✅ 安全なバックアップストレージとアクセス制御を実装
  • ✅ バックアップと復元操作の監査ログを維持
  • ✅ 規制データ保存要件を満たす

監視とアラート：

  • ✅ バックアップジョブの完了と持続時間を監視
  • ✅ バックアップ失敗や異常に対してアラート
  • ✅ バックアップストレージ使用量と成長を追跡
  • ✅ バックアップの完全性を自動検証

データベースバックアップ vs 一般データバックアップ

データベースバックアップ：ACID特性とトランザクション整合性を尊重する特化したバックアップ手法。

一般データバックアップ：ドキュメント、設定、静的データに適したファイルレベルバックアップ。

主な違い：

面 データベースバックアップ 一般データバックアップ
整合性 トランザクション ファイルレベル
手法 論理、物理、WAL 完全、増分、差分
複雑さ 高 中程度
復旧 ポイントインタイム ファイル復元
パフォーマンス影響 データベース認識 ストレージレベル
検証 ACIDコンプライアンス ファイル完全性

データベース固有の考慮事項

データベースバックアップの決定には、一般的なデータ保護を超えた独特の技術的およびビジネス上の考慮事項があります：

技術的複雑さ：

  • ACIDコンプライアンス：バックアップ中のトランザクション整合性の確保
  • 参照整合性：外部キー関係の維持
  • パフォーマンス影響：本番システムへの干渉の最小化
  • 復旧粒度：ポイントインタイム vs 完全データベース復元

ビジネス要因：

  • データの重要性：顧客レコード vs ログデータ vs ユーザー生成コンテンツ
  • コンプライアンス要件：金融や医療データの規制要件
  • 復旧時間目標：データベースはどの程度迅速に復元される必要があるか？
  • 整合性要件：一部のデータ損失や不整合を許容できるか？

SaaSデータベースの考慮事項：
マネージドデータベースサービスを使用する場合は、以下を評価してください：

  • プロバイダーのバックアップ機能とSLA
  • データのエクスポート/インポート能力
  • ベンダーロックインリスクとデータポータビリティ
  • 追加バックアップ層の実装コスト

包括的なデータ価値評価フレームワークについては、データバックアップ戦略 - 計画から復旧までをご参照ください。

選択を行う

データベースバックアップは単なる別のバックアップタスクではありません—それはデータベース内部、トランザクション処理、整合性要件の理解が必要な専門分野です。しかし、さらに重要なことは、それはリスク、価値、リソース配分に関するビジネス決定であることです。

まずは、あなたのデータベースの特定のバックアップ機能と要件を理解することから始めましょう。しかしまずは、あなたのデータのビジネス価値と、損失コスト対保護コストを理解することが必要です。あなたのデータベースプラットフォームとビジネスニーズに適したトランザクション一貫性のあるバックアップ手法を実装してください。

覚えておいてください：データベースバックアップは、重要なデータのビジネス継続性の保証です。正しく実装された場合、あなたの最も貴重な資産—あなたのデータ—があらゆる災害を乗り越えられるという信頼を提供します。適切に実装されない場合、偽の安全感を提供します。低価値データに対して完全にスキップされた場合、それは賂明なリソース配分を表します。

データベースバックアップ戦略を設計する際は、データベース設計と同じように細心に行いますが、常にビジネス価値とリスク管理の観点から行ってください。あなたの将来の自分—そしてあなたのビジネス—があなたに感謝するでしょう。

データベースを超えたより包括的なバックアップ戦略については、データバックアップ戦略 - 計画から復旧までをご参照ください。

シェア