DBAtlas · データベース運用アトラス

自動バックアップ (pgBackRest/Barman/Xtrabackup/cron)

症状

目標: データベースのバックアップを自動化し、スケジュールされたフル + 増分 + WAL/binlog アーカイブ、保持、検証、オフサイトコピーによる信頼性の高い復旧チェーンを構築する。

1. 適切なバックアップツールを選ぶ

エンジンに合ったツールを選ぶ: PostgreSQL には pgBackRest または Barman (物理バックアップ + WAL アーカイブ + PITR)。MySQL/MariaDB には Percona XtraBackup (オンライン物理バックアップ)、小規模なデータセットには mysqldump/mydumper (論理)。物理ツールは大規模データベースで高速かつ一貫性のあるバックアップとポイントインタイムリカバリを提供する。論理ダンプは移植性があるが、大規模データでは遅い。

PostgreSQL

# pgBackRest or Barman

MySQL

# physical: xtrabackup
# logical: mysqldump / mydumper

2. フル + 増分 + 継続的アーカイブのチェーンを構築する

週次/日次のフルバックアップ、その間の増分/差分バックアップ、継続的な WAL (PostgreSQL) または binlog (MySQL) のアーカイブで、ポイントインタイムリカバリを構築する。pgBackRest は full/diff/incremental のバックアップ種別と WAL アーカイブを管理する。PostgreSQL では archive_command で pgBackRest を指定する。増分バックアップ + アーカイブにより任意の時点に戻れる。

PostgreSQL

# postgresql.conf
archive_mode = on
archive_command = 'pgbackrest --stanza=appdb archive-push %p'

# full backup
pgbackrest --stanza=appdb --type=full backup
# incremental
pgbackrest --stanza=appdb --type=incr backup

MySQL

# full
xtrabackup --backup --target-dir=/backup/full
# incremental
xtrabackup --backup --target-dir=/backup/incr1 \
  --incremental-basedir=/backup/full

3. cron/タイマーでバックアップをスケジュールする

cron または systemd タイマーでバックアップコマンドを定期的に実行する: 例えば日曜の夜にフルバックアップ、他の夜は増分。業務時間外にスケジュールし、full と incr のジョブが重ならないようにする。出力ログをどこかに書き込み、失敗時にはアラートを上げる。

PostgreSQL

# crontab
0 1 * * 0 pgbackrest --stanza=appdb --type=full backup
0 1 * * 1-6 pgbackrest --stanza=appdb --type=incr backup

4. 保持ポリシーを定義する

バックアップを際限なく蓄積せず、保持するフルバックアップ数とアーカイブの日数を設定し、古いものはツールに自動で期限切れにさせる。pgBackRest では repo1-retention-full とアーカイブの保持設定で、Barman では retention_policy で管理する。保持期間は復旧目標 (何日前まで戻る必要があるか) に合わせる必要がある。

PostgreSQL

# pgbackrest.conf
[global]
repo1-retention-full=4
repo1-retention-archive=8

MySQL

# purge old backups with cron (example)
find /backup -type d -mtime +14 -exec rm -rf {} +

5. バックアップをオフサイト / S3 にコピーする

バックアップはデータベースと同じマシン/リージョンに置いたままにしてはならない。別の場所またはオブジェクトストレージ (S3、GCS) にコピーする。pgBackRest は S3 互換ストレージに直接書き込める。それ以外の場合は rsync/rclone でオフサイトのターゲットに同期する。災害時 (ローカルディスク/リージョンの喪失) に助けになるのはオフサイトのコピーだけである。

PostgreSQL

# pgbackrest.conf S3 repository
[global]
repo1-type=s3
repo1-s3-bucket=company-backup
repo1-s3-region=eu-central-1
repo1-s3-endpoint=s3.eu-central-1.amazonaws.com

6. バックアップを検証する

バックアップが存在しても、リストアできるとは限らない。整合性を定期的に検証する。pgBackRest では 'verify' コマンドとアーカイブの一貫性チェック、XtraBackup では prepare (--prepare) ステップの成功が、バックアップが健全であることを示す。毎回のバックアップ後に検証を自動実行し、失敗時にはアラームを上げる。

PostgreSQL

pgbackrest --stanza=appdb verify

MySQL

# make the backup consistent (verification)
xtrabackup --prepare --target-dir=/backup/full

7. 定期的なリストア訓練を行う

最も重要なステップ: 定期的にバックアップを別のサーバーへ実際にリストアし、データベースがオープンしデータに一貫性があることを検証する。この訓練により、復旧時間 (RTO) を測定し、インシデント以外の場で手順の不備を見つけられる。テストされていないバックアップはバックアップではない。

PostgreSQL

# restore + PITR on a separate server
pgbackrest --stanza=appdb \
  --type=time --target="2026-07-01 03:00:00" restore

MySQL

# copy the prepared backup back to the data directory
xtrabackup --copy-back --target-dir=/backup/full
DBAtlas で開く →