Categories
Database Backup

** Discover the hidden dangers of DIY database backup scripts. Learn why custom Bash scripts fail in production, the risks of logical dumps, and how to secure your data with enterprise solutions.

すべてのデータベース管理者（DBA）やシステムエンジニアは、キャリアのどこかでデータベースをバックアップするためのカスタムシェルスクリプトを書いたことがあるはずです。これは実質的に通過儀礼のようなものです。プロジェクトの初期段階では、mysqldump や pg_dump を実行し、その出力を gzip にパイプする単純な cron ジョブは、エレガントで軽量、かつ費用対効果の高いソリューションに見えます。

しかし、インフラが拡張され、データ量が増加し、稼働率のSLA（サービス品質保証）が厳しくなるにつれ、その10行のBashスクリプトは静かに時限爆弾へと変貌します。本番環境には、高可用性、厳格な目標復旧時点（RPO）、および迅速な目標復旧時間（RTO）が求められます。このような環境でDIY（自作）のバックアップスクリプトに依存することは、データの整合性、サイレント障害、セキュリティの脆弱性、そして管理不能な復旧プロセスに関連する深刻なリスクをもたらします。

本記事では、DIYデータベースバックアップスクリプトのアーキテクチャ上の欠陥と隠れた危険性を解剖し、論理バックアップと物理バックアップの技術的な落とし穴を探り、ミッションクリティカルなデータを保護するためにCloudSaveのようなエンタープライズグレードのソリューションへ移行する方法について議論します。

単純さという幻想：古典的なDIYスクリプトの解剖

危険性を理解するために、まずは典型的なDIYバックアップスクリプトの構造を見てみましょう。MySQLデータベースに対する標準的なアプローチは、多くの場合以下のようになります：

#!/bin/bash
# シンプルなDIY MySQLバックアップスクリプト
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"

mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz

# 30日以上前のバックアップを削除
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

一見すると、このスクリプトは目的を達成しているように見えます。データを抽出し、圧縮し、保持期間を管理しています。しかしその裏側には、最終的に本番環境でのデータ損失につながる重大な欠陥が潜んでいます。

危険1：サイレント障害とパイプの罠

DIYスクリプトの最も陰湿な危険の一つが「サイレント障害」です。上記のスクリプトでは、mysqldump コマンドが直接 gzip にパイプ（|）されています。

Bashにおいて、パイプラインの終了ステータスは、パイプライン内の最後のコマンドの終了ステータスとなります。もしデータベースサーバーのメモリが不足したり、接続が切断されたり、ダンプの途中でテーブルがロックされたりして mysqldump が失敗しエラーを投げたとしても、gzip は受け取った部分的な出力を正常に圧縮し、終了コード 0（成功）を返して終了します。

cron ジョブの終了コードをチェックする監視システムは、バックアップが成功したと報告します。ディスク上には有効な .gz ファイルが存在しますが、その中身は切り詰められた役に立たないSQLファイルです。これは、実際に重要な復旧を試みるまで気づくことはありません。

緩和策（とその限界）

エンジニアは、Bashで厳格なエラーハンドリングを有効にすることでこれを修正しようとすることがよくあります：

set -e
set -o pipefail

set -o pipefail はパイプライン内のいずれかのコマンドが失敗した場合にスクリプトを確実に失敗させますが、それでもスクリプトの周囲に堅牢なアラート、ログ記録、再試行メカニズムを構築する必要があります。午前2時に一時的なネットワークエラーで失敗が発生した場合、DIYスクリプトは単に停止するだけです。エンタープライズプラットフォームは、インテリジェントな指数バックオフ再試行によって、こうした一時的なエラーを処理します。

危険2：データの整合性とロックの悪夢

DIYスクリプトは、論理バックアップ（mysqldump、pg_dump）に大きく依存しています。論理バックアップは、すべてのテーブルに対して SELECT 文を実行することでデータを抽出します。高トランザクションの本番データベースでは、データは常に変化しています。もし100GBのデータベースをダンプするのに45分かかる場合、ダンプの開始時点のデータは終了時点のデータよりも45分古くなり、ACID準拠に違反することになります。

MySQLのトランザクション整合性

InnoDBを使用してMySQLで整合性のあるスナップショットを取得するには、特定のフラグを渡す必要があります：

mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql

--single-transaction フラグは、分離レベルを REPEATABLE READ に設定し、ダンプ前にトランザクションを開始します。しかし、データベースにレガシーなMyISAMテーブルが含まれている場合、このフラグではロックを防ぐことができず、バックアップ実行中に本番環境の読み書きトラフィックが停止する可能性があります。さらに、バックアップ中に開発者が実行した ALTER TABLE、DROP TABLE、または RENAME TABLE 文は REPEATABLE READ スナップショットを破壊し、ダンプを失敗させます。

PostgreSQLとWALアーカイビング

PostgreSQLの場合、pg_dump は整合性のある論理バックアップを提供しますが、論理バックアップ単体ではポイントインタイムリカバリ（PITR）を提供できません。午後4時にデータベースがクラッシュし、最後のcronスクリプトが深夜0時に実行されていた場合、16時間分のデータを失うことになります。

PITRを実現するには、先行書き込みログ（WAL）の継続的なアーカイブが必要です。archive_command を安全に処理するDIYスクリプトを書くことは非常に困難です。

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

もし保存先ストレージ（/mnt/wal_archive/）がいっぱいになったり利用できなくなったりすると、archive_command は失敗します。するとPostgreSQLはプライマリディスクがいっぱいになるまでWALファイルをローカルに溜め込み、データベース全体の停止を引き起こします。DIYスクリプトが、WALの蓄積を監視し、停止が発生する前に管理者に警告するテレメトリを備えていることは稀です。

危険3：保持期間のロシアンルーレット

最初のスクリプトの保持コマンドを振り返ってみましょう：

find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

これは壊滅的なデータ損失を招く可能性のある処理です。設定変更によって mysqldump の認証が失敗するシナリオを想像してください。スクリプトは新しいバックアップの作成に失敗しますが、find コマンドは毎晩実行され続け、30日以上前のファイルを忠実に削除し続けます。

30日間のバックアップ失敗が続いた後、find コマンドは最後に残った有効なバックアップを削除してしまいます。その結果、バックアップが一つも存在しない状態になります。

CloudSaveのようなエンタープライズバックアップソフトウェアは、ステートフルな保持ポリシーを利用します。これは「30日以上前のバックアップを削除する」ことと、「古いデータを削除する前に、少なくとも30個の成功した復旧ポイントが存在することを確認する」ことの違いを理解しています。

危険4：セキュリティ、暗号化、およびコンプライアンスの死角

ランサムウェアや厳格なコンプライアンスフレームワーク（GDPR、HIPAA、SOC 2）の時代において、バックアップは主要な標的です。DIYスクリプトは、セキュリティのベストプラクティスに違反することがよくあります：

  1. ハードコードされた認証情報： データベースのパスワードをプレーンテキストのスクリプトやcron定義に保存することは、重大なセキュリティリスクです。MySQLの mysql_config_editor や PostgreSQLの .pgpass ファイルのようなツールはこれを緩和しますが、それでもサーバー上のローカルキーファイルを管理する必要があります。
  2. 保存時の暗号化の欠如： 生のSQLをディスクにダンプすると、機密性の高いPII（個人識別情報）やPHI（保護対象保健情報）が露出したままになります。
  3. 複雑な暗号化パイプライン： GPGを使用してバックアップをオンザフライで暗号化しようとすると、深刻なCPUオーバーヘッドとキー管理の複雑さが生じます。
# DIYの暗号化バックアップパイプライン
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

サーバーが侵害された場合、攻撃者は暗号化されたバックアップと /etc/keys/backup.key ファイルの両方にアクセスできるため、暗号化は無意味になります。さらに、GPGキーを生成したDBAが退職し、キーが紛失した場合、バックアップは復旧不可能になります。

危険5：RTOの現実チェック（復旧はバックアップより難しい）

バックアップの究極のテストは復旧です。DIYスクリプトによって生成された論理バックアップは、復旧に時間がかかることで有名です。500GBのSQLダンプを作成するのに15分かかるかもしれませんが、それを復旧するにはデータベースエンジンがSQLを解析し、インデックスを再構築し、制約を再計算する必要があります。これには数時間、あるいは数日かかる可能性があり、RTOを台無しにします。

大規模な本番データベースでは、物理バックアップ（実際のデータファイルのコピー）が必須です。Percona XtraBackupや pg_basebackup のようなツールは存在しますが、それらをDIYのBashスクリプトでラップするのは非常に複雑です。LVMスナップショットを管理し、ファイルシステムの静止を処理し、ネットワークインターフェースを飽和させずにバックアップをオフサイトに転送することを保証しなければなりません。

LVMスナップショットの罠

多くのエンジニアが、LVMスナップショットを使用して「ダウンタイムゼロ」の物理バックアップを試みます：

# スナップショットの作成
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# マウントとコピー
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

データベースで書き込みI/Oが急増すると、20GのLVMスナップショットは即座にいっぱいになる可能性があります。LVMスナップショットがいっぱいになると無効になり、バックアップは失敗します。さらに、過度に使用されているLVMスナップショットは、プライマリデータベースボリュームのI/Oパフォーマンスを著しく低下させ、アプリケーションのレイテンシスパイクを引き起こす可能性があります。

エンタープライズグレードの保護への移行

DIYスクリプトからエンタープライズプラットフォームへの移行は、あらゆるインフラチームにとって重要な成熟の節目です。目標は、「スクリプトが実行されたことを願う」状態から、復旧可能性の暗号学的な証明を持つ状態へ移行することです。

CloudSaveのようなプラットフォームは、DIYスクリプトの死角を排除するために特別に設計されています。アプリケーション対応エージェントをデプロイすることで、CloudSaveはデータベースAPI（MySQL、PostgreSQL、MS SQL、Oracle）と直接対話し、テーブルをロックしたりパフォーマンスを低下させたりすることなく、整合性のある物理および論理バックアップを調整します。

スクリプトから脱却する主な利点：

  1. 自動検証： 最新のプラットフォームはバックアップを取るだけでなく、テストも行います。CloudSaveは一時的なデータベースインスタンスを自動的に立ち上げ、バックアップを復旧し、整合性チェック（例：DBCC CHECKDB）を実行して破棄することで、バックアップが実際に使用可能であるという検証レポートを提供します。
  2. イミュータブル（不変）ストレージ： ランサムウェアに対抗するため、バックアップは不変でなければなりません。DIYスクリプトではWORM（Write Once, Read Many）ストレージへの書き込みは容易ではありません。エンタープライズソリューションはS3オブジェクトロックや不変クラウドストレージとネイティブに統合されており、サーバーが完全に侵害されたとしても、攻撃者がバックアップを削除したり暗号化したりできないようにします。
  3. 簡素化されたPITR： 複雑な recovery.conf や postgresql.auto.conf パラメータを使用してベースバックアップと数百のWALファイルを自分でつなぎ合わせる代わりに、プラットフォームは視覚的なタイムラインを提供します。復旧したい正確な分を選択するだけで、ソフトウェアが自動的にログのリプレイを処理します。
  4. 重複排除と圧縮： DIYスクリプトは各ファイルを個別に圧縮する gzip に依存しています。エンタープライズバックアップソフトウェアはグローバルなブロックレベルの重複排除を利用し、バックアップをオフサイトに転送する際のストレージコストとネットワーク帯域幅を劇的に削減します。

結論

データベースをバックアップするためのカスタムBashスクリプトを書くのは簡単です。しかし、サイレントなパイプライン障害を処理し、ACID整合性を保証し、暗号鍵を安全に管理し、保持期間に基づくデータ損失を防ぎ、厳格なRTO/RPO SLAを保証するスクリプトを書くことは、ほぼ不可能です。

本番環境において、データベースはビジネスの最も重要な資産です。その保護を、数百行のシェルスクリプトで維持されるサイドプロジェクトとして扱うことは、どの企業も負うことのできないリスクです。現在のバックアップ戦略を監査し、論理ダンプの限界を理解し、CloudSaveのような堅牢で自動化されたプラットフォームに移行することで、DevOpsチームやDBAチームはカスタムスクリプトの「バス係数（誰かがいなくなると立ち行かなくなるリスク）」を排除し、データが真に回復力を持つことを保証できます。

カテゴリー