Kopiujesz lokalnie duże drzewo katalogów? cp czy rsync?

230

Muszę skopiować duże drzewo katalogów, około 1,8 TB. Wszystko jest lokalne. Z przyzwyczajenia korzystałbym rsync, jednak zastanawiam się, czy ma to sens i czy raczej powinienem użyć cp.

Martwię się o uprawnienia i identyfikator uid / gid, ponieważ muszą one zostać zachowane w kopii (wiem, że rsync to robi). A także rzeczy takie jak dowiązania symboliczne.

Miejsce docelowe jest puste, więc nie muszę się martwić o warunkową aktualizację niektórych plików. To wszystko dysk lokalny, więc nie muszę się martwić o ssh ani sieć.

Powodem, dla którego chciałbym się oderwać od rsync, jest to, że rsync może zrobić więcej, niż potrzebuję. Pliki sum kontrolnych rsync. Nie potrzebuję tego i martwię się, że może to potrwać dłużej niż CP.

Więc co o tym myślisz, rsyncalbo cp?

Rory
źródło
2
Jeśli rsync robi dokładnie to, co chcesz, jeśli znasz już jego użycie w tej konkretnej aplikacji, a jeśli działa wystarczająco szybko, aby dopasować się do Twojego gustu, to dlaczego, u licha, miałbyś chcieć to zmienić?
jedenaście81
2
Ponieważ martwię się, że rsync zajmie więcej czasu niż cp, ponieważ rsync wykonuje wiele sprawdzeń, których cp nie zrobi
Rory
1
Narzut procesora sumy kontrolnej jest niewielki w porównaniu do operacji we / wy na dysku / sieci. Chyba że dysk znajduje się w tym samym systemie, a system operacyjny może wykonać sprytną kopię dysku w kontrolerze magistrali.
Martin Beckett,
3
Sumowanie kontrolne odbywa się na plikach, które różnią się rozmiarem i znacznikiem czasu. Jeśli jesteś paranoikiem (np. Po przerwie w zasilaniu podczas kopiowania), możesz wymusić sumowanie kontrolne na wszystkich plikach, ale przy lokalnym przesyłaniu, zwykle jest to wolniejsze niż rozpoczynanie od zera.
korkman
3
Może jest ciekawy usprawnienia pracy i nie chowa głowy w piasek, myśląc, że wie wszystko. Ten komentarz naprawdę mnie denerwuje.
Martin Konecny

Odpowiedzi:

204

Użyłbym rsync, ponieważ oznacza to, że jeśli zostanie przerwane z jakiegokolwiek powodu, możesz go łatwo zrestartować przy bardzo niskim koszcie. Ponieważ jest rsync, może nawet częściowo zrestartować duży plik. Jak wspominają inni, może łatwo wykluczyć pliki. Najprostszym sposobem na zachowanie większości rzeczy jest użycie -aflagi - „archiwum”. Więc:

rsync -a source dest

Chociaż identyfikatory UID / GID i dowiązania symboliczne są przechowywane przez -a(patrz -lpgo), twoje pytanie sugeruje, że możesz potrzebować pełnej kopii informacji o systemie plików; i -anie obejmuje twardych dowiązań, rozszerzonych atrybutów lub list ACL (w systemie Linux) ani powyższych ani widelców zasobów (w systemie OS X). Zatem, aby uzyskać solidną kopię systemu plików, musisz uwzględnić te flagi:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

Domyślne cp uruchomi się ponownie, chociaż -uflaga zostanie „skopiowana tylko wtedy, gdy plik SOURCE jest nowszy niż plik docelowy lub gdy brakuje pliku docelowego” . A -aflaga (archiwum) będzie rekurencyjna, nie będzie kopiować plików, jeśli będziesz musiał zrestartować i zachować uprawnienia. Więc:

cp -au source dest
Hamish Downer
źródło
5
Flaga -u cp prawdopodobnie nie jest najlepszym rozwiązaniem, ponieważ nie wykryłaby częściowo skopiowanego / uszkodzonego pliku. Zaletą rsync jest to, że md5 sumuje pliki w celu wykrycia różnic.
Chad Huneycutt
3
Dodanie opcji -w (--whole-file) przyspieszy przerwany rsync, ponieważ po prostu skopiuje plik zamiast sprawdzania.
hayalci
13
w rzeczywistości rsync wykrywa lokalne transfery i umożliwia kopiowanie całego pliku bez automatycznego sumowania.
korkman
22
i - postęp, który jest naprawdę przydatny!
Mat.
12
-P lub --progress pokazuje postęp dla każdego pliku osobno. Jest to przydatne do kopiowania dużych plików, a nie wielu (tysięcy) małych plików, ponieważ oznacza o wiele więcej danych wyjściowych, których nie można odczytać. Nie pokazuje całkowitego postępu wszystkich plików łącznie.
SPRBRN,
106

Podczas kopiowania do lokalnego systemu plików zawsze używam następujących opcji rsync:

# rsync -avhW --no-compress --progress /src/ /dst/

Oto moje rozumowanie:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

Widziałem 17% szybsze transfery przy użyciu powyższych ustawień rsync za pomocą następującego polecenia tar, jak sugeruje inna odpowiedź:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
Ellis Percival
źródło
1
rsync: --no-compress: unknown optionWystąpił następujący błąd: @Ellis Percival.
alper
To błyskawicznie. Szybciej to zrobić niż rm -rf /src/.
dgo
2
Podobnie jak @alper, --no-compress nie był opcją dla mojej wersji rsync (w CentOS 7); Zamiast tego użyłem --compress-level = 0.
Paul
79

Kiedy muszę skopiować dużą ilość danych, zwykle używam kombinacji tar i rsync. Pierwszym krokiem jest tarowanie go, coś takiego:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Zwykle przy dużej liczbie plików, niektóre z nich nie będą w stanie obsłużyć tar z jakiegokolwiek powodu. A może proces zostanie przerwany lub jeśli jest to migracja systemu plików, możesz chcieć wykonać wstępną kopię przed faktycznym krokiem migracji. W każdym razie po początkowej kopii wykonuję krok rsync, aby zsynchronizować wszystko:

# cd /dst; rsync -avPHSx --delete /src/ .

Pamiętaj, że końcowy ukośnik /src/jest ważny.

Chad Huneycutt
źródło
6
+1 Odkryłem, że tar jest generalnie szybszy dla dużych kopii niż rsync. Podoba mi się też pomysł ukończenia z końcowym rsync.
Geoff Fritz
2
tar jest dobrym wyborem, jeśli katalog docelowy jest pusty. Chociaż moją drogą byłoby: cd $ DSTDIR; tar c -C $ SRCDIR. | tar
asdmin
19
To jest piękno tej metody. Nie potrzebujesz podwójnej przestrzeni, ponieważ tak naprawdę nigdy nie tworzysz pośredniego pliku tar. Smoła przed potokiem pakuje dane i przesyła je strumieniowo na standardowe wyjście, a smoła po potoku pobiera je ze standardowego wejścia i rozpakowuje.
Chad Huneycutt
4
Zrobiłem cp -a dla transferu 12 GB, a ta metoda dla transferu 42 GB. Metoda smoły zajęła około 1/4 czasu.
NGaida
3
Umieściłem również pvw środku, aby móc obserwować postęp, szacując rozmiar wszystkich używanych danych df. Użyłem również --numeric-owner, ponieważ dysk źródłowy był z innego systemu i nie chciałem tarbałaganić właścicieli:tar -C /old-path --numeric-owner -S -c . | pv -tpeba -s 100G | tar -C /new-path --numeric-owner -S -xp
Petr Pudlák
14

rsync

Oto rsync, którego używam, wolę cp dla prostych poleceń, a nie to.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

CPIO

Oto sposób, który jest jeszcze bezpieczniejszy, CPIO. Jest tak szybki jak smoła, może trochę szybciej.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

smoła

Jest to również dobre i trwa w przypadku błędów odczytu.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

Pamiętaj, że wszystkie są tylko dla lokalnych kopii.

AskApache
źródło
Dlaczego używasz flag -S i -D dla rsync?
miyalys,
7

Cokolwiek wolisz. Po prostu nie zapomnij o -aprzełączniku, kiedy zdecydujesz się użyć cp.

Jeśli naprawdę potrzebujesz odpowiedzi: użyłbym rsync, ponieważ jest on znacznie bardziej elastyczny. Potrzebujesz zamknąć przed zakończeniem kopiowania? Po prostu ctrl-c i wznów jak tylko wrócisz. Chcesz wykluczyć niektóre pliki? Po prostu użyj --exclude-from. Chcesz zmienić własność lub uprawnienia? rsync zrobi to za ciebie.

innaM
źródło
Co robi flaga -p ponownie?
Rory,
1
Będzie to własność Preserver, znaczniki czasu i uprawnienia.
innaM
5
cp -a byłoby lepsze.
David Pashley,
W rzeczy samej. Odpowiedź zmieniła się odpowiednio.
innaM
7

rsyncKomenda zawsze oblicza sumy kontrolne na każdy bajt to transferów.

Opcja wiersza poleceń --checksumdotyczy tylko tego, czy sumy kontrolne plików są używane do określenia, które pliki mają zostać przesłane, tj .:

-c, --checksum pomiń na podstawie sumy kontrolnej, a nie czasu modyfikacji i rozmiaru ”

Strona ta mówi również:

Zauważ, że rsync zawsze sprawdza, czy każdy przesłany plik został poprawnie zrekonstruowany po stronie odbierającej, sprawdzając sumę kontrolną całego pliku, ale że automatyczna weryfikacja po przesłaniu nie ma nic wspólnego z tą opcją przed przesłaniem. ”Czy ten plik potrzebuje do zaktualizowania?" czek.

Tak więc rsynczawsze oblicza sumę kontrolną całego pliku po stronie odbierającej, nawet gdy -c/ --checksumopcja jest wyłączona.

Jan
źródło
14
Podczas gdy twój post dodał tutaj kilka interesujących informacji, rant i obelgi zmniejszają wartość twojego postu. Ta strona nie jest forum dla niekonstruktywnych rantów. Jeśli byłeś w stanie zmodyfikować źródło, czy przesłałeś swoje modyfikacje jako łatkę? Czy zamieściłeś swoją wersję na github? Jeśli czujesz się tak mocno w tej sprawie, może być lepiej, jeśli spróbujesz zrobić coś bardziej konstruktywnego zamiast niepotrzebnie obrażać.
Zoredache
Tak, ostatni akapit nie był tak naprawdę konieczny.
Sherwin Flight,
6

rsync -aPhW --protocol=28pomaga przyspieszyć te duże kopie dzięki RSYNC. Zawsze używam rsync, ponieważ myśl o byciu w połowie 90GiB i łamanie go odstrasza mnie od CP

oneguynick
źródło
2
Jaka jest wartość używania starszego protokołu w tym ciągu poleceń?
ewwhite
1
Na komputerze Mac starsza wersja dostarczonego Rsync zawiesza się na niektórych nowszych wersjach protokołu rsync, takich jak 29. Polecenie przejścia do starszego protokołu powoduje, że NIE sprawdza się od nowa.
oneguynick
Myślę, że liczba 28 już nie jest ważna?
SPRBRN,
5

rsync jest świetny, ale ma problemy z naprawdę dużymi drzewami katalogów, ponieważ przechowuje drzewa w pamięci. Chciałem tylko sprawdzić, czy naprawią ten problem, gdy znajdę ten wątek.

Znalazłem też:

http://matthew.mceachen.us/geek/gigasync/

Możesz także ręcznie rozbić drzewo i uruchomić wiele rsyncs.

n3bulous
źródło
12
Jeśli używasz wersji 3, nie zachowuje ona całego drzewa w pamięci, jeśli jest duże, używa algorytmu przyrostowej rekurencji: samba.org/ftp/rsync/src/rsync-3.0.0-NEWS
Kyle Brandt
5

Ten wątek był bardzo przydatny, a ponieważ było tak wiele opcji, aby osiągnąć wynik, postanowiłem przetestować kilka z nich. Wierzę, że moje wyniki mogą być pomocne dla innych, którzy mają pojęcie o tym, co działało szybciej.

Aby przenieść 532 GB danych rozproszonych między 1753200 plików , mieliśmy te czasy:

  • rsync zajęło 232 minuty
  • tar zajęło 206 minut
  • cpio zajęło 225 minut
  • rsync + parallel zajęło 209 minut

W moim przypadku wolałem używać rsync + parallel. Mam nadzieję, że te informacje pomogą większej liczbie osób zdecydować się na te alternatywy.

Pełny test porównawczy został opublikowany tutaj

arjones
źródło
Nie znaleziono 404 strony
Amedee Van Gasse
1
Dzięki @AmedeeVanGasse URL został naprawiony krótko po tym, jak zgłosiłeś :)
arjones
Dlaczego nie benchmarking cp? To jest tytuł pytania!
calandoa
@calandoa Myślę, że cpjest niepewny, tj .: kiedy się psuje, musisz zacząć od nowa, w ten sposób faworyzuję opcje, które można wznowić, ergo rsyncjest moim ulubionym :)
arjones
3

Kiedy robię lokalną kopię katalogu lokalnego, mam doświadczenie, że „cp -van src dest” jest o 20% szybszy niż rsync. Jeśli chodzi o możliwość ponownego uruchomienia, to właśnie to robi „-n”. Wystarczy tylko częściowo skopiować skopiowany plik. Nie bolesne, chyba że jest to ISO lub coś takiego.

Ron
źródło
2

ARJ TO TAKIE STARE SZKOŁA !! Naprawdę wątpię, aby ARJ i / lub rsync dały wydajność.

Zdecydowanie zawsze używam cpio:

find . -print | cpio -pdm /target/folder

Jest to prawie szybkie niż CP, zdecydowanie szybsze niż smoła i bez robienia czegokolwiek.

Gonzalo Gorosito
źródło
2
„Oryginalne narzędzie cpio i narzędzia do znajdowania zostały napisane przez Dicka Haighta podczas pracy w Unix Support Group AT&T. Po raz pierwszy pojawiły się w 1977 roku w PWB / UNIX 1.0” - strona podręcznika FreeBSD cpio.
Chris S
3
cpioniestety ma górny limit 8 GB na pliki.
bez robienia czegokolwiek ” [sic]. Z wyjątkiem findpolecenia, które zostało wymienione, ma w nim rurkę:find . -print | cpio -pdm /target/folder
warren
1

Zdecydowanie chcesz wypróbować rclone . To jest szalone szybko:

sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Jest to lokalna kopia zi na dysk SSD LITEONIT LCS-256 (256 GB).

Możesz dodać --ignore-checksumprzy pierwszym uruchomieniu, aby był jeszcze szybszy.

Frédéric N.
źródło
0

Oba będą działać dobrze.

Pauska
źródło
0

tar wykonałby to zadanie, ale nie wznowiłby przerywania, tak jak rsync.

pgs
źródło
Stara odpowiedź, ale czy TAR nie służy do tworzenia skompresowanych archiwów plików? Jak można go używać do przesyłania plików takich jak rsync lub cp?
Sherwin Flight,
@SherwinFlight źródło cd; tar cf -. | (cd dest; tar xf -)
pgs
0

Co się stanie, jeśli użyjesz ARJ?

arj a -jm -m1 -r -je filepack /source

gdzie -jm -m1są poziomy kompresji i -jesprawia, że ​​jest to plik wykonywalny. Teraz masz zamknięty pakiet plików.

Następnie w celu wyodrębnienia do mapy docelowej

filepack -y  

gdzie zostanie utworzona mapa źródłowa (gdzie -yzawsze jest akceptacja, nadpisywanie, pomijanie itp.)

Następnie można scp ftp plik pakietu do obszaru docelowego i wykonać go, jeśli to możliwe.

herauthon
źródło
1
Arj? Czy to nie wymarło w latach 80-tych?
Michael Hampton
może wczesne lata 90-te, jeśli wierzysz w wikipedię
Matt
0

Istnieje kilka przyspieszeń, które można zastosować do rsync:

Uniknąć

  • -z--compressKompresja / : spowoduje obciążenie tylko procesora, ponieważ transfer nie odbywa się przez sieć, ale przez pamięć RAM.
  • --append-verify: wznowić przerwany transfer. To brzmi jak dobry pomysł, ale ma niebezpieczny przypadek awarii: każdy plik docelowy o tym samym rozmiarze (lub większym) niż źródło zostanie Zignorowany. Ponadto sumuje na koniec cały plik, co oznacza brak znaczącego przyspieszenia --no-whole-filepodczas dodawania niebezpiecznego przypadku awarii.

Posługiwać się

  • -S/ --sparse: zamienia sekwencje zer na rzadkie bloki
  • --partiallub -Pktóry jest --partial --progress: zapisz częściowo przesłane pliki do przyszłego wznowienia. Uwaga: pliki nie będą miały nazwy tymczasowej, więc upewnij się, że nic innego nie oczekuje na użycie miejsca docelowego, dopóki cała kopia nie zostanie ukończona.
  • --no-whole-filewięc wszystko, co musi zostać wysłane ponownie, wykorzystuje transfer delta. Odczytywanie połowy częściowo przesłanego pliku jest często znacznie szybsze niż ponowne zapisywanie.
  • --inplace aby uniknąć kopiowania plików (ale tylko wtedy, gdy nic nie czyta miejsca docelowego, dopóki cały transfer nie zostanie zakończony)
Tom Hale
źródło