rsyncに2つのリモートを使用できないのはなぜですか？[閉まっている]

発信元と宛先の両方がリモートの場合、rsyncは次のエラーを出します。

The source and destination cannot both be remote. rsync error: syntax or usage error (code 1) at main.c(1156) [Receiver=3.0.7]

rsyncでこれを行うには乗り越えられない技術的な障害がありますか？それとも、まだ実装されていない場合ですか？2つのリモート間の転送を仲介し、ハッシュとデータの両方を保持するローカルバッファーをメモリに作成するのは比較的簡単に思えます。

編集

人々は接線方向の提案をしているので、特定のユースケースを詳述する別の質問を投稿しました。これらは実際には2つの独立したものであり、rsyncのこれらの特定の詳細を知ることは価値があると思います

rsync remote

— ゴンカロップ
ソース

リモートsrc rsyncdがリモートdest rsyncdにデータを送信します。srcシステムにsshしてrsyncを呼び出すことで回避できます。

— アレックスホルスト

@AlexHolstこれは私の特定のケースではうまくいかないと思います。編集を参照してください

— -goncalopp

申し訳ありませんが、Server Faultは理論的な質問には対応していません。実際に直面している問題に関する回答可能な質問のみ。詳細については、よくある質問をご覧ください。

— クリスS

申し訳ありません（モデレーター）、これは答えられる興味深い質問です：理由は、rdiffアルゴリズムが対称的でないことです。CPUとメモリのオーバーヘッドが大きくなるのは「アクティブ」側です。「パッシブ」側は、変更されたすべてのファイルのすべてのブロック（--block-sizeパラメーターを参照）のチェックサムを計算して再送信するだけです。これは非常に小さなメモリ要件で実行され、ほとんどの操作は第1レベルのCPUキャッシュで実行できます。「アクティブ」側は、同じデータブロックが現在配置されているチェックサムで検索する必要があります

— ...-hynekcer

これは素晴らしい質問だと思います（私はまさにこの質問を持っていたので、私はここにいるのです）。私はまだ答えを知りたいです！

— reinierpost

回答:

リモートマシンに接続して、そこから転送を開始してみてください。ssh-keysを使用している場合は、エージェントパススルーを使用して認証を管理できます。

ssh -A remotehostA rsync /remote/file/on/host/a remoteHostB:/destination/

このコマンドは、remoteHostAにログオンし、そこからrsyncを実行します。

— カプラア
ソース

セキュリティに関する考慮事項がいくつかあります。編集を参照

— goncalopp

また、2つのシステム間の直接アクセスがない場合は機能しません...直接アクセスを取得するために、セキュリティセクションでファイアウォールルールが正しく実装されるまで2週間待つ必要がある場合...

— Gert van den Berg

シナリオ：サーバーAには、サーバーBおよびCへのキーベースのルートアクセスがあります。両方のルートアクセスを使用して、BからCに同期する必要があります。ただし、BまたはCが互いにルートアクセスすることは望ましくありません。

— -thomasrutter

scp -3r <remote src> <remote dest>

これを行うのに問題はありません。

— カルマヒューズボックス
ソース

ただし、scpはデルタを実行しないので、この場合は非常に必要です。編集の詳細

— -goncalopp

ところで、あなたはホスト間のプロキシのようになりたい場合はオプション-3である必要はありSCP

— alterpub

残念ながら、scpにはrsyncの重要な機能がありません。たとえば、ファイルシステム（ユーザーフォルダーにマウントされたネットワークドライブなど）を渡さないオプション、アーカイブモード（「シンボリックリンク、デバイス、属性、権限、所有権など）が保持される」など） ...

— 要塞

これを回避するには、リモートファイルシステムの一方（または両方）をでマウントしsshfsます。次に、rsyncはそれをローカルであるかのように扱います。

残念ながら、これはファイルシステムがでマウントされているマシンで多くの帯域幅を使用することになりますsshfsので、あなたと3番目のマシンの間に多くの帯域幅があるマシンでのみこれを行うことをお勧めします。

もちろん、理想的な解決策は、マシンが互いに直接通信することです。私は考えることはできません良いなぜ彼らはいけない理由。

— マイケル・ハンプトン
ソース

編集を参照してください。あなたが言及している理由はセキュリティです。2台のマシンのいずれか（ルート）が侵害されても、もう一方へのファイルシステムアクセスが発生してはなりません。しかし、多分私は間違った角度からこれを攻撃しているし、第三のマシンを含まない解決策があります

— ...-goncalopp

うーんこれらの詳細は本当にこの質問に追加されるべきだと思います。ルートの侵害については、SELinuxを実際に使用する必要があります。

— マイケルハンプトン

他の誰かが特にrsyncでのこの動作に興味があるかもしれないので、私はこれを残しました。どちらのマシンでも、ローカルで実行するrsyncが両方の場合（特定のディレクトリへのファイルシステムアクセス）でまったく同じ動作をしている場合、いずれかのマシンのSELinuxは他方が侵害されているかどうかを知ることができません。

— goncalopp

SELinuxの仕組みを理解しているかどうかはわかりません。その全体のポイントは、たとえそのサービスがrootとして実行されていても、明示的にアクセスが許可されていないものにアクセスすることからサービス（侵害されたサービスでさえ）を防ぐことです。

— マイケルハンプトン

私はSELinuxポリシーの基本的な理解しかありませんが、rsync はファイルシステムにアクセスするはずですよね？リモートマシンが侵害された場合、まったく同じ種類の（ローカル）アクセスパターンは望ましくありません。

— goncalopp