2台のサーバー間で大きなフォルダーを同期する(再開可能・バックグラウンド)

最終更新: 2026-07-08

一方のサーバーに大きなフォルダー——数十 GB——があり、それをもう一方に完全な複製として欲しいとします。何時間もターミナルを見張ることはできませんし、途中で落ちた転送が最初からやり直しになるのも困ります。relayium sync はまさにこのために作られています。一方向の増分ミラーで、すでにあるものはスキップし、途中まで送ったファイルは止まったところから再開し、各ファイルを端から端まで検証します。

本ガイドでは、無人で自己修復する転送を構築します。送信側を一度だけ承認し、リスナーをバックグラウンドで動かし、tmux 内のリトライループで relayium sync を回して、接続が切れても続行させ、フォルダー全体が届くまで走らせます。

なぜ relayium sync がこの用途に向くのか

sync はネイティブプロトコル上の一方向増分ミラーです(両端に relayium をインストールします)。無人で繰り返し実行しても安全な理由が3つあります:

すでにあるファイルはスキップ: 受信側のコピーがサイズと更新時刻で一致するファイルは再送しません。
途中のファイルを再開: 接続が切れたとき半分だけ送られていたファイルは、次回の実行でディスク上にすでにあるバイトオフセットから続行し、やり直しません。
各ファイルを検証: 各ファイルを端から端まで SHA-256 で検査するため、完了したミラーは完全だと分かります。
これらのおかげでコマンドは冪等です——もう一度実行しても残りの作業だけを行います。これこそがリトライループで巨大な転送を完了させる要点です。

前提条件

両方のサーバーに relayium をインストールします(sync はネイティブプロトコルを話すため、各端に必要です):

# on BOTH servers
curl -fsSL https://relayium.com/install.sh | sh

本ガイドはデーモン直結(relayium://)を使うため、2台のサーバー間に SSH アクセスは不要です。
受信側のファイアウォールまたはセキュリティグループで、リスナーのポート(既定 9031)を送信側に開放してください。

送信側を一度だけ承認する(受信側)

受信側は送信側のマシンを一度だけ承認します。承認はディスクに書き込まれ、再起動をまたいでも有効なので繰り返す必要はありません。まずターミナルでリスナーをフォアグラウンド起動し、--dir を親ディレクトリに向けます——relayium sync /root/workspace は受信側で workspace/... を再現するので、--dir /root ならファイルは /root/workspace/ に着地します。

送信側の初回接続時(次節)、serve はその住所とフィンガープリントを表示して承認を求めます。y と答えれば永続的に記憶されます:

# on the RECEIVER (foreground, to approve interactively)
relayium serve --dir /root --port 9031

# on the RECEIVER, at the first connection:
Incoming push from 203.0.113.9:52140
  fingerprint: 9f2c41ab…
Accept and remember this peer? [y/N] y

完全に無人にするならプロンプトを省けます: 送信側で relayium id を実行してフィンガープリントを表示し、受信側で relayium authorize <フィンガープリント> を実行します。
--dir は同期するフォルダーの親であって、フォルダー自体ではありません——さもないとファイルが1階層深く着地します(例: /root/workspace/workspace)。

リスナーをバックグラウンドで動かす(受信側)

フィンガープリントを承認したら、フォアグラウンドの serve を止め(Ctrl-C)、ログアウト後も生き残るようデタッチして再起動します。保存済みのフィンガープリントを読み込み、送信側を確認なしで受け入れます——今回はプロンプトは出ません:

# on the RECEIVER
nohup relayium serve --dir /root --port 9031 > ~/relayium-serve.log 2>&1 &

serve は接続を1つずつ処理して動き続けるため、下のリトライループの再接続のたびに受信の準備ができています。
常時稼働の受信箱にするなら、代わりに systemd で動かします(Restart=always、--config-dir /etc/relayium)。

tmux 内のリトライループで sync を回す(送信側)

長い転送は中断されます——セッション切断、不安定なネットワーク、再起動。解決策は高級なツールではなく、sync を成功するまで再実行するループと、ログアウト後も生き残らせる端末マルチプレクサです。ここでは tmux が nohup より扱いやすい: 間違えやすい出力リダイレクトがなく、再接続して進捗を見られます。

tmux セッションを開始し、until ループでミラーを実行します——10秒ごとに再試行し、sync が成功を返したら自分で終了します:

# on the SENDER
tmux new -s xfer      # apt install -y tmux if it's missing

until relayium sync /root/workspace relayium://203.0.113.43:9031; do echo "$(date) retrying"; sleep 10; done

Ctrl-b の次に d でデタッチ。ターミナルを閉じてもループは動き続けます。tmux attach -t xfer で再接続します。
再試行のたびに作業は減ります: 転送済みのファイルはスキップされ、半分送ったファイルは再開する——だからループは収束して終わります。
進捗はファイルが1つ完了するごとに1行表示されるので、大きなファイルは完了まで静かに転送されます。無音は停止ではありません(トラブルシューティング参照)。

検証と仕上げ

until ループが終わり、通常のシェルプロンプトに戻ったら転送は完了です。両側が一致することを確認してから、リスナーを停止します:

# compare totals on BOTH servers
du -sh /root/workspace

# on the RECEIVER, once verified
pkill -f 'relayium serve'

各ファイルは到着時に SHA-256 で検査済みなので、サイズの一致とクリーンな終了は複製が完全であることを意味します。

トラブルシューティング

問題に見えて多くの場合そうでないこと——そして多くの場合本当に問題であること(ポートの遮断)を挙げます。

無音は停止ではありません。進捗は各ファイルが完了したときだけ表示されるので、大きなファイルは静かに転送されます。送信側で ss -tnp | grep 9031 を使って実際の状態を確認します——ESTAB は接続して転送中、SYN-SENT はリスナーに届いていないことを意味します。
SYN-SENT はポートが遮断されている印です。受信側で送信側に向けて 9031/TCP を開放します(クラウドのセキュリティグループ、または ufw allow 9031/tcp)。「転送がいつまでも始まらない」最も一般的な原因です。
複数行の nohup より、tmux と1行のループを優先します。引用符と > リダイレクトを含む複数行コマンドをシェルに貼り付けると、リダイレクトで壊れたり、> の継続プロンプトで止まったりしがちです。
プロセスを片付けるときは正確に一致させます(pkill -f 'relayium sync')。pkill relayium ではありません——広い一致は同じマシンで動く無関係な relayium プロセスを巻き込みかねません。
venv などの再生成可能なディレクトリは除外する価値があります。Python の仮想環境は数 GB のライブラリを抱えることがあり、対向側で pip が作り直せます。除けば転送を大きく節約できます。
シンボリックリンクと特殊ファイルはスキップされます——sync が転送するのは通常ファイルだけです。重要なシンボリックリンクは別途扱ってください。

よくある質問

転送が途中で中断されたらどうなりますか?

何も失われません。relayium sync を再実行してください——受信側にすでにあるファイルはスキップし、半分送ったファイルはディスク上のバイトオフセットから再開します。本ガイドの until ループが、フォルダー全体がミラーされるまでこれを自動で行います。

これは rsync と何が違いますか?

どちらも増分の一方向ミラーですが、relayium sync は固定された TLS 接続で動作し、SSH アカウントを必要とせず(デーモン直結)、証明書のフィンガープリントで2台を認証し、各ファイルを SHA-256 で検証します。relayium の他モードと同じ転送エンジンです。

ソースから削除したファイルを、sync は受信側でも削除しますか?

あなたが求めたときだけです。既定では sync は追加と更新だけを行います。削除をミラーするには --delete を渡し、それが有効になるには受信側が --allow-delete で serve を実行している必要があります——さもなければ削除は無視され、報告されます。

2つのフォルダーを継続的に同期し続けられますか?

はい。--watch を付けると sync は動き続け、ソース配下の変更のたびに再ミラーします。大きなフォルダーの一度きりの移動には不要です——リトライループと素の sync で十分です。

ポートを開ける必要がありますか?

デーモン直結ならはい——リスナーのポート(既定 9031)が送信側から到達可能である必要があります。ポートを開けたくなく、サーバー間にすでに SSH があるなら、sync は SSH 経由でも動きます: relayium sync /path user@host:/path(リモートに relayium が必要)。

自分の2台のサーバー間でフォルダーをミラーしましょう——増分、再開可能、張り付き不要。

CLI を入手する