onedumpを使ってMySQLとPostgreSQLのバックアップを一括管理してみた（複数環境一括管理の検証）
背景・目的
複数環境を一括管理できるツールの有用性を検証するために、ローカルDocker上の MySQL と、Amazon RDS 上の PostgreSQL の両方を対象に、バックアップを自動化してみるという趣旨で試しました。
この方式がうまくいけば、開発・ステージング・本番など複数環境を一元管理する運用がしやすくなる可能性があります。
本記事では次のような流れで紹介します：
- onedump の概要
- 設定ファイル（特に RDS 向け）
- 実行例
- 自動化（GitHub Actions との連携例）とそのユースケース
- エンタープライズ運用上のバックアップ出力先ベストプラクティス
- 感想と今後の展望
onedump の概要（おさらい）
onedump は複数種類のデータベース（MySQL、PostgreSQL、MongoDB、Redis、SQLite など）を、**統一的な設定ファイル（YAML）**でバックアップ / リストアできる CLI ツールです。(github.com)
バックアップ先として、ローカルファイルはもちろん、S3 や SFTP など複数の出力先を組み合わせられるよう設計されています。(tom-doerr.github.io)
この性質により、「複数 DB／複数環境を一元的に管理したい」用途に向く可能性があります。
設定ファイル例（onedump.yml）と注意点
以下は、今回私が試した設定例です（検証目的で簡略化しています）。
databases:
- name: local-mysql
type: mysql
host: localhost
port: 3306
username: root
password: rootpass # 本来は平文では書かない
output: ./backups/mysql_dump.sql
- name: rds-postgres
type: postgres
host: mydb.xxxxxx.ap-northeast-1.rds.amazonaws.com
port: 5432
username: admin
password: pgpass # 本来は平文では書かない
output: ./backups/pg_dump.sql
RDS 向けに押さえておく点
-
hostに RDS のエンドポイント（例：xxxxx.ap-northeast-1.rds.amazonaws.com）を指定 -
portは通常 PostgreSQL の標準ポート（5432） -
usernameとpasswordは管理者権限を持つアカウント -
outputはダンプファイルのパス（ローカルまたは他の出力先）
セキュリティ上の注意
今回は検証用途のためパスワードを YAML に平文で記述しましたが、実運用では推奨されません。
本来は、次のような対策が望ましいです：
- 環境変数参照方式にする
- Vault（HashiCorp Vault など）や AWS Secrets Manager などの秘密情報管理サービスと連携
- IAM ロール／IAM 認証（PostgreSQL で IAM 認証が可能な場合）
- 暗号化された設定ファイルや、ロールベースアクセス制御
などを組み合わせて扱うことが望まれます。
実行例
onedump dump --config ./onedump.yml
実行ログ例（簡略化）：
[INFO] Dumping database: local-mysql (mysql)
[INFO] Output: ./backups/mysql_dump.sql
[INFO] Dumping database: rds-postgres (postgres)
[INFO] Output: ./backups/pg_dump.sql
[INFO] Done!
この通り、両方の DB に対して順次ダンプが実行され、指定したローカルディレクトリにファイルが出力されました。
自動化との連携：GitHub Actions を活用するユースケースと利点
GitHub Actions 連携例
name: Scheduled DB Backup
on:
schedule:
- cron: "0 3 * * *" # 毎日 3:00 に実行
jobs:
backup:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install onedump
run: |
# 例として Linux 向けインストール方法
curl -fsSL https://github.com/liweiyi88/onedump/releases/latest/download/onedump_linux_amd64.tar.gz | tar zx
mv onedump /usr/local/bin/
- name: Run backup
run: onedump dump --config ./onedump.yml
- name: Upload artifacts
uses: actions/upload-artifact@v3
with:
name: db-backups
path: ./backups/*.sql
この連携で得られるメリット・ユースケース
-
IaC リポジトリとバックアップ定義を一元管理できる
→ バックアップ設定ファイルやスクリプトとコードを同じリポジトリで管理可能 -
レビュー / 変更履歴の一元化
→ 誰がいつバックアップ設定を変えたか Git の履歴で追える -
随時オンデマンドバックアップも可能
→ GitHub Actions のワークフローを手動実行すれば即時バックアップできる -
環境分岐の自動化
→ ブランチ（たとえばprod、staging）ごとに異なるonedump.ymlを用意して、バックアップ対象を分ける -
クラウド CI 経由でエージェントレス運用
→ 自身でサーバを立てることなく、GitHub 上で定期実行できる
これにより、コードと運用設定を統合しやすく、複数環境向けのバックアップ運用が比較的シンプルになります。
本番・エンタープライズ運用でのバックアップファイル出力先のベストプラクティス
単にローカルにファイル出力するだけでは、災害対応・可用性・セキュリティの観点で十分とは言えません。以下は業界で一般的に推奨されるベストプラクティスです。
出力先選定の指針
- オブジェクトストレージ（Amazon S3、Google Cloud Storage、Azure Blob Storage など）：高耐久性・冗長性のある保存先
- 専用バックアップリポジトリ（バックアップ専用ストレージ装置／ソフトウェア型ストレージプール）(storware.eu)
- テープアーカイブ（コールドストレージ）やオフライン媒体（特に長期保存）
- 地理的に分散した複数拠点への保存
- 暗号化・アクセス制御・改ざん防止（WORM モード、Immutable オブジェクトストレージなど）
一般的なバックアップ戦略の原則（参考までに）
-
3-2-1 ルール：
→ 本データ 1 コピー + バックアップ 2 コピー + 異なるメディア／オフサイト保存 1 箇所以上 を保持する設計が推奨されます。(acronis.com) - 複数拠点保存：災害や障害が起きた際もバックアップが失われないようにする
- 定期的なリストアテスト：バックアップが正しく復元できるか定期確認
- 暗号化とアクセス制御：保存時暗号化、アクセスログ、削除権限制限
- インクリメンタル／差分バックアップとフルバックアップの組み合わせ：頻度と容量を考慮して効率化
- ライフサイクル管理：古いバックアップ自動削除やアーカイブ移行
onedump における出力先設計（応用案）
onedump の構成次第では、出力先をオブジェクトストレージや SFTP、クラウドストレージといった先に向けられるよう設定できることが想定されます。(tom-doerr.github.io)
たとえば output をローカルパスではなく、S3 バケットへのアップロード処理をバックアップ後にフックして実行する、という構成も現実的です。
例えば：
- 一時的にローカルにダンプ
- ダンプファイルを S3 にアップロード（CLI や SDK 経由）
- ローカルファイルをクリーンアップ
このようにすると、オンプレや CI 環境でもオブジェクトストレージを最終保存先として利用できます。
感想・今後の展望
感想（今回検証してみて）
- 複数 DB／複数環境を統一設定で扱える点は確かに魅力
- ログやエラーハンドリングの表現をもう少し詳細に出してほしいと感じた
- 認証情報の取り扱い周りは改善余地あり
- 大規模データセットや高速更新中の DB を扱う際の性能・タイミングの検証が必要
今後試してみたいこと／改善案
- Secrets Manager / Vault 連携 による認証情報管理
- バックアップ後の S3 / GCS アップロード自動化
- 増分／差分バックアップを部分対応できる仕組み（もし onedump が対応していれば）
- 復元 (restore) の操作性確認と障害シナリオでの復旧検証
- 大容量データ／高負荷 DB での動作挙動検証
- Slack 通知・モニタリング連携