Core Media Lab記事一覧
開発・インフラ

【VPS運用】Dify・n8nのDocker環境を自動バックアップ&安全にアップデートする完全手順!データ消失を防ぐ保守術

【VPS運用】Dify・n8nのDocker環境を自動バックアップ&安全にアップデートする完全手順!データ消失を防ぐ保守術

VPS(仮想専用サーバー)上のDocker環境に「Dify」や「n8n」をセルフホストして24時間稼働の自動化パイプラインが回り始めると、次に必ず直面するのが「新しいバージョンにアップデートしたいけれど、せっかく作ったワークフローやナレッジのデータが消えたらどうしよう」「万が一操作を誤ったときに元に戻せるバックアップの仕組みがない」という運用・保守の課題です。

オープンソースのAI・自動化ツールは開発スピードが非常に速く、新機能の追加やセキュリティ修正のアップデートが頻繁に行われます。しかし、事前のバックアップなしにいきなりコマンドを叩いて更新すると、設定ファイルの競合やデータベースの不整合によってコンテナが起動しなくなるトラブルが少なくありません。

本記事では、VPS上のDockerで動かしているDify・n8nのデータを確実に保護するバックアップ手順から、cron を使った毎日の自動退避スクリプト、そしてデータを壊さずに最新版へアップデートする安全な手順までを体系的に解説します。

なぜDify・n8nのセルフホスト運用で「バックアップと更新手順」が重要なのか?

クラウド版(SaaS版)のツールであれば、サーバーの保守やバージョンアップはすべて運営会社側が裏側で行ってくれます。しかし、コストパフォーマンスと自由度に優れた「VPSでのセルフホスト運用」では、自分自身がインフラ管理者となるため、データの保存構造を正しく理解しておく必要があります。

💡 まだDify・n8nの初期構築や連携が終わっていない方へ
VPSへのDocker導入から各ツールの立ち上げ・API連携手順については、以下の記事で詳しく解説しています。
・【脱・無料枠制限】Difyを格安VPSにセルフホスト構築する完全手順!
・【脱Zapier】n8nを格安VPSにDocker構築する完全手順!
・【Dify×n8n連携】AIワークフローを24時間完全自動化する構築手順!

Dockerコンテナを更新・再作成してもデータが消えない仕組み(永続化データの実体)

Dockerの基本原則として、「コンテナそのものは使い捨て」であり、バージョンアップ時には古いコンテナを削除して新しいイメージからコンテナを再作成します。それにもかかわらず作成したワークフローやログイン情報、登録したドキュメントが消えないのは、データがコンテナの外側(VPSホスト側)にある「バインドマウント(特定ディレクトリ)」または「Dockerボリューム(Volume)」に永続化されているためです。

Difyとn8nの標準的なDocker Compose構成では、それぞれ以下の場所に重要データが保存されています。

対象ツール データ永続化の方式(標準構成) 絶対に守るべき重要データ・設定ファイル
Dify バインドマウント方式
(dify/docker/volumes/ 配下)
・PostgreSQLデータベース(volumes/db)
・ベクトルDB / Redis / ストレージ(volumes/ 一式)
・環境変数ファイル(dify/docker/.env)
n8n Dockerボリューム方式(n8n_data 等)
またはバインドマウント
・SQLiteデータベース(database.sqlite)
・暗号化キーを含む設定(config ファイル)
・docker-compose.yml および .env

つまり、バックアップとは「これら永続化されたデータ領域と、環境変数ファイル(.env)をセットで別領域に丸ごとコピー・圧縮しておくこと」にほかなりません。

無計画なアップデートや設定上書きで起きる3大トラブル

バックアップを取らずにアップデート作業を行ったり、構造を理解せずにファイルを操作したりすると、以下のような深刻なトラブルが発生しがちです。

  1. Difyの git pull 時に .env の必須項目が増減して起動エラーになる:
    Difyはバージョンアップに伴って .env.example に新しい環境変数が追加されることがあります。古い .env のままコンテナを起動すると、必要な変数が不足してバックエンド(api / worker)がクラッシュする場合があります。
  2. n8nの「暗号化キー(Encryption Key)」を紛失して認証情報が復号できなくなる:
    n8nに登録したAPIキー(Credential)は、.n8n/config ファイル内の暗号化キー(または環境変数 N8N_ENCRYPTION_KEY)で暗号化されています。データベースだけを残してこのキーを失うと、すべてのノードの認証情報が読み込めなくなります。
  3. 古いDockerイメージが蓄積してVPSのディスク容量(SSD)が100%に張り付く:
    アップデートを繰り返すと、使われなくなった数GB単位の旧イメージがVPS内に残り続けます。空き容量が枯渇するとデータベースへの書き込みが失敗し、最悪の場合データが破損します。

【実践】Dify・n8nのデータを丸ごと保護する手動バックアップ手順

自動化のスケジュールを組む前に、まずはアップデート作業の直前などにいつでも手動で実行できる「確実なフルバックアップ手順」を押さえておきましょう。

Dify(docker/volumes ディレクトリと .env)のフルバックアップコマンド

Difyのデータは、クローンしたリポジトリ内の dify/docker/volumes ディレクトリと dify/docker/.env ファイルに集約されています。データベース(PostgreSQL)の書き込み中にファイルをコピーするとデータの整合性が崩れる恐れがあるため、一度コンテナを停止してから tar コマンドで1つの圧縮ファイルにまとめるのが最も安全です。

VPSにSSH接続し、以下の手順でバックアップを実行します(※Difyを ~/dify に配置している場合の例です)。

# 1. バックアップ保存用ディレクトリを作成
mkdir -p ~/backups/dify

# 2. DifyのDockerディレクトリへ移動してコンテナを一時停止
cd ~/dify/docker
docker compose stop

# 3. 日付付きのファイル名で volumes ディレクトリと .env をまとめて圧縮保存
sudo tar -czpf ~/backups/dify/dify_backup_$(date +%Y%m%d_%H%M%S).tar.gz volumes .env

# 4. コンテナを再起動
docker compose start

tar コマンドに -p(パーミッション保持)と sudo を付けているのは、volumes/db などのファイル所有権がコンテナ内の特定ユーザー(rootやpostgres等)になっており、一般ユーザー権限だけでは読み取りエラーや復元時の権限ズレが起きるのを防ぐためです。

n8nのデータ退避(Dockerボリュームのアーカイブ化とCLIエクスポート)

n8nについては、インフラ全体を戻すための「ボリューム丸ごとバックアップ」と、ワークフロー単位で手軽に扱える「CLIエクスポート」の2通りがあります。

▼ 方法1:n8nの永続化データと設定ファイルを丸ごと圧縮する(推奨)

もし ~/n8n ディレクトリ内の ./n8n_data をバインドマウントしている場合は、Difyと同様に以下のコマンドで退避できます。

# 1. バックアップ保存用ディレクトリを作成
mkdir -p ~/backups/n8n

# 2. n8nディレクトリへ移動して一時停止・圧縮・再開
cd ~/n8n
docker compose stop
sudo tar -czpf ~/backups/n8n/n8n_backup_$(date +%Y%m%d_%H%M%S).tar.gz .
docker compose start

一方、docker-compose.yml でDockerの名前付きボリューム(例:n8n_data:/home/node/.n8n)を使用している場合は、一時的な軽量コンテナ(busybox等)を介してボリュームの中身を tar.gz に書き出すことができます。

# Docker名前付きボリューム(例:n8n_n8n_data)をアーカイブ化するコマンド
docker run --rm \
  -v n8n_n8n_data:/volume_data:ro \
  -v ~/backups/n8n:/backup \
  busybox tar -czpf /backup/n8n_volume_$(date +%Y%m%d_%H%M%S).tar.gz -C /volume_data .

※ボリュームの正確な名前は docker volume ls コマンドで確認できます。

▼ 方法2:稼働中のn8nコンテナからワークフローをJSON形式でエクスポートする

コンテナを止めずにワークフローの定義データだけをサクッと抜き出したい場合は、n8n公式のCLIコマンドを docker compose exec 経由で実行する方法も便利です。

# コンテナ内の全ワークフローを1つのファイルにエクスポートする例
docker compose exec n8n n8n export:workflow --all --output=/home/node/.n8n/workflows_backup.json

手動でのバックアップ方法が確認できたら、次はこれらを「毎日深夜に自動で実行し、古いバックアップを自動で整理する仕組み」へと発展させましょう。

cronで毎日自動実行!シェルスクリプトによる世代管理バックアップの構築

手動でのバックアップ手順が確認できたら、次はLinux標準のスケジューラである cron(クーロン)を使って、毎日深夜に自動でバックアップを取得する仕組みを構築します。

ここで重要なのが「世代管理(古いバックアップファイルの自動削除)」です。毎日フルバックアップを取り続けると、数週間でVPSのディスク容量が圧迫されてしまいます。そのため、「直近7日分のファイルだけを残し、8日以上前のファイルは自動で削除する」という処理をシェルスクリプト内に組み込みます。

古いバックアップを自動削除(7日分保持)するシェルスクリプトの作成

まずはバックアップ処理をまとめたシェルスクリプト(auto_backup.sh)を作成します。以下の例では、Difyのデータ一式を退避し、7日より古いアーカイブを find コマンドで自動削除する構成にしています(※n8nも同居している場合は、同じスクリプト内に追記できます)。

# 1. スクリプト保存用のディレクトリを作成してファイルを開く
mkdir -p ~/scripts
nano ~/scripts/auto_backup.sh

エディタが開いたら、以下の内容を貼り付けて保存(Ctrl + O ➔ Enter ➔ Ctrl + X)します。

#!/bin/bash
set -e

# 設定変数(ご自身の環境に合わせてパスを変更してください)
BACKUP_DIR="/root/backups/dify"
DIFY_DOCKER_DIR="/root/dify/docker"
RETENTION_DAYS=7
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# 1. バックアップ先ディレクトリの作成
mkdir -p "${BACKUP_DIR}"

# 2. Difyコンテナの一時停止とバックアップ圧縮
cd "${DIFY_DOCKER_DIR}"
docker compose stop
tar -czpf "${BACKUP_DIR}/dify_backup_${TIMESTAMP}.tar.gz" volumes .env

# 3. Difyコンテナの再開
docker compose start

# 4. 指定日数(7日)より古いバックアップファイルを自動削除
find "${BACKUP_DIR}" -type f -name "dify_backup_*.tar.gz" -mtime +${RETENTION_DAYS} -delete

スクリプトを作成したら、実行権限を付与して一度手動でテスト実行し、エラーが出ないか確認しておきましょう。

# 実行権限を付与
chmod +x ~/scripts/auto_backup.sh

# テスト実行
sudo ~/scripts/auto_backup.sh

# バックアップファイルが生成されているか確認
ls -lh ~/backups/dify/

※もし一般ユーザー(ubuntu 等)で運用している場合は、スクリプト内のパス(/root/...)を /home/ユーザー名/... に書き換えてください。

crontab -e で深夜に自動実行するスケジュール設定

スクリプト単体での動作が確認できたら、cron に登録して毎日深夜(アクセスや自動ワークフローの稼働が少ない時間帯)に自動実行させます。パーミッションエラーを防ぐため、root 権限のcrontabに登録するのが確実です。

# root権限でcron設定画面を開く
sudo crontab -e

ファイルの末尾に、以下の1行を追記して保存します(毎日深夜3時30分に実行し、実行ログを backup.log に記録する設定例です)。

30 3 * * * /root/scripts/auto_backup.sh >> /var/log/dify_backup.log 2>&1

これで、人間が意識しなくても毎日最新のバックアップが7世代分キープされ続ける安全な体制が整いました(※VPS上での cron の基本的な書式やタイムゾーン設定については、PythonスクレイピングをVPSで24時間完全自動化する手順の記事内でも詳しく解説しています)。

データを壊さずにDify・n8nを最新バージョンへ安全にアップデートする手順

バックアップ体制が整えば、新機能が追加された際も安心してアップデート作業を行えます。ここでは、データを維持したままDifyとn8nをそれぞれ最新バージョンへ更新する標準手順を解説します。

Difyの安全なアップデート手順(git pull と .env.example の差分反映)

DifyはGitHubリポジトリからソースコードを取得して動かしているため、git pull で最新のコードを取り込み、Dockerイメージを再取得して起動します。このとき、「新しいバージョンで追加された環境変数(.env.example の差分)を確認すること」が最大のポイントです。

# 1. 念のため直前バックアップスクリプトを実行しておく
sudo ~/scripts/auto_backup.sh

# 2. Difyのルートディレクトリへ移動して最新コードを取得
cd ~/dify
git pull origin main

# 3. dockerディレクトリへ移動し、.env と .env.example の差分を確認
cd ~/dify/docker
diff -u .env .env.example

diff コマンドを実行した際、.env.example 側に新しく追加されている重要な環境変数があれば、手動で .env ファイルに追記します(なお、自身が .env でカスタマイズしたポート番号やシークレットキーの値を .env.example で丸ごと上書きして消してしまわないよう注意してください)。

環境変数の確認が終わったら、最新のDockerイメージをプルしてコンテナを再構築します。

# 4. コンテナを停止し、最新イメージを取得してバックグラウンドで再起動
docker compose down
docker compose pull
docker compose up -d

# 5. すべてのコンテナが正常に起動(Up / Healthy)しているか確認
docker compose ps

コンテナ起動時、Difyのバックエンドが自動的にデータベースのマイグレーション(構造更新)を実行するため、既存のワークフローやナレッジデータはそのまま新しいバージョンへ引き継がれます。

n8nの安全なアップデート手順(docker compose pull と不要イメージの削除 docker image prune)

n8nは docker-compose.yml で公式イメージ(n8nio/n8n:latest など)を指定して動かしているケースが多いため、手順はさらにシンプルです。

# 1. n8nのディレクトリへ移動
cd ~/n8n

# 2. 最新のDockerイメージを取得
docker compose pull

# 3. 古いコンテナを停止・削除し、新しいイメージで再作成して起動
docker compose down
docker compose up -d

# 4. 起動状態の確認
docker compose ps

そして、Difyやn8nのアップデート作業が終わった後に必ずセットで実行しておきたいのが、不要になった旧バージョンのDockerイメージの削除です。

# どのコンテナからも参照されていない古いDockerイメージを一括削除
docker image prune -f

# 現在のディスク空き容量を確認
df -h

docker image prune -f を実行することで、アップデートによって浮いた数GB単位の古いイメージファイルが綺麗に削除され、VPSのディスク容量逼迫を未然に防ぐことができます(※稼働中のコンテナや永続化ボリュームのデータが消えることはありません)。

まとめ:堅牢なバックアップ体制を整えてVPS自動化基盤を長期安定稼働させよう

本記事では、VPS上のDocker環境で稼働する「Dify」および「n8n」のデータを守るバックアップ手順と、安全に最新バージョンへアップデートする運用・保守術を解説しました。

  • 永続化データの把握:Difyは dify/docker/volumes と .env、n8nは永続化ボリューム(またはマウントディレクトリ)と暗号化キー設定をセットで保護する。
  • 自動バックアップと世代管理:シェルスクリプトと cron を組み合わせ、深夜の自動退避と find -mtime +7 -delete による古いファイルの自動整理を回す。
  • 安全なアップデート手順:更新前にバックアップを取り、.env の差分確認と docker compose pull を行い、最後に docker image prune -f でディスク容量を空ける。

24時間稼働の自動化パイプラインは、一度止まったりデータが消えたりすると復旧に多くの時間を奪われます。初期構築の段階でこの自動バックアップの仕組みを入れておけば、安心して新しいワークフローの開発やバージョンアップに挑戦できます。

なお、バックアップファイルの保持や複数コンテナの同時稼働を余裕をもって行うには、SSD容量とメモリスペックに優れたコストパフォーマンスの高いVPS選びも重要です。「現在のサーバー容量が手狭になってきた」「これからDify・n8n用のVPSを契約したい」という方は、以下の徹底比較記事もあわせて参考にしてください。

👉 【2026年最新】開発・自動化におすすめのVPS 3選(コスト・スペック比較)を見る