Difyを運用していると、「サーバーのスペック不足で引っ越したい」「開発環境から本番環境へデータを移したい」といったシーンに直面することがあります。
この記事では、Dockerで構築されたDify環境のデータを、安全かつ確実に新しい環境へ移行するための手順を解説します。データベース（PostgreSQL）の論理バックアップを使用する推奨手順と、ボリュームごとコピーする簡易手順の2通りを紹介します。
方法1：pg_dumpを使用した完全移行（推奨）
データベースの中身をSQLファイルとして書き出し、新環境で読み込ませる方法です。データの整合性が保たれやすく、DockerやOSのバージョンが異なる環境間でも移行できる可能性が高いため、最も推奨される方法です。
ステップ1：旧サーバーでのデータエクスポート
まず、稼働中のDifyコンテナからデータベースのダンプ（バックアップファイル）を作成します。
# Difyのディレクトリへ移動 cd /path/to/dify/docker
データベースのダンプを作成（dify_backup.sqlというファイル名で保存）
docker compose exec -T db pg_dump -U postgres -d dify > dify_backup.sql
コンテナを停止（データの整合性を保つため）
docker compose downステップ2：新サーバーへのファイル転送
作成した dify_backup.sql と、アップロードファイルが格納されている volumes ディレクトリを新サーバーへ転送します。
# SQLファイルの転送 scp dify_backup.sql user@new-server-ip:/path/to/new/dify/
アップロードファイル（画像など）の転送
volumes/app/storage などを圧縮して送るのが効率的です
tar -czvf storage_backup.tar.gz volumes/app/storage scp storage_backup.tar.gz user@new-server-ip:/path/to/new/dify/ステップ3：新サーバーでのデータインポート
新サーバーでDifyを初回起動した後、データを流し込みます。
# 1. 新環境でDifyを起動（初回は空のDBが作られます） docker compose up -d
2. データをインポート
cat dify_backup.sql | docker compose exec -T db psql -U postgres -d dify
3. アップロードファイルを配置（バックアップを展開）
tar -xzvf storage_backup.tar.gz -C ./
4. コンテナを再起動して反映
docker compose restart方法2：Dockerボリュームの直接コピー（簡易版）
Dockerのボリュームディレクトリ（volumes）を丸ごとコピーする方法です。手順は簡単ですが、移行元と移行先でDockerやOSの環境が大きく異なると動作しないリスクがあります。
移行手順
- 旧サーバー：
docker compose downでコンテナを停止します。 - 旧サーバー： Difyのディレクトリ（
dockerフォルダ一式）を丸ごと圧縮します。tar -czvf dify_full_backup.tar.gz dify/docker - ファイル転送：
scpコマンド等で新サーバーへ転送します。 - 新サーバー： ファイルを展開し、
.envファイルの設定（ドメインやポートなど）を新環境に合わせて修正します。 - 新サーバー：
docker compose up -dで起動します。
移行後のトラブルシューティング
移行後にDifyがうまく動かない、または極端に重い場合のチェックポイントです。
ポートの競合（Address already in use）
新サーバーで既に別のサービスが動いている場合、ポート（80, 443, 5432など）が競合することがあります。.env ファイルでポート番号を変更するか、競合しているプロセスを停止してください。
サーバーリソースの不足
Difyは複数のコンテナ（API, Worker, DB, Redis, Weaviateなど）を同時に動かすため、メモリ不足になりがちです。
# コンテナごとのリソース使用状況を確認 docker statsCPU使用率が常に100%だったり、メモリ使用量が上限に達している場合は、サーバーのスペックアップや、docker-compose.yaml でのリソース制限設定（limits）を検討してください。
2つのバックアップ方法の違い
データベースをバックアップする最初の方法（pg_dump/psql）と、2番目の方法（ボリュームを直接コピー）の主な違いは、システムの負荷ではなく、安全性と互換性です。
「pg_dumpとpsql」を使った方法は、同一のデータベースでの管理となり、「ボリュームを直接コピーする方法」はDifyコンテナ毎にデータベースを分離するため、より独立性の高い環境を構築できます。このため、今回は「ボリュームを直接コピーする方法」を使用します。
| 項目 | pg_dumpとpsqlを使った方法 | ボリュームを直接コピーする方法 |
|---|---|---|
| データ形式 | SQLコマンド形式。 | ディレクトリ内の物理ファイル。 |
| 互換性 | PostgreSQLのバージョンが異なっていても比較的安全。 | Docker、OS、PostgreSQLのバージョンが完全に一致する必要がある。 |
| データの整合性 | データベースの論理的な整合性を保つため、より安全。 | ファイルが破損しているとデータが使えないリスクがある。 |
| システム負荷 | ダンプとリストア時にCPUとメモリを使用する。 | 圧縮と転送にI/OとCPUを使用する。 |
結論: pg_dump/psqlを使った方法は、少し複雑ですが、データの安全性が非常に高く、最も推奨される方法です。ボリュームを直接コピーする方法は、簡単ですが、両サーバーの環境が完全に一致していないと動作しないリスクがあります。
どちらの方法も、元の環境と新しい環境のDifyのバージョンが一致していることを確認してください。 バージョ
まとめ
Difyのデータ移行は、「pg_dumpによるDB移行」＋「ファイルストレージのコピー」が最も確実です。サーバー移転やバックアップからの復旧が必要になった際は、この手順を参考にしてください。
また、移行作業前には必ず、現行環境のバックアップを別途保存しておくことを強くおすすめします。
【推奨】業務システム化に有効なアイテム
生成AIを学ぶ
システム化のパートナー
VPSサーバの選定
コメント