現在、2つのCentOSサーバーがあります。イメージディレクトリを "tar"し、それをSCPする最も簡単な方法と方法を知る必要がありますか？
tarringが永遠にかかっているので、それが私がちょうど提案した最も速い方法です...私はコマンドを実行しました：
tar cvf imagesbackup.tar images
そして、私はちょうどそれを上に行くつもりだった。
もっと速い方法があれば教えてください。両方のマシンにリモート/ SSHアクセスできます。
回答:
tarを使用してローカルディスクに書き込む代わりに、sshを使用してネットワーク経由でリモートサーバーに直接書き込むことができます。
server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"
「ssh」コマンドに続く文字列は、対話型ログオンの代わりにリモートサーバーで実行されます。それらがローカルであるかのように、SSHを介してこれらのリモートコマンドとの間で入出力をパイプすることができます。コマンドを引用符で囲むと、特にリダイレクトを使用する場合の混乱を避けることができます。
または、他のサーバーでtarファイルを直接抽出できます。
server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"
めったに使用されない-Cオプションに注意してください。これは、「何かを行う前にまずこのディレクトリに変更する」ことを意味します。
または、宛先サーバーから「プル」したい場合があります。
server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")
この 構成はbashにとって新しいものであり、古いシステムでは機能しないことに注意してください<(cmd) 。プログラムを実行し、出力をパイプに送信し、そのパイプをファイルであるかのようにコマンドに置き換えます。
上記の内容を次のように簡単に記述できたはずです。
server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")
または次のように：
server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination
または、いくつかの悲しみを省いて、rsyncを使用することもできます。
server1$ rsync -az ./path server2:/destination/
最後に、転送前にデータを圧縮すると帯域幅が削減されることを忘れないでください。ただし、非常に高速な接続では、実際に操作に時間がかかる場合があります。これは、お使いのコンピューターが十分に高速に圧縮できないためです。100MBを圧縮するのに100MB を送信するよりも時間がかかる場合、非圧縮で送信する方が高速です。
あるいは、圧縮レベルを指定できるように、（-zオプションを使用するのではなく）自分でgzipするパイピングを検討することもできます。私の経験では、圧縮可能なデータを使用した高速ネットワーク接続では、レベル2または3（デフォルトは6）でgzipを使用すると、ほとんどの場合で全体的なスループットが最高になります。そのようです：
server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
私は自分自身でそれを再同期したいと思うでしょう-それは圧縮を行い、リンク損失をうまく処理します。
あなたがそれらをただtarしただけで、これが最小限の速度向上で多くの時間を無駄にします。
したがって、cvfスイッチを使用してファイルを単純に風袋引きすると、55GBのすべてのイメージを読み取ってディスクに書き戻すのにかかる時間が実質的にかかります。（実質的には、かなりのオーバーヘッドがあるため、さらに時間が無駄になります）。
ここで得られる利点は1つだけです。多くのファイルをアップロードするためのオーバーヘッドが削減されています。画像を圧縮すると、転送時間が短縮される場合があります（ただし、すでに圧縮形式になっていると思われるため、これはあまり役に立ちません）。計算時間の無駄。
巨大なtarアーカイブを有線で転送することの最大の欠点は、何か問題が発生した場合、最初からやり直す必要があることを意味します。
私はその方法を使用します：
md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/
新しいサーバー上
md5sum /images/* > md5sum_new.txt
それからちょうどdiff。また、scpはオンザフライで圧縮をサポートしているため、個別のアーカイブを作成する必要はありません。
OP5が有用だったため、MD5情報を保持します。しかし、1つのコメントが私に新しい洞察を与えました。そのため、少しの検索でこの便利な情報が提供されました。 ここでの主題は直接SCPではなくSFTPであることに注意してください。
FTPとは対照的に、SFTPはファイルの転送にオーバーヘッドを追加します。ファイルがクライアントとサーバー間で転送されると、「パケット」と呼ばれる小さなチャンクに分割されます。たとえば、各パケットが32KBであるとします。SFTPプロトコルは、送信時に各32KBファイルに対してチェックサムを実行し、そのチェックサムとそのパケットを含めます。受信者はそのパケットを取得してデータを復号化し、チェックサムを検証します。チェックサム自体は、CRC32チェックサムよりも「強力」です。（SFTPはMD5やSHAなどの128ビット以上のチェックサムを使用するため、これはすべてのパケットで実行されるため、転送の一部として実行される非常に詳細な整合性チェックがあります。）それ自体は（追加のオーバーヘッドのため）遅くなりますが、転送が正常に完了すると、事実上、
Paceyのmd5sum提案に加えて、次のものを使用します。
宛先で： nc -w5 -l -p 4567 | tar -xvf -
次に、ソースで： tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567
まだtar / untarであり、暗号化はありませんが、他のサーバーに直接送信されます。両方をタンデムで起動し（-w55秒の猶予が与えられます）、動作を確認します。帯域幅が狭い場合は、両端のtarに-zを追加します。
ワンポイント-すべてのホストがrsyncを持っているわけではなく、ホストが異なるバージョンのtarを持っているかもしれません。このため、しばしば無視されるcpioを使用した最初の呼び出しポートとして推奨できます。
sshを介してcpioを実行すると、ホスト間でファイル/ディレクトリ構造のアドホックレプリケーションを実行できます。このようにして、cpioを「フィード」する必要があるときに、見送りで送信されるものをより細かく制御できます。また、引数の移植性が高く、cpioはあまり変化しません。これは、異機種環境で複数のホストを管理する場合に重要なポイントです。
/ export / homeとsubdirsをリモートホストにコピーする例：
cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'
上記は、/ export / homeおよびすべてのサブディレクトリの内容をリモートホストの/ export / homeにコピーします。
お役に立てれば。
あなたはsshアクセスがあり、rsyncアクセスがあります。
rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/
または
rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/
「rsyncエラー：main.c（977）[sender = 2.6.9]で一部のファイルを転送できませんでした（コード23）」などのエラーを受け取った場合は、サーバー間のユーザーとグループを確認してください。不一致がある可能性があります。
rsyncで転送を圧縮する場合は、rsync "-z"オプションを使用します。このオプションはより多くのCPUを使用しますが、帯域幅は少なくなりますので、注意してください。
「--progress」オプションがあり、これにより転送された割合が表示されます。これは、そのようなことが好きな場合に便利です。
ファイルを転送するためにインターネットを必要とするのではなく、共有ネットワーク上にありますか？NFSまたはFTPはSCPのオーバーヘッドよりもはるかに高速かもしれませんが、転送中に暗号化を失います。