OpenClawのバックアップ戦略｜日次・週次・災害復旧対策の完全ガイド

Q: バックアップの保持期間はどうすべきですか？

日次バックアップは7日分、週次は1ヶ月分、月次は1年分が一般的な目安です。医療・金融・個人情報を扱う業界では法規制による保存義務期間があるため、必ず確認してください。

Q: バックアップが失敗した場合のアラートは？

バックアップスクリプトの終了コードをチェックし、0以外の場合にSlackやメールで通知する仕組みを構築してください。死活監視とセットで運用することが重要です。

Q: Docker環境のバックアップはどうすべきですか？

docker volumeのデータはホスト側のマウントポイントを直接バックアップします。docker-compose.ymlと.envファイルはGitバージョン管理で保護してください（.envは.gitignoreで除外し別途暗号化バックアップ）。

公開日：2026年3月 / 更新日：2026年3月

「バックアップを取っているつもり」が最も危険な状態です。OpenClawを法人で運用する場合、データベース・アップロードファイル・設定ファイルの3種類を適切な頻度でバックアップし、定期的にリストアテストを実施しなければなりません。本記事では日次・週次・月次のバックアップ設計から、mysqldump自動化、rsync、遠隔地保管、災害復旧計画まで実践手順を解説します。

OpenClawバックアップなぜ「取っているつもり」が最も危険なのか

バックアップに関して最も多い失敗は、「取っていない」ではなく「取っているつもり」のまま運用していることです。実際に障害が発生して初めて、バックアップが機能していなかったことに気づくケースが後を絶ちません。

バックアップの3大失敗パターン

取っていない：最もシンプルな失敗。「誰かがやっているはず」という思い込みで、誰もバックアップを設定していなかった。
古いバックアップしかない：手動バックアップを「たまに」実施していた結果、最新のバックアップが数ヶ月前のものしかない。データ損失は最小限でも、その間の更新内容がすべて失われる。
リストアできない：バックアップファイルは存在するが、リストア手順を誰も知らない。ファイルが破損していても気づかない。ディスクの種類が変わって手順が通用しなくなっていた。

重要

バックアップはリストアできて初めて意味があります。「バックアップを取っている」ではなく「バックアップからリストアできることを確認している」が正しい運用です。定期的なリストアテストを実施していない限り、バックアップは存在しないも同然です。

リストアテストを怠るリスク

バックアップファイルが破損していることは珍しくありません。圧縮コマンドのオプションミス、ディスク障害中のバックアップ取得、権限不足によるファイル欠損など、様々な理由でリストアに失敗します。障害発生時に初めてリストアを試みて失敗するという最悪のシナリオを避けるため、定期的（最低でも四半期に1回）のリストアテストを必ず実施してください。

対策の基本姿勢

バックアップ設計は「障害が起きたときに何を失うか」ではなく、「障害が起きても何を守れるか」という視点で考えてください。RPO（目標復旧時点）とRTO（目標復旧時間）を事前に決め、それを満たすバックアップ頻度と手順を整備することが重要です。

OpenClawバックアップ 3種類のバックアップとそれぞれの役割

OpenClawのバックアップ戦略は、取得タイミングと対象データによって3種類に分類されます。それぞれの役割を理解した上で、適切な組み合わせで運用することが重要です。

種類	頻度	対象	特徴	推奨ツール
フルバックアップ	週次（日曜深夜）	DB全体 + 全ファイル	完全なスナップショット。リストアが最もシンプル。容量大。	mysqldump + tar
差分バックアップ	日次（深夜2時）	前回フル以降の変更分	フルバックアップとの差分のみ。容量小。リストア時はフル+差分が必要。	rsync --checksum
トランザクションログ	リアルタイム（15分ごと）	DBの更新履歴	任意の時点への復元が可能（PITR）。MySQL binlogを使用。	MySQL Binary Log

OpenClawに推奨するバックアップ構成

小中規模のOpenClaw運用であれば、以下の構成が費用対効果に優れています。

日次：mysqldumpによるDBフルバックアップ（圧縮して7日分保持）
週次：アップロードファイル一式のフルバックアップ（4週分保持）
月次：上記を遠隔地（S3/GCS）へ転送（12ヶ月分保持）

ポイント

トランザクションログ（binlog）は高可用性が求められる場合に追加します。通常の法人運用では日次DBバックアップ＋週次ファイルバックアップで十分なケースがほとんどです。まずシンプルな構成で確実に動かすことを優先してください。

OpenClawバックアップ MySQLデータベースの自動バックアップ設定

OpenClawのデータはMySQLに格納されています。最も重要なバックアップ対象であり、mysqldumpを使った日次自動バックアップを最初に整備してください。

mysqldumpの基本コマンド

--single-transactionオプションを必ず付けてください。これにより、ダンプ中もDBへの書き込みを継続できます（InnoDB前提）。このオプションなしでのバックアップは、ロックが発生してOpenClawの動作に影響を与えます。

# 基本的なmysqldumpコマンド
mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  -u openclaw_user \
  -p'パスワード' \
  openclaw_db \
  | gzip > /backup/db/openclaw_$(date +%Y%m%d).sql.gz

cronによる日次自動化

バックアップスクリプトを作成し、cronで自動実行します。スクリプト化することで、世代管理（古いバックアップの自動削除）や失敗時の通知も一緒に実装できます。

#!/bin/bash
# /usr/local/bin/openclaw-db-backup.sh

BACKUP_DIR="/backup/db"
DB_NAME="openclaw_db"
DB_USER="openclaw_user"
DB_PASS="パスワード"
KEEP_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)
FILENAME="${BACKUP_DIR}/openclaw_${DATE}.sql.gz"

# バックアップ実行
mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  -u "$DB_USER" \
  -p"$DB_PASS" \
  "$DB_NAME" \
  | gzip > "$FILENAME"

# 終了コードチェック（パイプラインの失敗を検出）
if [ ${PIPESTATUS[0]} -ne 0 ]; then
    echo "BACKUP FAILED: $(date)" | mail -s "[ALERT] OpenClaw DB backup failed" admin@example.com
    exit 1
fi

# 7日以上前のバックアップを削除
find "$BACKUP_DIR" -name "openclaw_*.sql.gz" -mtime +$KEEP_DAYS -delete

echo "Backup completed: $FILENAME"

# crontabに追加（毎日深夜2時に実行）
0 2 * * * /usr/local/bin/openclaw-db-backup.sh >> /var/log/openclaw-backup.log 2>&1

世代管理の考え方

日次バックアップ：7日分保持（ローカルストレージ）
週次スナップショット：日次バックアップのうち毎週日曜分を別ディレクトリにコピーして4週分保持
月次アーカイブ：毎月1日のバックアップを遠隔地に転送して12ヶ月分保持

注意

パスワードをスクリプトにハードコードすることはセキュリティ上のリスクです。本番環境では/etc/mysql/conf.d/backup.cnfにMySQL認証情報を記述し、chmod 600で保護してください。スクリプトからは--defaults-extra-fileオプションで読み込みます。

OpenClawバックアップアップロードファイルと設定ファイルの保護

DBバックアップと同様に重要なのが、ユーザーがアップロードしたファイルと設定ファイルのバックアップです。特に.envファイルやAPIキーを含む設定ファイルは、紛失すると再設定に多大な時間がかかります。

rsyncによるファイルバックアップ

rsyncは差分転送に対応しており、初回以降は変更分のみを転送するため高速です。週次フルバックアップと組み合わせて使用します。

#!/bin/bash
# /usr/local/bin/openclaw-file-backup.sh

SRC="/var/www/openclaw/uploads/"
DEST="/backup/files/uploads/"
LOG="/var/log/openclaw-file-backup.log"

# 除外パターン: 一時ファイル・キャッシュを除外
rsync -av \
  --delete \
  --exclude="*.tmp" \
  --exclude="cache/" \
  --exclude="*.log" \
  "$SRC" "$DEST" >> "$LOG" 2>&1

if [ $? -ne 0 ]; then
    echo "FILE BACKUP FAILED: $(date)" | mail -s "[ALERT] OpenClaw file backup failed" admin@example.com
fi

設定ファイルの暗号化保管

.envファイルやNginx設定など、機密情報を含む設定ファイルは暗号化してからバックアップします。平文のままクラウドストレージに保存することは避けてください。

# GPGで暗号化してバックアップ
tar czf - /var/www/openclaw/.env /etc/nginx/sites-available/openclaw \
  | gpg --symmetric --cipher-algo AES256 \
  --passphrase-file /root/.backup-passphrase \
  > /backup/config/openclaw-config-$(date +%Y%m%d).tar.gz.gpg

# 復号化コマンド（リストア時）
gpg --passphrase-file /root/.backup-passphrase \
  --decrypt openclaw-config-20260301.tar.gz.gpg \
  | tar xzf -

除外すべきパターン

vendor/：Composerで再生成可能なため除外
node_modules/：npm installで再生成可能なため除外
cache/：再生成可能なキャッシュファイル
*.log：ログファイル（必要なら別途アーカイブ）
*.tmp：一時ファイル

ポイント

設定ファイルは変更のたびにバックアップする習慣をつけてください。特に.envファイルはGitリポジトリに含めないため、変更履歴が残りません。変更前後にコピーを取る運用が安全です。

OpenClawバックアップ災害復旧（DR）計画の立て方

バックアップはローカルに置くだけでは不十分です。サーバー本体が物理的に損傷・盗難・火災にあった場合、同じサーバー上のバックアップも失われます。遠隔地へのバックアップ転送と復旧手順の文書化がDR計画の核心です。

RTO/RPOの設定

DR計画を立てる前に、以下の2つの指標を決定してください。これにより、必要なバックアップ頻度とシステム構成が決まります。

指標	意味	OpenClaw法人運用の目安
RTO （目標復旧時間）	障害発生から復旧完了までの許容時間	社内利用：24時間以内顧客向け：4時間以内
RPO （目標復旧時点）	復旧時に失ってよいデータの最大期間	社内利用：24時間前顧客向け：1時間前

遠隔地バックアップ（S3/GCS）

AWS S3またはGoogle Cloud Storageを遠隔地バックアップの保管先として使用します。AWS CLIを使えばcronで自動転送が可能です。

# AWS S3へのバックアップ転送
aws s3 cp /backup/db/openclaw_$(date +%Y%m%d)*.sql.gz \
  s3://your-backup-bucket/openclaw/db/ \
  --storage-class STANDARD_IA

# 古いS3オブジェクトの自動削除（S3 Lifecycle Policyで設定推奨）
# 30日以上前のオブジェクトをGlacierへ移行
# 1年以上前のオブジェクトを削除

コールドスタンバイ vs ホットスタンバイ

方式	概要	復旧時間	費用	推奨ケース
コールドスタンバイ	バックアップを保持するだけ。障害時に新規サーバーへリストア。	数時間〜1日	低（S3ストレージ代のみ）	社内利用・RTO 24時間以内
ウォームスタンバイ	縮小構成でスタンバイサーバーを常時起動。障害時にスケールアップ。	1〜2時間	中（スタンバイサーバー費用）	RTO 4時間以内が必要
ホットスタンバイ	同一構成のサーバーをリアルタイム同期。フェイルオーバー自動化。	数分以内	高（本番×2の費用）	顧客向け・高可用性必須

ほとんどの法人OpenClaw運用ではコールドスタンバイで十分です。S3への自動転送を設定し、リストア手順を文書化しておけば、24時間以内の復旧は現実的に達成できます。

セキュリティ連携

バックアップの設計と並行して、アクセス権限やAPIキーの管理も見直してください。バックアップデータには機密情報が含まれるため、暗号化と転送時のSSL/TLSは必須です。詳細はOpenClawのセキュリティ設計ガイドを参照してください。

まとめ

OpenClawのバックアップ戦略で最も重要なのは、3-2-1ルールの実践です。

3コピー：データのコピーを合計3つ保持する（本番 + ローカルバックアップ + 遠隔地バックアップ）
2種類の媒体：異なる種類のストレージに保存する（例：ローカルHDDとクラウドストレージ）
1つは遠隔地：必ず1つは地理的に離れた場所に保管する（S3東京リージョン等）

これに加えて、定期的なリストアテスト（最低四半期に1回）を実施し、リストア手順を文書化しておくことが、真に機能するバックアップ体制の条件です。

運用中の障害対応についてはOpenClaw保守運用ガイドも合わせてご覧ください。コスト面での最適化についてはコスト完全分解で詳しく解説しています。

よくある質問

バックアップの頻度はどのくらいが適切ですか？

データベースは日次、ファイルは週次、設定ファイルは変更時にが基本です。トラフィックが多い本番環境やデータ更新頻度が高い場合は、DBバックアップを6時間ごとに変更することを検討してください。まずは日次から始めて、業務の重要度に合わせて頻度を上げていくアプローチが現実的です。

バックアップの保持期間はどうすべきですか？

日次バックアップは7日分、週次は1ヶ月分、月次は1年分が一般的な目安です。医療・金融・個人情報を扱う業界では法規制（医療法・金融商品取引法・個人情報保護法等）による保存義務期間があるため、必ず確認してください。コンプライアンス要件がある場合は、その期間に合わせて保持期間を設定します。

リストアテストはどのくらいの頻度で行うべきですか？

最低でも四半期に1回、理想的には月1回の実施を推奨します。テスト環境にリストアして正常動作を確認する手順を文書化しておいてください。テスト結果（成功/失敗・リストア所要時間・確認項目）を記録しておくと、次回の計画立案や監査対応に役立ちます。初回のリストアテストは必ずバックアップ設定直後に実施してください。

クラウドストレージへのバックアップは安全ですか？

暗号化（AES-256）して転送すれば安全です。AWS S3やGoogle Cloud Storageはサーバーサイド暗号化（SSE-S3、SSE-KMS）にも対応しており、保管時の暗号化も可能です。転送時のSSL/TLS（HTTPS/TLS 1.2以上）も必ず確認してください。機密情報を含むバックアップは、クライアントサイドで暗号化してからアップロードすることを推奨します。

バックアップが失敗した場合のアラートは？

バックアップスクリプトの終了コード（exit code）をチェックし、0以外の場合にSlackやメールで通知する仕組みを構築してください。死活監視（cronが実行されているか）とセットで運用することが重要です。「バックアップが成功したことを確認する」ポジティブ通知と、「失敗を検知する」ネガティブ通知の両方を実装すると信頼性が高まります。

Docker環境のバックアップはどうすべきですか？

docker volumeのデータはホスト側のマウントポイント（通常/var/lib/docker/volumes/）を直接バックアップするか、コンテナを一時停止してdumを取得します。docker-compose.ymlと.envファイルはGitバージョン管理（.envは.gitignoreで除外し別途暗号化バックアップ）で保護してください。コンテナイメージはDocker Hubやプライベートレジストリにプッシュしておけば再構築が容易です。

バックアップにかかるストレージ費用は？

圧縮済みで月数GB程度が一般的なOpenClaw運用における目安です。AWS S3 Standard（東京リージョン）で$0.025/GB/月のため、100GB保管しても月$2.5程度（約350円）です。より安価なS3 Standard-IA（低頻度アクセス）を使えば$0.0138/GB/月まで下がります。ローカルバックアップはVPSのディスク容量を使うため、バックアップ専用の小容量VPS（月500〜1,000円）を別途用意するコストも考慮してください。

OpenClawの導入を検討していますか？

設計・構築・保守まで、構築代行会社を比較して最適なパートナーを見つけましょう。

構築代行会社を比較する →