こんにちは！てつです。
前回の連載第3回では、Watchtowerを使って特定のデータベースコンテナをアップデート対象から除外したり、アクセスの少ない深夜の時間帯に更新スケジュールを固定したりする「プロ仕様の制御方法」を解説しました。
手動でのイメージ更新の手間がゼロになり、あなたのサーバー運用は劇的に効率化されたはずです。しかし、自動化が進むと新たな不安が頭をよぎりませんか？
「もし深夜の自動アップデートのタイミングで、アプリの最新イメージにバグがあって動かなくなったらどうしよう……」
今回は、そんな技術者が一番恐れる「自動更新による環境破損」のリスクを完全にゼロにする、Dockerの自動バックアップとの組み合わせ戦略を徹底解説します。「自動化×安全対策」をセットで導入し、何が起きても一瞬で復旧できる本物のインフラ運用スキルを身に付けましょう！
1. Watchtowerの自動アップデートでDockerコンテナが壊れるリスクと対策
アプリの仕様変更やバグでシステムが停止する原因
コマンドを叩かなくても裏側でDockerコンテナが最新の状態に保たれるのは最高に便利です。
しかし、アプリの開発元がリリースした最新バージョンに未知のバグが含まれていたり、設定ファイルの書き換えが必要な「仕様変更」が含まれていたりする場合、Watchtowerがそれを感知せずにアップデートしてしまい、朝起きたらシステムが真っ赤なエラーで落ちているというリスクが潜んでいます。
実務で必須の思想「デザインフォーフェイラー（壊れる前提の設計）」とは
実務の開発現場や商用サービスでは、「システムは必ずどこかで壊れるもの」という前提（デザインフォーフェイラー）でインフラを設計します。
「壊さないように祈る」のではなく、「壊れても一瞬で元の正常な状態に戻せる仕組み」を用意しておくこと。これが、コピペエンジニアと「現場で重宝されるプロエンジニア」を分ける決定的な違いです。
Watchtower稼働直前の自動バックアップで得られる安心感
この記事のハンズオンを終えると、「Watchtowerが動く直前に自動でデータを安全な場所へ退避させ、万が一コンテナが壊れてもコマンド一発で復旧できる仕組み」が完成します。
これでもう、自動更新の失敗に怯える必要はありません。安心して枕を高くして眠れる、最強の自動運用環境を一緒に作り上げましょう！
2. docker-composeによる自動バックアップ環境の前提条件
動作確認済みのOS環境とDockerバージョン
初学者が迷わないよう、推奨環境を明示します。
- OS: Linuxサーバー（Ubuntu推奨）、AWS（EC2）、またはローカルの検証環境（Windows/macOS）
- Docker / Docker Compose: 導入済みであること
連載第3回の「深夜スケジュール稼働環境」をおさらい
今回は、前回の記事で作成した「深夜04:00に稼働するWatchtower」と「自動更新を除外されたMySQLデータベース」が動いている docker-compose.yml をベースに機能を追加していきます。
初心者向け：Dockerボリューム（Volumes）によるデータ永続化の仕組み
ハンズオンに入る前に、とても大切なボリューム（Volumes）の話をします。
Dockerコンテナは、例えるなら「使い捨ての賃貸マンションの一室」です。
コンテナを削除したりアップデートしたりすると、その部屋の中に置いていたデータ（ユーザーの投稿や設定など）はすべて一緒に消えてしまいます。
これでは困るので、コンテナの外（サーバーのハードディスクなど）に「頑丈な外部倉庫」を作り、そこへデータを保存します。この仕組みを「データの永続化（ボリュームマウント）」と呼びます。
今回のバックアップ戦略とは、この「外部倉庫（Dockerボリューム）の中身を丸ごと安全な場所にコピーする」作業を自動化することを指します。
3. AWS S3へのDocker自動バックアップを実装する3ステップ
今回は、開発現場でも人気の高い、Dockerボリュームを自動で圧縮して外部へ転送できる軽量ツール offen/docker-volume-backup を使って解説します。
ステップ1：AWS S3にバックアップ保存用のバケットを作成する
なぜサーバーの内部ではなく、外部にバックアップデータを送る必要があるのでしょうか？
それは、「サーバー自体が物理的に壊れたり、ハッキングされたりした時に、同じサーバー内にバックアップがあっても一緒に消えてしまうから」です（これを二重障害と呼びます）。
今回は、安全な外部ストレージの代表格であるAWS（Amazon Web Services）の「S3」への退避を想定します。
事前にご自身のAWSアカウント等で「バックアップ保存用のバケット（倉庫）」を作成し、接続に必要なアクセスキーとシークレットキーをメモしておいてください。
ステップ2：docker-compose.ymlにバックアップサービスを追記する
それでは、あなたの環境の docker-compose.yml を以下のように書き換え、バックアップ専用のコンテナを仲間に加えましょう。
version: '3.8'
services:
# あなたのメインのWebアプリケーション
web-app:
image: wordpress:latest
ports:
- "8080:80"
volumes:
- wp_data:/var/www/html
# 深夜に自動でアップデートしてくれる見張り番
watchtower:
image: containrrr/watchtower:latest
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- TZ=Asia/Tokyo
- WATCHTOWER_SCHEDULE=0 0 4 * * * # 毎日深夜04:00に自動実行
restart: always
# 【今回追加】万が一の破損に備えてデータを守るバックアップ専用コンテナ
backup-service:
image: offen/docker-volume-backup:v2
volumes:
- wp_data:/backup/wp_data:ro # 守りたい外部倉庫（ボリューム）を「読み取り専用」で繋ぐ
- /var/run/docker.sock:/var/run/docker.sock
environment:
- TZ=Asia/Tokyo
- BACKUP_CRON_EXPRESSION=0 30 3 * * * # Watchtowerが動く30分前（深夜03:30）に実行
- BACKUP_FILENAME=wp-app-backup-%Y-%m-%d-%H%M%S.tar.gz
- AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
- AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
- AWS_S3_BUCKET_NAME=your-my-backup-bucket
restart: always
volumes:
wp_data:【1行解説】バックアップ設定コードの意味を初心者向けに解説
image: offen/docker-volume-backup:v2: ボリュームを自動で固めて送ってくれる定評のあるツールを呼び出しています。- wp_data:/backup/wp_data:ro: バックアップしたい倉庫（wp_data）を、このコンテナの/backup/の中に繋いでいます。末尾の:roは「読み取り専用（Read Only）」という意味で、バックアップ処理中に誤って元のデータが書き換わるのを防ぐプロの知恵です。BACKUP_CRON_EXPRESSION=0 30 3 * * *: 毎日深夜03:30にバックアップを実行する設定です。Watchtower（04:00実行）が動く一歩手前で確実にデータを保護するロジックになっています。AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}: AWSの倉庫に鍵を開けて入るためのIDです。大事な情報なので、後述する隠しファイルから読み込ませます。
ステップ3：テストコマンドでS3へバックアップが保存されるか確認する
設定が書けたら、実際に動かしてみましょう。深夜03:30まで待つ必要はありません。「今すぐ手動でバックアップを実行して動作確認するコマンド」を叩きます。
# 1. コンテナを起動する（-d は裏側でずっと動かす指示）
docker compose up -d
# 2. バックアップコンテナに対して「今すぐバックアップを実行せよ」と命令を送る
docker compose exec backup-service backupコマンドを実行した後、AWS S3の管理画面を開いてみてください。wp-app-backup-2026-06-20-xxxxxx.tar.gz のようなファイルがしっかりと保存されていれば大成功です！
自動化を導入した時は、このように「テスト環境で意図的に一度動かしてエビデンス（証拠）を掴む」のがインフラエンジニアの基本の動き方です。
4. 自宅サーバー運用を劇的に安全にするプロ仕様のセキュリティ対策
ランサムウェアや二重障害を防ぐ「外部ストレージ分散」の重要性
実務の世界では、システムを構築したサーバー内にバックアップファイルを残す手法は「悪手」とされています。
サーバーのハードディスク自体の故障や、サイバー攻撃によるランサムウェア（データを暗号化して人質に取るウイルス）に感染した場合、バックアップごと全滅するからです。
必ず物理的に離れた別のクラウドストレージ（S3等）へデータを分散させること。これがプロと同じ安全基準を満たすための鉄則です。
【厳禁】.envファイル（環境変数）を使いAWSのAPIキー直書きを防ぐ
先ほどのコードで ${AWS_ACCESS_KEY_ID} という書き方をしました。
もし docker-compose.yml に直接、生のアクセスキーを書き込んでしまうと、将来そのファイルをGitHubなどの公開場所に誤ってアップロード（プッシュ）した瞬間、全世界のロボットにキーを盗まれ、数時間で数百万円の身に覚えのない請求がAWSから届くという大惨事になります。
これを防ぐプロの技が、設定ファイルの隣に .env という名前の隠しファイルを作り、そこに秘密の鍵を切り離して管理する手法です（環境変数の利用）。
# .env ファイルの中身
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEdocker-compose.yml はこの .env の中身を自動で読み込んでくれるため、安全性を保ったままプロと同じ環境を構築できます。
5. Docker自動バックアップでよくあるエラーメッセージと解決策
初心者のうちはいろいろなエラーに直面します。エラーが出た時に「うわ、わからない」と諦めるのではないアプローチをしていきましょう。
AWS S3へのアップロード失敗（AccessDenied / 403）の注目点
【ログに表示されるエラーメッセージの例】
upload failed: ./wp-app-backup.tar.gz to s3://your-bucket/ (AccessDenied) with status code 403- どこに注目すべきか？：メッセージの末尾にある
(AccessDenied)とstatus code 403という部分に注目してください。 - 原因と解決策：インフラの世界で「403」や「Access Denied」は「お前が入る権限は無い（アクセス拒否）」という意味です。プログラムのバグではなく、100%「
.envに書いた鍵が間違っている」か「AWS側でバケットへの書き込み権限を許可していない」ことが原因です。鍵を再発行してコピペし直してみましょう。
ファイルサイズが0バイトになる原因：Watchtowerとの時間衝突を回避
【起きる現象】 バックアップのファイルサイズが毎回0バイトになっていたり、データの一部が破損して復旧できなくなったりする。
- どこに注目すべきか？：それぞれのコンテナの起動ログに表示されるタイムスタンプ（実行時間）を確認してください。
- 原因と解決策：データのバックアップの最中に、Watchtowerが「お、コンテナをアップデートする時間だ！」と割り込んできてアプリを強制停止させると、データが中途半端な状態で固められてしまいます。 必ず、バックアップが完全に終わる時間（例：03:30）と、Watchtowerが動き出す時間（04:00）の間に、十分な余裕（30分〜1時間程度）を空けるようにCronの数値を設計し直してください。
6. まとめ：Dockerの自動アップデート×自動バックアップで手間をゼロに
全4回の「WatchtowerによるDocker自動運用シリーズ」の振り返り
全4回にわたってお届けした「WatchtowerによるDocker自動運用シリーズ」は今回で完結です！
- 第1回で自動アップデートのベースを作り、
- 第2回で結果をDiscordやSlackへ可視化し、
- 第3回でスケジュールとDBの除外を制御し、
- 第4回で万が一に備える鉄壁の自動バックアップを実装しました。
これであなたのインフラは、「運用の手間を最小限に抑えつつ、トラブルが起きても一瞬で復旧できる」という、現場のシニアエンジニアが設計したようなプロ仕様の環境へと進化しました！
自信を持って、この環境をベースに自身のポートフォリオやWebサービスを運用していってください。
🚀 副業や発信を加速させる「note記事自動生成ツール」のご案内
インフラの自動化をマスターしたあなたなら、「自分の作業時間を減らして、成果を最大化する」ことの価値が痛いほどわかるはずです。
もしあなたが、日々のインフラ勉強のアウトプットとして「noteの執筆」や「ブログ運営」をしている、あるいはこれから挑戦しようとしているなら、システムの自動化だけでなく「コンテンツ作成の自動化」も取り入れてみませんか？
「生成AIに長文を書かせると、途中で話がループして中身がめちゃくちゃになる」 「もっともらしい嘘（ハルシネーション）を捏造されて、結局修正に何時間もかかる……」
そんな副業ブロガーやエンジニアの悩みを解決するために、私の開発のノウハウを詰め込んだWindows専用のデスクトップアプリ「note記事自動生成システム（Gemini対応）」を開発しました！AIに一度に長文を書かせず、独自の「3段階分割リレー執筆パイプライン」を内部で回すことで、ブレのない高品質な下書きを1クリックで出力します。
🎁 【金土日限定】初期モニター様を50%OFFで募集中！ 現在、私以外のPC環境での動作フィードバック（小さなバグ出し協力）をいただける初期モニター様限定で、通常価格2,980円のところ、今週末（日曜日 23:59まで）に限り半額の1,490円で完全版をご提供しています。 一度手に入れれば、今後の機能追加やアップデートは永久に無料です。月曜日の0:00には通常価格に戻ってしまいますので、時間を味方につけて圧倒的なアウトプットを出したい方は、ぜひこのチャンスに手に入れてみてください！
👉 【1クリック自動化】note記事自動生成システムを半額で手に入れる（BOOTH販売ページへ）
(※月曜日の0:00には自動的に通常価格の2,980円に戻りますのでご注意ください)
筆者のnote👇
コメント