Podsumujmy.
Pytałem tylko o logowanie do shella r-o, ale rozmowa rozwinęła się, więc dla jasności:
A - konto ~, które ma być backupowane
B - konto, które służy do backupu i częściowo archiwizacji
Obydwa konta to zwyczajne konta usera na różnych maszynach linux w LAN.
Do obydwu kont mogę zalogować się sftp read-only (mam takie konta) lub normalnie do pełnego shella.
Cytat:
|
Jest to najprostszy sposób: serwer A robi tara z kopią, łączy się po sftp, czy ftps z serwerem B i przesyła plik tar.
|
Sposób dobry, ale pokażę Ci mój tok myślenia:
Konto A ma mnóstwo usług na świat (np. sklepy), stąd ryzyko włamania jest duże. Natomiast konto B przeznaczyłem wyłącznie do backupu i mocno zadbałem o jego bezpieczeństwo (także atak socjotechniczny, np. przez reset hasła poprzez fakturę etc). Założyłem, że najlepiej będzie gdy konto A "nie będzie wiedziało" o istnieniu konta B. Włamanie na konto A nie umożliwi żadnego dostępu do konta B, ani nie wpłynie na jego wykonywane zadania.
Oczywiście
bardzo słusznie zauważyłeś, że w przypadku niewykrytego włamania na konto A, obojętnie od strategii konto B będzie posiadać "lewe" pliki w backupie - bezużyteczne. Wtedy cała ta izolacja konta B pachnie security by obscurity
Zgadzam się.
W czym więc problem? Konto B służy także do częściowej archiwizacji (backup różnicowy w całości i ostatnie backupy pełne). Dostęp do niego z A umożliwiłby naruszenie archiwów sprzed włamania. W tym widzę delikatną przewagę mojego rozwiązania, choć wynika ona z nieprawidłowości: łączenia backupu z archiwizacją. A dlaczego łącze to inny temat (koszta w $).
Oczywiście można to rozwiązać: A przenosi tar via sftp do podkatalogu na B (i tylko tam ma dostęp), a B po chwili przenosi do archiwów. No ale to kolejna komplikacja, dwa crony w użyciu i cała prostota poszła w piach
Ostatecznie poradziłem sobie tak:
Z B loguję się na A wyłącznie SFTP read-only.
Miałem problem, bo standardowe klienty SFTP nie potrafią rekursywnie listować katalogów - stąd było moje pytanie.
Potrafi to lftp
http://lftp.yar.ru/, ale miałem problem z kompilacją.
Ostatecznie napisałem wrapper na pythonowego klienta, wzorując się na tym rozwiązaniu:
https://gist.github.com/2190472
Ma to taką wadę, że jest dość wolne. Full backup wykonuje mi się kilka godzin. Szczęśliwie unikam stosowania plików tymczasowych - wszelkie tego typu rzeczy trzymam w bazach danych, których zrzut następuje błyskawicznie - no i stąd działa, bo pliki w nocy są niezmienne. Może to kiedyś poprawię, na razie zrobiłem, zamknąłem i nie chce mi się w tym więcej babrać
Cytat:
|
Napisałem wcześniej abyś czytał bardziej ze zrozumieniem i porzucił filozofowanie.
|
Oczywiście, tyko odpowiadam a na forum już jest drugi temat, lepszy - gdzie można filozofować