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

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?

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

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 -)

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.

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.

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.

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.

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

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.

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

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.

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.

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.

Oba będą działać dobrze.

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

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.

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)