Difyデータ移行の完全ガイド：バックアップから復元まで

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 stats

CPU使用率が常に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を使用する。