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ć.
kerberosdo uwierzytelnienia na zdalnym serwerze.