55GBの画像を新しいサーバーに転送する最も簡単な方法
現在、2つのCentOSサーバーがあります。画像ディレクトリを「タール化」してSCPで上書きする方法と方法を知る必要がありますか？
Tarの作成は永遠にかかるので、これが先ほど提案した最も速い方法ですか？コマンドを実行しました。
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 server1 "tar -zc -C /srcdir ./path")
_<(cmd)構成はbashの新機能であり、古いシステムでは機能しないことに注意してください。プログラムを実行して出力をパイプに送信し、そのパイプをファイルのようにコマンドに置き換えます
上記を次のように簡単に記述できただろう：
_server2$ tar -zx -C /destination -f <(ssh server1 "tar -zc -C /srcdir ./path")
_または次のように：
_server2$ ssh server1 "tar -zc -C /srcdir ./path" | tar -zx -C /destination
_または、いくつかの悲しみを救い、rsyncを使用することができます：
_server1$ rsync -az ./path server2:/destination/
_最後に、転送前にデータを圧縮すると帯域幅が減少することを覚えておいてください。ただし、非常に高速な接続では、実際に操作に時間がかかる場合がありますより多くの時間。これは、コンピュータが追いつくのに十分な速さで圧縮できない可能性があるためです：ifcompressing100MBはsend100MB、非圧縮で送信する方が高速です。
あるいは、圧縮レベルを指定できるように、（-zオプションを使用するのではなく）自分でgzipにパイプすることを検討することもできます。圧縮可能なデータを使用した高速ネットワーク接続で、レベル2または3（デフォルトは6）でgzipを使用すると、ほとんどの場合に全体的なスループットが最高になるというのが私の経験です。そのようです：
_server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
_私はそれを自分でrsyncしたくなります-圧縮を行い、リンク損失をうまく処理します。
あなたがそれらをタールにして他に何もない場合、これは最小限のスピードゲインで大量の時間を浪費します。
したがって、cvfスイッチを使用してファイルを単純に風袋引きすると、55 GBのすべてのイメージを読み取り、それらをディスクに書き戻すのにかかる時間が実質的にかかります。 （実質的には、かなりのオーバーヘッドがあるため、さらに多くの時間が無駄になります）。
ここで得られる利点は1つだけです。多くのファイルをアップロードするためのオーバーヘッドが削減されています。画像を圧縮すると、転送時間が短縮される場合があります（ただし、画像はすでに圧縮形式になっていると思いますので、あまり役に立ちません）。計算時間の無駄が増えるだけです。
巨大なtarアーカイブをネットワーク経由で転送することによる最大の欠点は、何か問題が発生した場合、最初からやり直す必要があることです。
私はそのように使用します：
md5sum /images/* > md5sum.txt
scp -r images/* user@Host:/images/
新しいサーバー上
md5sum /images/* > md5sum_new.txt
そしてdiffだけです。また、scpはオンザフライでの圧縮をサポートしているため、個別のアーカイブを作成する必要はありません。
編集する
MD5の情報はOPにとって有用だったので、保存しておきます。しかし、あるコメントが私に新しい洞察を与えました。したがって、少し検索すると、この有用な情報が提供されました。 ここの件名は直接の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であり、暗号化はありませんが、他のサーバーに直接送信されます。両方を同時に開始します（-w5は5秒間の猶予を与えます。帯域幅が狭い場合は、両端のtarに-zを追加します。
私はあなたに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」オプションがあります。これは、この種のものが好きな場合にはいい感じです。
1つのポイント-すべてのホストがrsyncを備えているわけではなく、ホストのtarのバージョンが異なる場合もあります。このため、頻繁に無視されるcpioを使用して、最初の呼び出しポートとして推奨することができます。
Sshを介してcpioを実行すると、ホスト間でファイル/ディレクトリ構造のアドホックレプリケーションを実行できます。このようにして、cpio、nom-nomに「フィード」する必要があるときに、何が送信されるかをより細かく制御できます。また、引数の移植性が高く、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にコピーします。
お役に立てれば。
または、常にtarパイプを使用できます。
(cd /path && tar -cjf - * ) | ssh user@Host 'tar -xjf - -C /path'
'j' = bzip2、gzipには 'z'を、tarがサポートしている場合は--lzmaを使用できます。
彼らはファイルを転送するためにインターネットを必要とするのではなく、共有ネットワーク上にありますか？ NFSまたはFTPはSCPのオーバーヘッドよりもはるかに高速ですが、転送中に暗号化が失われます。