概要
Cloudflare D1で運用しているデータベースのデータを保護するため、GitHub Actionsを利用した日次バックアップシステムを構築しました。
本記事では、wrangler d1 export コマンドを使用した自動バックアップの実装、専用のSlackチャンネルへの結果通知、およびGitHubのArtifacts(成果物)から直接バックアップファイルをダウンロードするまでの仕組みを解説します。
D1データベースの定期エクスポート設定
GitHub Actionsのスケジュール機能(cron)を利用し、毎日指定した時間にD1データベースのSQLダンプを取得します。
ワークフローの構築
プロジェクトの .github/workflows/d1-backup.yml に以下の設定を追加します。
name: D1 Database Daily Backup
on:
schedule:
# 毎日午前4時00分 (日本時間 JST) に自動実行
- cron: '0 19 * * *'
workflow_dispatch:
jobs:
backup:
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Wrangler
run: npm install -g wrangler
- name: Export D1 Database
env:
CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
run: |
wrangler d1 export <your-database> --remote --output=backup-$(date +'%Y%m%d%H%M').sql
- name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: d1-backup-files
path: backup-*.sql
retention-days: 90
必要なAPIトークンの権限
Wranglerを実行するためには、CloudflareのAPIトークンに適切な権限が必要です。以下の権限を持つカスタムトークンを発行し、GitHubのSecretsに登録します。
- アカウント > D1 > 編集
- ユーザー > ユーザーの詳細 > 読み取り
- ユーザー > メンバーシップ > 読み取り
Slackへの結果通知とダウンロード導線
バックアップの成否を監視するため、rtCamp/action-slack-notify を使用してSlackへ通知を送信します。
特定のチャンネル(例: #backup)に確実に通知を送るため、チャンネル専用のIncoming Webhook URLを発行し、Secrets(SLACK_WEBHOOK_BACKUP_URL)として登録しました。
Artifactsへの直接リンクの生成
GitHubのセキュリティ仕様により、Artifacts内のファイルを直接ダウンロードするURLは発行できません。代わりに、GitHubの環境変数を利用して「該当の実行結果ページ」へのリンクを生成し、Slackメッセージに埋め込みます。
- name: Notify Success
if: success()
uses: rtCamp/action-slack-notify@v2
env:
SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_BACKUP_URL }}
SLACK_COLOR: 'good'
SLACK_TITLE: '✅ バックアップ完了'
SLACK_MESSAGE: "本日のデータを保護しました。\n以下のリンク先、一番下の「Artifacts」から取得可能です。\n\n<[https://github.com/$](https://github.com/$){{ github.repository }}/actions/runs/${{ github.run_id }}|📦 ここからダウンロード>"
SLACK_USERNAME: 'GitHub Actions'
これにより、通知を受け取った担当者が迷うことなくバックアップファイルへアクセスできるようになります。エラー発生時も同様に、エラーログへのリンクを送信するように設定すると効率的です。
GitHubのストレージ容量の管理
GitHub ActionsのArtifactsは、リポジトリのストレージ容量(無料枠の場合500MB)を消費します。容量制限に達すると後続のバックアップが失敗する原因となります。
保存期間の設定
upload-artifact ステップで retention-days: 90 を指定することで、90日経過した古いバックアップファイルは自動的に削除されます。テキストデータであるSQLダンプはファイルサイズが小さいため、通常運用であれば無料枠内で長期間の世代管理が可能です。
容量の確認方法
現在のストレージ使用状況は、GitHubの以下の画面から確認できます。
- Settings (アカウント設定)
- Billing and plans > Plans and usage
- Actions セクション内の Storage (Packages storage と共通)
まとめ
GitHub Actionsを活用することで、サーバーの運用コストをかけることなくCloudflare D1の安全なバックアップ体制を構築できました。Slack通知と組み合わせることで運用状況の可視化も実現しています。
今後は、データ量の増加に伴う保存期間(retention-days)の見直しや、実行頻度(毎日から週次など)の最適化を検討していく予定です。