rsync przez VPN: nowa próba, która wykorzystuje przerwany transfer
Zerwany tunel kończy połączenie, a nie dane. Zachowaj fragment z --partial-dir, uruchom ponownie tę samą kopię i zweryfikuj plik przed publikacją.
Twoje wysyłanie zatrzymuje się na czterech gigabajtach z dwunastogigabajtowego archiwum, a nawyk wyniesiony z menedżerów pobierania mówi, żeby nacisnąć wznów. rsync nie wznowi strumienia TCP, bo ten strumień zniknął wraz z ostatnią retransmisją tunelu. Może natomiast zachować już odebrane bajty i użyć ich jako podstawy następnej próby, co jest innym mechanizmem z innym zestawem reguł. Wybrane flagi decydują, czy to ponowne użycie w ogóle nastąpi.
Nowa próba odbudowuje stan, nie wznawia strumienia
Gdy sesja SSH padnie, po drugiej stronie zostaje tylko to, co udało się zapisać na dysku, i nic więcej. Nie ma tokenu sesji, do którego można by się ponownie przyłączyć, ani numeru sekwencji do odtworzenia. Kolejne uruchomienie otwiera nowe połączenie, ponownie czyta źródło i pyta odbiorcę, co już ma.
Właśnie to ostatnie pytanie wyjaśnia, dlaczego warto zachować częściowy plik. Kopia odbiorcy daje rsyncowi coś do porównania, a algorytm wysyła tylko te różnice, które potrafi rozpoznać. To wciąż nowy transfer metadanych i nowe przejście po źródle, więc zaoszczędzony czas jest proporcjonalny do tego, ile pliku się zgadza, a nie do tego, jak daleko zaszło poprzednie połączenie. Jeśli odbiorca niczego nie zachował, następna próba to pełna kopia, niezależnie od tego, ile gigabajtów przeniósł pierwszy.
Zdecyduj, gdzie mieszka fragment wielokrotnego użytku
Domyślne zachowanie zapisuje plik częściowy pod ścieżką docelową, co sprawia, że na wpół zapisane archiwum jest widoczne pod nazwą końcową. --partial-dir przenosi go do wybranego katalogu, a podręcznik opisuje ten katalog jako zachowany do wykorzystania jako dane przez późniejszy transfer. Nazwa względna jest rozwiązywana w katalogu docelowym, co jest dokładnie tym, czego chcesz, gdy oba końce mogą mieć różne układy.
rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
large-archive.bin [email protected]:/srv/incoming/
Kolejność ma znaczenie także w miejscu docelowym: katalog częściowy potrzebuje dość miejsca na fragment, a wolumen potrzebuje dość miejsca także na ukończony plik. Wypełnienie wolumenu docelowego w połowie transferu daje błąd, który wygląda jak problem sieci, ale nim nie jest, i może pozostawić zachowany fragment ucięty. Sprawdź wolne miejsce na hoście odbierającym przed rozpoczęciem, a nie po niepowodzeniu. Kilka sekund z df -h po tej samej ścieżce SSH to najtańszy możliwy test planu.
Uprawnienia to mniejszy, ale realny problem. Katalog częściowy, w którym mogą pisać niepowiązane konta, pozwala komuś innemu podmienić treść, którą kolejne uruchomienie potraktuje jako już odebraną. Trzymaj go w posiadaniu konta transferowego i nie umieszczaj tam, skąd publikują inne usługi.
Uruchom tę samą kopię, nie mądrzejszą
Ponowne użycie obowiązuje tylko wtedy, gdy źródło i cel nadal opisują ten sam obiekt. Ta sama ścieżka, ta sama nazwa, ten sam plik. Zmiana nazwy źródła lub wskazanie innego katalogu docelowego rozpoczyna nowe porównanie z niczym użytecznym.
Nie dodawaj --whole-file, oczekując zachowania delta. Ta opcja każe rsyncowi kopiować cały plik bez porównania kroczącej sumy kontrolnej, co jest rozsądnym wyborem w szybkim łączu lokalnym i dokładnie złym po nieudanym wysłaniu na dużą odległość. --inplace też zmienia historię: zapisuje bezpośrednio w pliku docelowym, więc przerwanie zostawia plik mieszający starą i nową treść, bez osobnego fragmentu do odwrotu.
Linia postępu podaje łączny postęp transferu. To nie jest sygnał ukończenia. Liczba, która osiąga sto procent, gdy połączenie jest jeszcze otwarte, oznacza, że dane zostały wypchnięte, a nie że odbiorca coś zmienił nazwę, zsynchronizował lub zaakceptował.
Zaakceptuj obiekt dopiero, gdy się zgadza
Najpierw potwierdź status wyjścia, potem porównaj wynik, zamiast polegać na braku błędów. Kontrola rozmiaru wyłapuje większość uciętych transferów; porównanie sum kontrolnych wyłapuje resztę, i oba są tanie w porównaniu z ponownym uruchomieniem wysyłania.
Jeśli archiwum publikuje proces następczy, każ temu procesowi czekać na zaakceptowany plik. Zachowany fragment, który pod nazwą końcową trafi do obserwowanego katalogu, zostanie podchwycony przez następne skanowanie, a błąd odbiorcy będzie dotyczył uszkodzonego wejścia, a nie transferu, który nigdy się nie zakończył.
Nie ruszaj źródła, dopóki odbiorca nie potwierdzi. Ponowne generowanie archiwum między próbami zmienia podstawę porównania, a kolejne uruchomienie albo przenosi prawie wszystko, albo tworzy plik, który nie pasuje ani do starego, ani do nowego źródła.
Gdy granicą jest łącze, a nie flaga
Narzut nagłówka i protokołu jest jednym kosztem transferu i rzadko to on decyduje, ile trwa duży plik. Zachowanie przy ponownym starcie liczy się bardziej: metoda, która przeżywa zerwanie bez ręcznych kroków, dostarcza użyteczny plik wcześniej niż szybsza metoda, którą trzeba zaczynać od nowa. Magazyn po obu stronach i ścieżka uwierzytelniania należą do tego samego porównania.
Porównaj dozwolone ścieżki alternatywne z tym samym plikiem i tym samym celem, i zanotuj, od czego każda z nich wznawia po przerwaniu. Ta jedna kolumna mówi o wysyłaniu dwunastu gigabajtów przez VPN więcej niż jakakolwiek prędkość szczytowa zmierzona w krótkim teście.