Docker内のPostgreSQLデータベースを自動バックアップする方法

## 方案一：ホストマシンスクリプト + Crontab 定時タスク

これは最も古典的で直接的な方法です。ホストマシン（Host）でシェルスクリプトを記述し、`docker exec` を使用してコンテナ内の `pg_dump` ツールを呼び出します。

### 実装ステップ：

1. **スクリプトの作成**：`.sh` ファイルを作成し、内容は通常次の通りです：

   ```Bash
   docker exec -t <container_name> pg_dumpall -c -U <username> > /path/to/backups/db_$(date +%Y%m%d).sql
   ```

2. **権限の設定**：スクリプトに実行権限を付与します。

3. **Cronの設定**：`crontab -e` を使用して定時タスク（例：毎日午前2時に実行）を追加します。

4. **クリーンアップメカニズム**：スクリプト内に `find` コマンドを追加して、X 日前の古いバックアップを自動的に削除します。

### 長所と短所のまとめ：

- **長所**：コンテナイメージを変更する必要がない、設定が柔軟で、追加のコンテナリソースを占有しません。
- **短所**：ホストマシンの環境設定に依存し、新しいサーバーに移行した場合、Cronとスクリプトパスを再構成する必要があります。

## 方案二：サイドカー・コンテナ（Sidecar Container）

Docker Composeでバックアップ専用のサービスを追加します。現在、コミュニティには多くの成熟したイメージがあります（例：`prodrigestivill/postgres-backup-local`）。

### 実装ステップ：

1. **Composeファイルの修正**：`docker-compose.yml` 内にバックアップサービスを追加します：

   
   ```YAML
   services:
     db:
       image: postgres:15
     backup:
       image: prodrigestivill/postgres-backup-local
       volumes:
         - ./backups:/backups
       links:
         - db
       environment:
         - POSTGRES_HOST=db
         - POSTGRES_USER=user
         - POSTGRES_PASSWORD=pass
         - SCHEDULE=@daily # 内蔵のCron式を使用
         - BACKUP_KEEP_DAYS=7
   ```

2. **サービス起動**：`docker-compose up -d` 後、バックアップサービスは設定された `SCHEDULE` に従って自動的に実行されます。

### 長所と短所のまとめ：

- **長所**：高度に統合されており、プロジェクトコードとともに管理できます。移行が容易で、どこでもComposeを実行してバックアップできます。
- **短所**：コンテナのオーバーヘッドが増加し、バックアップファイルはデフォルトでボリュームに保存されるため、オフサイトバックアップを考慮する必要があります。

## 方案三：クラウド/オブジェクトストレージバックアップ（例：S3/OSS）

データが非常に重要な場合は、直接バックアップをクラウドストレージ（例：AWS S3またはアリババクラウドOSS）にストリーミング伝送することをお勧めします。物理サーバーの障害を防ぐためです。

### 実装ステップ：

1. **イメージの選択**：S3プロトコルをサポートするイメージ（例：`schickling/postgres-backup-s3`）を使用します。
2. **環境変数の設定**：コンテナ内で `S3_ACCESS_KEY_ID`、`S3_SECRET_ACCESS_KEY`、`S3_BUCKET` を設定します。
3. **バックアップの実行**：コンテナは自動的に「エクスポート -> 圧縮 -> アップロード」の全プロセスを完了します。

### 長所と短所のまとめ：

- **長所**：**オフサイトバックアップ**、セキュリティが非常に高い；ローカルディスクスペースを占有しません。
- **短所**：パブリックネットワーク帯域幅が必要であり、少量のクラウドストレージ料金が発生します。

## 方案の総合比較

| **特性**     | **方案一：ホストマシンスクリプト** | **方案二：サイドカー・コンテナ** | **方案三：クラウドストレージバックアップ** |
| ------------ | ---------------------- | ------------------------ | ---------------------- |
| **デプロイの難易度** | 中等 (Cronの設定が必要)     | **簡単 (YAMLの設定)**     | やや複雑 (クラウド認証が必要)    |
| **移植性**   | 悪                     | **極めて良い**                 | 良い                     |
| **セキュリティ**   | ローカルディスクに依存           | ローカルディスクに依存             | **極めて高い (オフサイト冗長)**    |
| **適用シナリオ** | 単一マシンの小規模プロジェクト           | 複雑なアプリケーション、ミクロサービス         | 本番環境、コアビジネス     |


## 推奨事項

- **バックアップのみでなくテストも行う**：定期的にバックアップファイルからデータを復元して、バックアップが「生きている」ことを確認します。
- **機密情報の取り扱い**：スクリプトまたはComposeファイル内にパスワードを平文で書き込まないでください。Docker Secretsまたは `.pgpass` ファイルを使用することをお勧めします。
- **モニタリングとアラート**：どの方案を採用する場合でも、バックアップ失敗の通知（例：企業WeChat/钉钉 Hook）を設定することをお勧めします。バックアップが静かに失敗しないようにします。