rsync ciągle się rozłącza: uszkodzona rura

Używam rsyncdo wykonania kopii zapasowej mojego katalogu domowego. Od dawna działa dobrze. Oto polecenie, którego używam:

rsync \
    -pavz \
    --delete \
    --exclude 'mnt/' \
    --exclude '.cache/' \
    --exclude 'Videos/' \
    --exclude 'Music/' \
    --exclude 'Documents/virtualbox' \
    /home/"${USER}" "${server}":"${dir}" 2>> "${errorFile}"

Jednak przełączyłem serwer, na którym tworzę kopię zapasową, a teraz się rsyncuruchamia i działa przez kilka sekund (do kilku minut), ale potem zatrzymuje się z komunikatem o błędzie

packet_write_wait: Connection to x.x.x.x: Broken pipe
rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.1]

Ponieważ działa na innych serwerach, podejrzewam, że problemem jest połączenie lub sam serwer. Połączenie wydaje się być stabilne. Jestem połączony kablem i nie widzę żadnych zakłóceń. Próbowałem również pingować serwer podczas tworzenia kopii zapasowej. Ping ma wskaźnik odpowiedzi 100%, nawet gdy kopia zapasowa się rozpada.

Używam kerberosdo uwierzytelnienia na zdalnym serwerze.

Próbowałem kilka kombinacji z ServerAliveInterval, ServerAliveCountMaxlub ClientAliveIntervalw moim ~/.ssh/config, ale bezskutecznie.

Możliwe, że rsyncz jakiegoś powodu na serwerze działa coś, co zabija polecenie, ale nie wiem, jak to zbadać. Jakieś pomysły?

Twoim problemem może być (brak) pamięci. Kiedy 1 GB był duży dla serwera, rsync nie działał na mnie w przypadku dużych zestawów danych. Być może algorytm poprawił pojemność pamięci, ale nie widziałem tego problemu od około 8 lat. Tak naprawdę to jest strzał z zewnątrz, ale warto go zbadać. Najpierw wypróbuj mniejsze zestawy danych. Możesz także spróbować - jako formularz kontroli poczytalności - wykonać tar-tar:

tar cf - $HOME | ssh ${server} tar xf -

Jeśli to również zawiedzie po kilku minutach, to nie jest pamięć.

Spotkałem się z tym również rsyncw przeszłości. Rozwiązaniem, które go naprawiło, było uruchomienie go z screensesji, co pomogło utrzymać połączenie ze zdalnym serwerem.

screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session

Możesz sprawdzić status, uruchamiając screen -x rsync(lub cokolwiek zdecydujesz nazwać sesję, jeśli nadasz jej nazwę, która nie jest wymagana). Spowoduje to ponowne dołączenie bieżącej powłoki do tej sesji. Pamiętaj tylko, aby odłączyć go ponownie po sprawdzeniu stanu, aby działał w tle.

Możesz także wykonać polecenie uruchomienia screenw tle za jednym zamachem, wykonując [ktoś, proszę, popraw mnie, jeśli się mylę] screen -dm 'command'. Możesz man screenspróbować przed tym ostatnim.

EDYTOWAĆ:

Edytuję moją odpowiedź, ponieważ potwierdziłeś, że screennie ma żadnej pomocy w tym scenariuszu, ale odpowiedziałeś na mój komentarz sugerując, aby spróbować scpzobaczyć, jakie wyniki uzyskasz, na co odpowiedziałeś, że dość dziwnie, zadziałało dobrze.

Więc moja nowa odpowiedź brzmi: użyj scp- lub ssh(z tar) - zamiastrsync

To prawda, scpnie obsługuje ogromną liczbę funkcji, jak rsync, ale trzeba faktycznie być zaskoczony, aby dowiedzieć się, jak wiele możliwości, że ma wsparcie, które są niemal identyczne do tego z rsync.

Prawdziwe scenariusze scpi inne alternatywy dla rsync:

Jakiś czas temu miałem za zadanie utworzyć skrypt powłoki, który pobierał dzienniki z naszych serwerów produkcyjnych i przechowywał je lokalnie na serwerze WWW, aby programiści mieli do nich dostęp w celu rozwiązywania problemów. Po bezskutecznych próbach zmuszenia zespołu Unixa do zainstalowania rsyncna naszych serwerach, wymyśliłem obejście, scpktóre działa równie dobrze.

To powiedziawszy, niedawno zmodyfikowałem skrypt, tak aby wszystko, czego używa, to sshi tar- GNU tar/ gtar, a dokładnie. GNU tarobsługuje wiele opcji, które można odnaleźć w rzeczywistości rsync, takich jak --include, --excludezezwolenie / konserwatorskich atrybut, kompresja itp

Sposób, w jaki teraz to sshosiągam, to połączenie z serwerem zdalnym (za pomocą uwierzytelniania pubkey) i użycie gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- zapisuje wszystkie informacje stdout, które są następnie przekazywane lokalnie, aby tar -xzfżadne zmiany nie były dokonywane na zdalnym serwerze produkcyjnym , i wszystkie pliki ściągnięte na serwer lokalny w stanie, w jakim się znajdują. To świetna alternatywa dla rsynctego przypadku. Jedyną ważną rzeczą, tarani scpwsparcie, ani wsparcie nie są przyrostowe kopie zapasowe i poziom kontroli błędów na poziomie bloku, które rsyncfunkcje.

Pełne polecenie, o którym mówię podczas używania sshi tarbyłoby coś takiego (zdalne to Solaris 10; lokalne to Debian, za ile jest warte):

cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz

W twoim scenariuszu byłoby odwrotnie - tar -cf -lokalnie i potokowo do zdalnego serwera przez ssh user@remotehost "tar -xf -"- istnieje inna odpowiedź, która odwołuje się do tego rodzaju zachowania, ale nie zawiera zbyt wielu szczegółów.

Jest kilka innych opcji, które podałem, aby przyspieszyć. Nieustannie mierzyłem wszystko, aby czas wykonania był jak najkrótszy. Można by pomyśleć, że użycie kompresji tarbyłoby bezcelowe, ale tak naprawdę przyspiesza to trochę, podobnie jak użycie -Cflagi z, sshaby włączyć sshkompresję. Mogę zaktualizować ten post w późniejszym terminie, aby zawierał dokładne polecenie, którego używam (co jest bardzo podobne do tego, co zamieściłem), ale nie mam teraz ochoty korzystać z VPN, ponieważ jestem w tym tygodniu na wakacjach.

W Solarisie 10 również używam -c blowfish, ponieważ jest to najszybszy szyfr do uwierzytelnienia, a także pomaga przyspieszyć działanie, ale nasz Solaris 11 albo go nie obsługuje, albo wyłącza ten zestaw szyfrów.

Dodatkowo, jeśli wybierzesz opcję ssh/ tar, dobrym pomysłem byłoby zaimplementowanie mojego oryginalnego rozwiązania polegającego na korzystaniu screenz kopii zapasowej, która może chwilę potrwać. Jeśli nie, upewnij się, że twoje ustawienia podtrzymania / limitu czasu ssh_configsą odpowiednio poprawione, w przeciwnym razie istnieje duże prawdopodobieństwo, że ta metoda spowoduje uszkodzenie rury.

Nawet jeśli zdecydujesz się na to scp, zawsze uważam, że najlepszą praktyką jest używanie screenlub tmuxpodczas wykonywania operacji tego rodzaju, na wszelki wypadek . Wiele razy nie postępuję zgodnie z własnymi radami i nie robię tego, ale rzeczywiście dobrą praktyką jest używanie jednego z tych narzędzi, aby upewnić się, że zdalne zadanie nie zepsuje się z powodu rozłączenia aktywnej sesji powłoki.

Wiem, że chcesz znaleźć podstawową przyczynę swojego rsyncproblemu. Jeśli jednak jest to naprawdę ważne, są to dwa świetne obejścia, z którymi można w międzyczasie eksperymentować.

Miałem ten sam problem na OSX El Capitan i naprawiłem to poprzez uaktualnienie do rsync v3.11. Problem występował dla mnie w wersji 2.6.9.

Kerberos służy tylko do uwierzytelniania, co nie powinno powodować żadnych problemów po utworzeniu udanego połączenia.

Czy próbowałeś również użyć demona rsync?

Czy Twoje serwery są w tej samej sieci, czy masz między nimi zaporę ogniową / router?

Możesz spróbować skonfigurować sesję netcat między serwerami. Jest to prosty sposób na sprawdzenie, czy występują problemy z połączeniem między serwerami.

Na pierwszym serwerze:

nc -lk <port-number>

I na kliencie

nc <server> <port-number>

Możesz pozostawić połączenie otwarte i sprawdzić, czy połączenie je utrzymuje, czy też utracisz połączenie. Możesz także spróbować napisać coś na kliencie, a zobaczysz, że kończy się on na drugiej stronie.

Na zdalnym serwerze masz coś, co zapisuje na standardowe wyjście . To może być w twoim .profilelub .bash_profile. Może to być coś mniej oczywistego jak sttylub mesg. W razie wątpliwości skopiuj transkrypcję na swoje pytanie dotyczące logowania na serwerze (zredaguj nazwę hosta za wszelką cenę).

jedyny raz, gdy miałem taki problem z rsync, wyśledziłem go do wolnego portu Ethernet na innym komputerze, który miał ten sam adres IP, co mój serwer docelowy. Jeśli rsync jest niestabilny, prawie na pewno jest to problem z niezawodnością sieci lub (w moim przypadku) konfiguracją.

I napotkał podobny problem podczas uruchamiania rsynclub ręcznie (albo z cp, scplub w Gnome Nautilus) kopiowania dużych plików z Linuksa do niskiego zasilanego ARM Linux Gigabit NAS nad okablowaniem sieci (brak kerberosw mojej konfiguracji). Dyski NAS są współużytkowane sambai są montowane na kliencie za pomocą cifs. Rozwiązaniem było dla mnie zamontowanie systemu plików NAS z poziomu klienta bez buforowania (zobacz także strony podręcznika montowania.cifs ):

sudo mount -t cifs //server.lan/somedir /mnt/somedir/ -o cache=none

Alternatywnie, w przypadku montażu napędu NAS na kliencie za pomocą gvfsw nautilusten problem nie utrzymują się przy kopiowaniu dużych plików (ale to nie działa w połączeniu z rsyncchociaż).

Spraw, aby Linux zapisywał do sieciowego systemu plików jednocześnie z odczytami z dysku lokalnego, a następnie wyjaśnia, dlaczego ten problem może występować.

Po prostu zaktualizuj wersje rsync, aby upewnić się, że są dokładnie takie same na komputerach wysyłających i odbierających. Zobacz moją odpowiedź tutaj: /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794 .