Jeśli z przyjemnością przechowujesz kopię danych na komputerze pośrednim, możesz po prostu napisać skrypt, który zaktualizował kopię lokalną, używając serwera server1 jako referencji, a następnie zaktualizował kopię zapasową na serwerze2, używając kopii lokalnej jako referencji:
#!/bin/sh
rsync user@server1:/path/to/stuff /path/to/loca/copy -a --delete --compress
rsync /path/to/loca/copy user@server2:/path/to/where/stuff/should/go -a --delete --compress
Użycie prostego skryptu oznacza, że chcesz, aby pojedyncze polecenie wykonało wszystko. Może to być oczywiście nie-bezpieczeństwo, jeśli dane są wrażliwe (ty lub inni w twojej firmie, nie chcesz, aby kopia unosiła się na twoim laptopie). Jeśli serwer1 jest lokalny dla Ciebie, możesz po prostu usunąć lokalną kopię później (ponieważ następnym razem będzie można szybko zrekonstruować lokalną sieć LAN).
Konstrukcja tunelu, aby serwery mogły efektywniej ze sobą rozmawiać, powinna być możliwa w następujący sposób:
- Na serwerze 2 wykonaj kopię / bin / sh jako / usr / local / bin / shforkeepalive. Zamiast tego używaj dowiązania symbolicznego, a nie jego kopii; nie musisz jej aktualizować po aktualizacjach bezpieczeństwa łatki / bin / sh.
Na serwerze 2 utwórz skrypt, który przez kilka sekund nie wykonuje nic poza uśpieniem w pętli, a następnie wyśle echo niewielkiej ilości tekstu i użyj tej „kopii” sh:
#!/usr/local/bin/shforkeepalive
while [ "1" != "0" ]; do
echo Beep!
sleep 5
done
( echoprawdopodobnie nie jest to konieczne, ponieważ sesja nie będzie bezczynna przez wystarczająco długi czas, aby przekroczyć limit czasu, nawet jeśli SSHd jest skonfigurowany do ignorowania pakietów utrzymywania aktywności od klienta ssh)
Teraz możesz napisać skrypt na swoim laptopie, który uruchamia tunel zwrotny w tle, informuje serwer server1, aby użył rsync do wykonania operacji kopiowania, a następnie zabija tunel zwrotny, zabijając skrypt zapętlający (który zamyka sesję SSH):
#!/bin/sh
ssh user@server2 -L2222:127.0.0.1:22 /usr/local/bin/keepalivesctipt &
ssh user@server1 -R2222:127.0.0.1:2222 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
ssh user@server2 killall shforkeepalive
Sposób, w jaki to działa:
- Wiersz 1: standardowe polecenie „do interpretacji tego skryptu”
- Wiersz 2: uruchom połączenie SSH z tunelem zwrotnym i uruchom przez niego skrypt podtrzymujący, aby był otwarty. Trailing & mówi bashowi, aby uruchomił to w tle, aby kolejne linie mogły działać bez czekania na zakończenie
- Wiersz 3: uruchom tunel, który połączy się z tunelem powyżej, aby serwer 1 mógł zobaczyć serwer 2, i uruchom rsync, aby wykonać kopiowanie / aktualizację w ramach tego układu
- Wiersz 4: zabij skrypt utrzymywania aktywności po zakończeniu operacji rsync (a więc powróci drugie wywołanie SSH), co nastąpi i pierwsza sesja ssh.
Nie wydaje się to szczególnie czyste, ale powinno działać. Nie przetestowałem powyższego, więc może być konieczne jego ulepszenie. Uczynienie z polecenia rsync skryptu jednowierszowego na serwerze server1 może pomóc, zmniejszając potrzebę ucieczki znaków takich jak 'w wywoływanym poleceniu ssh.
BTW: mówisz „nie pytaj”, dlaczego dwa serwery nie widzą się bezpośrednio, ale często jest to dobry powód. Mój serwer domowy i serwer, na których przechowywane są jego kopie zapasowe online, nie mogą się ze sobą zalogować (i mają różne hasła + klucze dla wszystkich użytkowników) - oznacza to, że jeśli jeden z dwóch komputerów zostanie zhakowany, nie można go użyć jako łatwej drogi do zhakuj drugą, aby moje kopie zapasowe były bezpieczniejsze (ktoś złośliwie usuwający moje dane z live nie może wykorzystać swojej możliwości aktualizacji kopii zapasowych, aby usunąć te kopie zapasowe, ponieważ nie ma możliwości bezpośredniego dotknięcia głównej witryny kopii zapasowej). Oba serwery mogą się łączyć z serwerem pośrednim gdzie indziej - serwer na żywo jest ustawiony, aby wcześnie rano przesyłać kopie zapasowe (przez rsync) na maszynę pośrednią, a serwer zapasowy jest ustawiony (chwilę później, aby umożliwić wykonanie kroku pierwszego), aby się połączyć i zbieraj aktualizacje (ponownie za pomocą rsyc, a następnie migawki, aby zachować wiele lat tworzenia kopii zapasowych). Ta technika może być użyteczna również w twoich okolicznościach, a jeśli tak, poleciłbym ją jako znacznie czystszy sposób robienia rzeczy.
Edycja: Scalenie mojego hacka z Aaronem, aby uniknąć całego zamieszania z kopiami / bin / sh i oddzielnym skryptem utrzymywania aktywności na serwerze 2, ten skrypt na twoim laptopie powinien wykonać całą robotę:
#!/bin/sh
ssh user@server2 -L2222:127.0.0.1:22 sleep 60 &
pid=$!
trap "kill $pid" EXIT
ssh user@server1 -R2222:127.0.0.1:2222 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
Podobnie jak powyżej, rsync łączy się z localhost: 2222, który przesyła tunelem do localhost twojego laptopa: 2222, który przesyła przez drugi tunel do localhost server2: 22.
Edycja 2: Jeśli nie masz nic przeciwko serwerowi 1 posiadającemu klucz, który pozwala mu bezpośrednio uwierzytelnić się na serwerze server2 (nawet jeśli nie widzi serwera server2 bez tunelu), możesz dalej uprościć:
#!/bin/sh
ssh user@server1 -R2222:123.123.123:22 rsync /path/to/stuff user@127.0.0.1:/destination/path/to/update -a --delete --compress -e 'ssh -p 2222'
gdzie 123.123.123.123 to adres publiczny dla server2, który może być używany jako kopia + wklej jednowarstwowy zamiast skryptu.