it-swarm-eu.dev

Jak mohu nejlépe zkopírovat velké množství malých souborů přes SCP?

Mám adresář, který má několik gigabajtů a několik tisíc malých souborů. Chci jej zkopírovat přes síť s scp více než jednou. Čas procesoru na zdrojovém a cílovém počítači je levný, ale režijní náklady na síť přidané zkopírováním každého souboru jednotlivě jsou obrovské. Chtěl bych to dechovat/gzipovat a dodávat, ale zdrojový stroj je na disku krátký.

Existuje způsob, jak mi dát výstup z tar -czf <output> <directory> scp? Pokud ne, existuje jiné snadné řešení? Můj zdrojový stroj je starodávný (SunOS), takže bych raději nechtěl na něj instalovat věci.

63
nmichaels

Můžete rouru dehtu přes ssh relace:

$ tar czf - <files> | ssh [email protected] "cd /wherever && tar xvzf -"
110
pdo

Decht s kompresí bzip2 by měl mít stejnou zátěž ze sítě a na procesoru.

$ tar -C /path/to/src/dir -jcf - ./ | ssh [email protected] 'tar -C /path/to/dest/dir -jxf -'

Nepoužívám -v protože výstup obrazovky může proces zpomalit. Ale pokud chcete podrobný výstup, použijte jej na místní straně dehtu (-jcvf), nikoli na vzdálené části.

Pokud opakovaně kopírujete přes stejnou cílovou cestu, například aktualizujete záložní kopii, nejlepší volbou je rsync s kompresí.

$ rsync -az -e ssh /path/to/src/dir/ [email protected]:/path/to/dest/dir/

Všimněte si, že cesty src a dest končí koncem /. Opět nepoužíváme -v a -P příznaky úmyslně, přidejte je, pokud potřebujete podrobný výstup.

23
forcefsck

použijte rsync , používá SSH.

Používání:

rsync -aPz /source/path destination.server:remote/path

Přepínače rsync se starají o kompresi a informace o uzlu I-Node. -P zobrazuje průběh každého souboru.

Můžeš použít scp -C, což umožňuje kompresi, ale pokud je to možné, použijte rsync.

16
polemon

Pomocí ssh můžete spustit tar na obou koncích. scp je součástí rodiny dobroty ssh, takže ji pravděpodobně máte na obou koncích.

 8:03AM 12 % tar cf - some_directory | ssh dest_Host "tar xf -"

Může existovat způsob, jak do potrubí zapojit gzip nebo bzip2, aby se také snížil síťový provoz.

3
Bruce Ediger

Odpověď @ pdo je dobrá, ale lze zvýšit rychlost pomocí vyrovnávací paměti a dobré komprese a přidat ukazatel průběhu.

Síť je často překážkou a rychlost se v průběhu času mění. Pomáhá tedy ukládat data do vyrovnávací paměti před jejich odesláním přes síť. To lze provést pomocí pv.

Navíc lze obvykle zvýšit rychlost pomocí správného kompresního algoritmu. Gzip (podobně jako výše) je algoritmus rychlé komprese, ale obecně zstandard (zstd) (a pro vysoké kompresní poměry bude LZMA/LZMA2 (xz) komprimovat lépe a rychlejší ve stejnou dobu Nové xz a zstd mají již zabudovanou vícejádrovou podporu. Pro použití gzipu s více jádry lze použít pigz.

Zde je příklad odesílání dat pomocí ukazatele průběhu, vyrovnávací paměti a zstandardní komprese přes síť:

tar cf - . | pv -perabs $(du -sk . | cut -f 1)K | zstd -14 --long=31 -T0 | pv -qCB 512M | ssh [email protected] "cd /wherever && pv -qCB 512M | zstd -cd -T0 --long=31 | tar xf -"

Prvním pv je ukázat průběh ( p ), odhadovaný čas ( e ), přenosová rychlost ( r ), průměrná rychlost ( a ), celkový počet přenesených bytů ( b ). Celková velikost se odhadne pomocí du a přidá se k možnosti velikosti ( s ). Průběh se měří před kompresí a ukládání do vyrovnávací paměti, proto není příliš přesný, ale stále užitečný.

zstd se používá s nastavením komprese 14 . Toto číslo lze snížit nebo zvýšit v závislosti na rychlosti sítě a procesoru, takže zstd je o něco rychlejší než rychlost sítě. Se čtyřmi jádry na Haswell 3,2 GHz CPU 14 dává rychlost kolem 120 MB/s. V příkladu je použit dlouhý režim 31 (používá 2 GB okno, potřebuje hodně RAM, ale velmi dobré např. Pro komprimaci výpisů z databáze) . Možnosti T0 nastavují počet vláken na počet jader. Je třeba si uvědomit, že tato nastavení spolu s dlouhým režimem využívají spoustu paměti.

Problém se zstd je v tom, že většina operačních systémů se nedodává s verzí> = 1.3.4. Tato verze je nezbytná pro správnou vícejádrovou a dlouhou podporu. Pokud není k dispozici, lze jej zkompilovat a nainstalovat z https://github.com/facebook/zstd s pouhým make -j4 && Sudo make install. Místo zstd lze také použít xz nebo pigz. xz je pomalý, ale komprimuje se velmi dobře (dobré přes pomalé připojení), pigz/gzip je rychlý, ale komprimuje ne tak dobře. pv se poté použije znovu, ale pro vyrovnávací paměť (q pro tichý, C pro režim bez spojování [vždy nutné pro vyrovnávací paměť] a B pro nastavení velikost vyrovnávací paměti).

V příkladu je také použita vyrovnávací paměť na straně přijímače. To je často zbytečné (protože dekomprese a rychlost zápisu na pevný disk je většinou vyšší než rychlost sítě), ale obvykle to také nepoškodí.

3
Fabian Heller

Pokud máte gzip na obou koncích: sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh [email protected] "cd destinationdir && gzip -c -d | tar xf -"

Pokud na zdrojovém počítači nemáte gzip, ujistěte se, že máte v cíli dekomprimaci: sourcehost$ cd sourcedir && tar cf - . | compress | ssh [email protected] "cd destdir && uncompress | tar xf -"

To by bylo rychlejší než první zips, pak odeslání, pak rozbalení, a to nevyžaduje žádné další místo na disku na obou stranách. Sikpoval jsem kompresní (z) vlajku na dehtu, protože ji pravděpodobně nemáte na starodávné straně.

2
MattBianco

Nebo to můžete udělat opačně, pokud potřebujete. To je táhnout tarball přes síť spíše než Push to, jak bylo navrženo. To nevyřeší opakující se část vaší otázky a rsync je pro to nejlepší, ale pravděpodobně existuje pomocný přepínač dehtu.

Takže na místním počítači:

ssh remote 'tar zcf - /etc/resolv.conf' | tar zxf -

Nejlepší je být nejprve ve správném adresáři nebo musíte použít přepínač -C na příkazu untaring na konci.

Jen to zmíním v případě, že je to potřeba. Je to pro mě, protože v mé situaci je můj místní server za natem, takže by to trvalo nějakou síťovou mučivost, abych to dokázal tak, jak bylo dříve zmíněno.

HTH

2
DaveQB

Nebo připojte vzdálený souborový systém pomocí sshfs

sshfs [email protected]:/path/on/remote /path/on/local
1
ivanivan

I když to není nejelegantnější, zejména proto, že se nejedná o kopírování jediného souboru ZIP nebo dehtu a dvojnásobně, protože to nepomůže snížit režijní náklady na síť, moje jediná volba byla použít scp -r:

-r

      Rekurzivně kopírovat celé adresáře. Všimněte si, že scpfollows symbolické odkazy narazil ve stromovém průchodu.
Zdroj: scp (1)

Setkal jsem se s problémy s nedostatkem místa na disku se souborem dehtu se zipem 30 GB. Myslel jsem, že gunzip to dokáže inline, tj. Odstraní originál, protože byl rozbalen (a možná jsem vynechal výsledek Google), ale nic jsem nenašel.

Nakonec, protože mě nebavilo zkoušet několikrát čekat, až bude dokončen nový soubor TAR nebo Zip, decht nebo zip, nakonec jsem to udělal:

  1. Z původního serveru/počítače/notebooku přejděte do adresáře, ve kterém je složka s mnoha soubory/složkami.
  2. scp -r source_folder_nameyourname@yourservername:destination_folder_name

Pak jen uchopte nějaké pivo, kávu nebo popcorn a počkejte. Dobrá věc je, scp se bude opakovat, pokud se síťové připojení „zastaví“. Jen doufám, že to úplně neklesne.

1
JGlass