あるDockerコンテナから別のサーバーへのデータ全体のバックアップと転送

完全かつ安全なDockerコンテナを別のサーバーに移動するにはどうすればよいですか？

Dockerコンテナの完全なバックアップと移行には、主に3つの要素が含まれます。 画像、 データ（ボリュームまたはバインドマウント） そして 設定/メタデータ. このステップバイステップガイドでは、コンテナ化されたサービス（Webアプリケーションやデータベースを含む）を移行するための、安全でエラーのない、かつ元に戻せる方法について説明します。.

概要と前提条件

始める前に、以下のものを用意してください。

• SSHアクセス 適切なユーザーまたはroot権限で両方のサーバーにアクセスします。.
• ソースと宛先の両方にDocker（必要に応じてdocker-composeも）をインストールします。簡単なインストール例：

curl -fsSL https://get.docker.com | sh
# or follow your distribution guide

• アーカイブ用の十分なディスク容量があることを確認してください。.
• 安全な転送のためのSSHキーと次のようなツール rsync または アイテム番号: SCP-1811.
• サービス停止のスケジュール設定や低遅延方式の計画。.

最初に確認するコマンド：

docker ps -a
docker volume ls
df -h
du -sh /var/lib/docker/volumes/*

バックアップと移行戦略 ― 適切な方法の選択

完全な移行を実現するための3つの重要な要素：

• 画像 コンテナ（コード／バイナリ）
• 安定したデータ （ボリュームまたはバインディングマウント）
• 設定とメタデータ (docker-compose.yml、環境ファイル、ネットワーク、シークレット)

一般的な方法：

• docker export / docker importコンテナファイルシステムは含まれますが、メタデータと名前付きボリュームは転送されません。.
• docker save / docker load: 作成された画像に適しています。.
• ボリュームのバックアップ tar形式で圧縮し、rsync/scpで転送するか、S3にアップロードしてください。.
• プライベートレジストリの使用 プッシュ/プル画像の場合。.
• 管理ツールを使用する docker-composeやKubernetesのように、定義に基づいてサービスを再構築する。.

シナリオ1 — ローカルイメージと名前付きボリューム（例：Webアプリケーション＋MySQL）

前提条件：Webコンテナとmysql_dataという名前のボリュームを持つMySQL。手順：

1) コンテナイメージの取得

ローカルイメージがある場合、またはコンテナに変更が加えられた場合は、まずイメージ名とコンテナIDを確認し、必要に応じてコンテナをコミットして保存してください。.

docker ps --no-trunc --format '{{.Image}} {{.ID}}'
docker commit CONTAINER_ID myapp:backup-2026-07-14
docker save -o /tmp/myapp_backup_image.tar myapp:backup-2026-07-14

2) 名前付きボリュームのバックアップ

ホスト上でボリュームの内容をtarアーカイブするヘルパーコンテナを使用した安全な方法：

docker run --rm \
  -v mysql_data:/data \
  -v /tmp/backup:/backup \
  ubuntu \
  bash -lc "cd /data && tar czf /backup/mysql_data.tar.gz ."

大容量データの場合は、zstdのような高速な圧縮ツールを使用できます。

docker run --rm -v mysql_data:/data -v /tmp/backup:/backup ubuntu bash -lc "cd /data && tar -I 'zstd -19' -cf /backup/mysql_data.tar.zst ."

3) データベースのバックアップ（推奨）

データベースの一貫性と整合性を確保するには、論理ダンプを取得するのが最善です。

docker exec CONTAINER_ID sh -c 'exec mysqldump --all-databases --single-transaction -u root -p"$MYSQL_ROOT_PASSWORD"' > /tmp/all_databases.sql

説明： この方法はボリュームファイルシステムへの依存を排除し、正常な論理ダンプを生成します。.

4) 宛先サーバーへ転送する

安全かつ継続的な転送、特に大容量ファイルの転送には、rsyncの使用をお勧めします。.

rsync -avP -e "ssh -p 22" /tmp/myapp_backup_image.tar user@target:/tmp/
rsync -avP -e "ssh -p 22" /tmp/mysql_data.tar.gz user@target:/tmp/

または、scp を使えばもっと簡単です。

scp /tmp/myapp_backup_image.tar user@target:/tmp/

注記： 大容量の転送には、rsync --partial --progress または rclone などのツールを使用して S3/MinIO を使用してください。.

5) 宛先サーバーに復元する

イメージをアップロードしてボリュームを復元し、docker-composeでサービスを開始します。

docker load -i /tmp/myapp_backup_image.tar
docker volume create --name mysql_data
docker run --rm -v mysql_data:/data -v /tmp/backup:/backup ubuntu bash -lc "cd /data && tar xzf /backup/mysql_data.tar.gz"

SQLダンプを使用した場合は、一時的なmysqlコンテナを作成し、インポートを実行してください。

docker run --name mysql-temp -e MYSQL_ROOT_PASSWORD=yourpassword -d mysql:8
cat /tmp/all_databases.sql | docker exec -i mysql-temp sh -c 'mysql -u root -p"$MYSQL_ROOT_PASSWORD"'

次に、docker-compose.ymlファイルとenvファイルを配置し、サービスを開始します。

docker-compose -f docker-compose.yml up -d

6) テストとレビュー

ログ、データの整合性、チェックサムを確認することを忘れないでください。

docker logs -f CONTAINER
sha256sum /tmp/mysql_data.tar.gz
sha256sum /tmp/backup/mysql_data.tar.gz

シナリオ2 — バインドマウント（ホストフォルダ）を使用したコンテナ

コンテナがバインドマウントを使用している場合（例：ホスト上の /srv/app/data）、ホストパスを rsync または tar で圧縮し、宛先に同じパスを用意してから、コンテナを起動します。.

rsync -avP -e "ssh" /srv/app/data/ user@target:/srv/app/data/

次に、同じバインドマウントパスを使用して、宛先でコンテナを起動します。.

シナリオ3 ― 機密性の高いデータベースのダウンタイムゼロ移行

サービスの中断を減らすために：

• レプリケーション （MySQLレプリケーションまたはPostgreSQLストリーミングを）実装し、同期後に切り替えを実行します。.
• 初期および最終rsync: 大容量データに対しては最初にrsyncを実行し、その後、--inplaceと--deleteオプションを指定してrsyncを実行し、小さな変更を同期します。.

rsync -azP --delete --inplace /var/lib/docker/volumes/mysql_data/_data/ user@target:/var/lib/docker/volumes/mysql_data/_data/

最後のrsync処理が完了したら、サービスを数秒間停止してから、宛先側でサービスを起動してください。.

転校方法の比較（メリット／デメリット）

• dockerの保存/読み込み画像の処理は高速ですが、ボリュームデータは含まれません。.
• dockerのエクスポート/インポートコンテナファイルシステムは含まれますが、メタデータとボリュームは失われます。.
• ボリュームに対するrsync正確な制御と再開が可能であるが、管理とテストが必要となる。.
• 論理データベースダンプ信頼性が高く、異なるデータベースバージョン間での移行に適しています。.
• 個人登録複数のサーバーに画像を分散させる際のベストプラクティス。永続データは別途転送する必要があります。.

セキュリティに関するヒント（非常に重要）

実用的なセキュリティ対策のヒント：

• 保護された秘密鍵とアクセス制限を備えたSSHを使用してください。.
• 機密データを送信する前に、次のようなツールで保護してください。 gpg または 年 暗号化します。例:

gpg --encrypt --recipient [email protected] /tmp/mysql_data.tar.gz

転送後は、必ずファイルの整合性を確認してください。 sha256sum チェック。.

目的地では、サービスを開始する前に、ファイアウォールとポートの制限を確認し、必要に応じて厳格なアクセス制限を設定してください。.

ビッグデータのための実践的なヒントと最適化

• 圧縮 zstdまたは適切なレベルのgzipを使用する場合：tar -I 'zstd -19' -cf backup.tar.zst /data
• 接続が不安定な場合は、rsyncに--partialオプションを付けて実行を再開してください。.
• 数テラバイト規模のデータ転送の場合は、物理ディスクを送付するか、転送先に近い場所にオブジェクトストレージを設置することを検討してください。.

Dockerの互換性とバージョン

移行前に、ソースと移行先のDockerのバージョンを確認してください。通常、イメージは互換性がありますが、Composeやドライバーの新機能によっては、調整が必要になる場合があります。.

移行先の場所とサーバータイプの選択

データセンターの場所とサーバーの種類は、アプリケーションによって異なります。

• トレーディングと外国為替： ping値を最小限に抑えるため、取引所サーバーに近い場所に設置する。.
• ゲーム： ヨーロッパ/アメリカの適切な場所、またはDDoS対策ソフトを導入しているプレイヤーの近くにある場所。.
• 人工知能とレンダリング: 高I/O性能を実現するGPUおよびNVMeサーバー。.
• ウェブサイト： CDNを備えたクラウドサーバーで、主要ユーザーに近い場所に設置されています。.

当社は、世界85ヶ所以上の拠点、GPUサーバー、BGPネットワークを提供しており、様々な移行ニーズに対応可能です。.

完全な例：docker-compose を使用した Web + MySQL 移行

手順の概要：

1. docker-composeの設定とローカルイメージ作成の出力：

docker-compose -f docker-compose.yml config > /tmp/compose_config.yml
docker-compose build
docker save $(docker-compose images -q web) -o /tmp/web_image.tar

2. バックアップボリューム:

docker run --rm -v project_mysql:/data -v /tmp/backup:/backup ubuntu bash -lc "cd /data && tar czf /backup/mysql_data.tar.gz ."

3. rsyncを使用してファイルを宛先に転送し、その後、宛先で復元してdocker-composeを実行します。.

切り替え前の最終チェックリスト

• イメージとボリュームのバックアップが完了し、チェックサムも検証済みです。.
• 環境情報と機密情報は保護または保管庫に保管されます。.
• DockerとComposeのバージョンを確認済みです。.
• 宛先ネットワークとファイアウォールが設定されています。.
• ロールバックシナリオが定義されました。.
• 最終的なスケジュールが発表され、監視体制も整いました。.

よくある質問