どうすればscpで多数の小さなファイルをコピーできますか？
数ギガバイトと数千の小さなファイルがあるディレクトリがあります。 scpを使用してネットワーク経由で複数回コピーしたい。ソースマシンと宛先マシンのCPU時間は安価ですが、各ファイルを個別にコピーすることによって追加されるネットワークオーバーヘッドは非常に大きくなります。私はそれをtar/gzipして発送しますが、ソースマシンのディスクが不足しています。
tar -czf <output> <directory>の出力をscpにパイプする方法はありますか？そうでない場合、別の簡単な解決策はありますか？私のソースマシンは古い（SunOS）ので、インストールはしません。
Sshセッション全体でtarをパイプすることができます。
$ tar czf - <files> | ssh user@Host "cd /wherever && tar xvzf -"
Bzip2圧縮を使用したtarは、ネットワークとCPUの負荷をできるだけ多くする必要があります。
$ tar -C /path/to/src/dir -jcf - ./ | ssh user@server 'tar -C /path/to/dest/dir -jxf -'
画面出力によりプロセスが遅くなる可能性があるため、-vを使用しません。ただし、詳細な出力が必要な場合は、リモート部分ではなくtar（-jcvf）のローカル側で使用してください。
バックアップコピーの更新など、同じ宛先パスに繰り返しコピーする場合、圧縮を使用したrsyncが最適です。
$ rsync -az -e ssh /path/to/src/dir/ user@server:/path/to/dest/dir/
Srcパスとdestパスの両方が/で終わっていることに注意してください。繰り返しますが、-vフラグと-Pフラグを意図的に使用せず、詳細な出力が必要な場合は追加してください。
rsync を使用します。SSHを使用します。
使用法：
rsync -aPz /source/path destination.server:remote/path
Rsyncスイッチは、圧縮とIノード情報を扱います。 -Pは、すべてのファイルの進行状況を表示します。
scp -Cを使用して圧縮を有効にすることができますが、可能であればrsyncを使用してください。
Sshを使用して、両端でtarを実行できます。 scpはsshファミリーの良さの一部なので、おそらく両端にあります。
8:03AM 12 % tar cf - some_directory | ssh dest_Host "tar xf -"
Gzipまたはbzip2をパイプラインに組み込んでネットワークトラフィックを減らす方法もあるかもしれません。
@pdoの答えは適切ですが、バッファと適切な圧縮を使用して速度を上げ、進行状況バーを追加できます。
多くの場合、ネットワークがボトルネックであり、速度は時間とともに変化します。したがって、ネットワーク経由で送信する前にデータをバッファリングすると役立ちます。これはpvで実行できます。
さらに、通常は適切な圧縮アルゴリズムを使用して速度を上げることができます。 Gzip（上記で使用したものと同様）は高速圧縮アルゴリズムですが、一般的にzstandard（zstd）（および高い圧縮率の場合、LZMA/LZMA2（xz）は、より適切に圧縮され、同じ時間で高速になります。新しいxzとzstdにはマルチコアのサポートが組み込まれています。複数のコアでgzipを使用するには、pigzを使用できます。
ネットワーク経由でプログレスバー、バッファリング、およびzstandard圧縮を使用してデータを送信する例を次に示します。
tar cf - . | pv -perabs $(du -sk . | cut -f 1)K | zstd -14 --long=31 -T0 | pv -qCB 512M | ssh user@Host "cd /wherever && pv -qCB 512M | zstd -cd -T0 --long=31 | tar xf -"
最初のpvは、進行状況（p）、推定時間（e）、転送速度（ r）、平均レート（a）、合計転送バイト数（b ）。合計サイズはduで推定され、サイズオプションに追加されます（s）。進行状況は圧縮とバッファリングの前に測定されるため、あまり正確ではありませんが、それでも役に立ちます。
zstdは、圧縮設定14で使用されます。この数は、ネットワークとCPU速度に応じて増減できます。そのため、zstdはネットワーク速度よりも少し高速です。 Haswell 3.2 GHz CPU14の4つのコアでは、約120 MB /秒の速度が得られます。この例では、ロングモード31（2 GBのウィンドウを使用し、大量のRAMが必要ですが、データベースダンプを圧縮する場合など）が使用されます。 T0オプションは、スレッドの量をコアの数に設定します。これらの設定は、ロングモードとともに多くのメモリを使用することに注意してください。
Zstdの問題は、ほとんどのオペレーティングシステムにバージョン1.3.4以上が同梱されていないことです。このバージョンは、適切なマルチコアと長いサポートに必要です。利用できない場合は、コンパイルして https://github.com/facebook/zstd からmake -j4 && Sudo make installだけでインストールできます。 zstdの代わりに、xzまたはpigzを使用することもできます。 xzは遅いですが、非常にうまく圧縮されます（遅い接続では良好です）、pigz/gzipは高速ですが、あまり圧縮されません。次にpvが再び使用されますが、バッファリング（qはクワイエット、Cはスプライスなしモード[常にバッファリングに必要]、Bはバッファサイズ）。
この例では、受信側でもバッファが使用されています。多くの場合、これは不要です（解凍とハードディスクへの書き込み速度はほとんどの場合ネットワーク速度よりも速いため）が、害はありません。
両端にgzipがある場合：sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh user@destinationhost "cd destinationdir && gzip -c -d | tar xf -"
ソースマシンにgzipがない場合は、宛先で圧縮解除していることを確認してください：sourcehost$ cd sourcedir && tar cf - . | compress | ssh user@destinationhost "cd destdir && uncompress | tar xf -"
これは、最初に圧縮してから送信してから解凍するよりも速く、どちら側にも追加のディスク領域は必要ありません。私はtarの圧縮（z）フラグを省略しました。これは、おそらく古代ではそれがなかったためです。
または、必要に応じて逆に行うこともできます。これは、提案されているようにPush itではなく、ネットワーク上でtarballをプルすることです。これはあなたの質問の繰り返し部分を解決しません、そしてrsyncはそのために最善ですが、おそらく助けとなるtarスイッチがあります。
ローカルマシン上で：
ssh remote 'tar zcf - /etc/resolv.conf' | tar zxf -
最初に正しいディレクトリにあるか、最後にuntaringコマンドで-Cスイッチを使用するのが最善です。
これが必要な場合に備えて、これについて言及します。私の状況では私のローカルサーバーがNATの背後にあるので、以前に述べた方法でそれを実行できるようにするには、ネットワークの混乱が必要です。
HTH
または、sshfsを介してリモートファイルシステムをマウントします
sshfs user@remotehost:/path/on/remote /path/on/local
最もエレガントではありませんが、特に1つのZipファイルまたはtarファイルをコピーするのではなく、ネットワークのオーバーヘッドを減らすのに役立たないため、二重にコピーするため、scp -rを使用するしかありませんでした。
-rソース： scp（1）
ディレクトリ全体を再帰的にコピーします。
scpは、ツリートラバーサルで検出されたシンボリックリンクを追跡することに注意してください。
30 GBのzip圧縮されたtarファイルでディスク領域が不足するという問題が発生していました。 gunzipはインラインで実行できると考えていました。つまり、unzipされていたのでオリジナルを削除しました（Googleの検索結果を見逃した可能性があります）が、何も見つかりませんでした。
最後に、新しいTARまたはZipファイルのtar圧縮または圧縮が完了するのを待つのに何度も試すのにうんざりしていたので、ようやく次のようにしました。
- 元のサーバー/ PC /ラップトップから、多数のファイル/フォルダーを含むフォルダーがあるディレクトリに移動します。
scp -r source_folder_nameyourname@yourservername:destination_folder_name
その後、ビール、コーヒー、ポップコーンを手に取り、お待ちください。良い点は、ネットワーク接続が「ストール」した場合、scpが再試行することです。完全に下がらないことを願っています。