Jak zsynchronizować duży plik przy możliwie najmniejszych kosztach procesora i przepustowości?

13

Mam plik 500 GB, którego kopię zapasową planuję zdalnie. Plik często się zmienia. Zsynchronizuję go z pulpitu na serwer. Oba mogą uruchamiać klienta lub serwer rsync.

Jakie jest właściwe polecenie? Te, których wypróbowałem sofar, trwały wiecznie lub po prostu zachowywały się dziwnie.

Przykład i wyniki:

rsync -cv --partial --inplace --no-whole-file /desktop/file1 myserver.com::module/file1

Wydaje się działać, ale tylko jeśli zrobię to dwa razy (?!). Również powoli.

Czy powyższe polecenie wykonuje sumowanie kontrolne na obu komputerach, czy tylko na jednym wysyłającym? Czy inaczej jest poprawne?

rsync

— Johan Allgoth
źródło

Tak duży plik, który często się zmienia? Za pomocą rsync uzyskasz bardzo, bardzo rozczarowujące wyniki ...

— Ignacio Vazquez-Abrams

Jakieś inne sugestie? Powinienem być wykonalny z jakąś aplikacją, zastrzeżony klient Dropbox robi to bardzo dobrze. Zobacz forums.dropbox.com/topic.php?id=17631

— Johan Allgoth

--inplace sugeruje - częściowe patrz: linux.die.net/man/1/rsync

— Ray Hulha

12

To nigdy nie będzie szybkie, ponieważ rsync będzie musiał odczytać / zsumować cały plik, a odczyt 500 GB zajmie dużo czasu, chyba że masz go na dyskach SSD lub coś w tym rodzaju.

Spróbować rsync -vhz --partial --inplace <file/server stuff>.

-coznacza, że sumuje cały plik PRZED wykonaniem jakichkolwiek transferów, zamiast używać znacznika czasu, aby sprawdzić, czy został zmieniony, co oznacza dwukrotne odczytanie całego pliku. Jeśli znacznik czasu nie ulega zmianie (powinien), możesz po prostu touchplik przed uruchomieniem rsync.

Jeśli nie jest to napisane w skrypcie, możesz dodać, --progressaby zobaczyć, jak działa.

— Dentrasi
źródło

Tak, wiem „duży plik == długa obsługa”. Ale czuję, że coś tu brakuje, patrz komentarz powyżej. Jeśli Dropbox może to zrobić, możemy to zrobić! =) Nie powiedziałem, ale próbowałem też bez -c, wciąż powoli.

— Johan Allgoth,

2

--inplaceoznacza również--partial

2

Chociaż nie jest to rsync, w zależności od tego, co próbujesz zrobić, może to działać lepiej. Robiłem podobne zadanie tworzenia kopii zapasowej i było zdecydowanie szybsze.

Użyj netcata, aby utworzyć rurę smołową z jednej maszyny do drugiej.

Na komputerze źródłowym:

tar -cpv --atime-preserve=system . | nc -q 10 -l -p 45454

Tworzysz plik archiwalny, który zachowuje uprawnienia i czas, a następnie przekazujesz go do netcata na porcie 45454

Na komputerze kopii zapasowej

nc -w 10 X.X.X.X 45454 | tar -xpv

X.X.X.X = lokalny adres IP komputera źródłowego.

Dla mnie to działało dobrze. Działał z prędkością 25-30 MB / s przez przewodową sieć LAN, w przeciwieństwie do 2-3 MB / s z rsync. Wadą jest to: nie synchronizuje się, po prostu tworzy kopię tego, co jest w twoim źródle. Jednak w przypadku kopii zapasowej takiej jak opisana - jeden plik 500 GB - może działać bardzo dobrze.

Być może będziesz musiał to zrobić jako root, aby uniknąć problemów z uprawnieniami lub możesz mieć szczęście.

FWIW, początkowo dowiedziałem się o tym tutaj: http://www.screenage.de/blog/2007/12/30/using-netcat-and-tar-for-network-file-transfer/

— SteveLambert
źródło

1

tarjest lepszy niż rsyncwtedy, gdy masz dużo małych plików do przesłania. Użycie ncpoprawia także szybkość transferu w przypadku szybkiego połączenia, ponieważ nie masz narzutu szyfrowania SSH (którego nie potrzebuję w połączeniu peer-to-peer)

— jornane

0

Aby uniknąć obciążenia sieci, użyj protokołu rsync, a nie SSH. Domyślnie rsync używa SSH podczas określania adresu URL, takiego jak nazwa hosta: / ścieżka. Zamiast tego użyj szybszego protokołu rsync, używając rsync: // nazwa_hosta / ścieżka. W ten sposób nie są potrzebne żadne sztuczki z tar / netcat. Algorytm rsync delta powinien być znacznie szybszy.

Zobacz także https://gergap.wordpress.com/tag/rsync/, aby uzyskać więcej informacji.

— Gergap
źródło