Ustalmy dwie prawdy o kopiach bezpieczeństwa zwanych po polsku “bakapem”. Prawda pierwsza: ludzie dzielą się na dwie grupy. Ci, którzy robią backupy i ci, którzy będą robić backupy. Prawda druga: jeżeli nie masz danych w dwóch miejscach, to nie masz danych w ogóle. Widząc ostatnie wpadki w wykonaniu Apple (“Nie zapraszaj gości. Goście nie ściągają butów i kasują Twoje konto domowe“) i partnerstwa Microsoft/Danger (“Dajcie nam swoje dane. Po co Wam lokalne pliki na przenośnych urządzeniach. Mamy taką serwerownię i… OK, straciliśmy wasze dane. My bad”) postanowiłem napisać dwuczęściowy artykuł o tym, jak przy pomocy narzędzi dostępnych w każdej szopie i kuchni uchronić swoje dane przed katastrofą.
W pierwszej części zajmiemy się prostą metodą tworzenia kopii danych. Cała instrukcja przeznaczona jest dla użytkowników *NIX-owych, użytkownicy Windowsa mogą też wziąć udział w zabawie po zainstalowaniu Cygwina z odpowiednimi pakietami.
Użytkownicy OS X mają wszystkie niezbędne programy na miejscu. Mimo to radziłbym się uzbroić w Macports i XCode, bo Apple ma tendencję do dostarczania aplikacji, o których użytkownik Debiana mówi: W mordę, jakie to stare. Użytkownicy Linuksa i *BSD sprawdzają, czy mają zainstalowane pakiety rsync i openssh-client.
W pierwszej hipotetycznej sytuacji będziemy synchronizować dane z komputera użytkownika na serwer przy pomocy SSH. Na końcu uzyskujemy kopię naszego katalogu domowego. Zamykamy książeczki, otwieramy terminale.
Na początek słowo o kluczach. SSH pozwala logować się do zdalnych systemów przy użyciu kluczy. Znaczy to tyle, że Wasz komputer ma ukryty w katalogu .ssh plik id_rsa i id_rsa.pub. Możemy powiedzieć maszynie, żeby logowała nas przy użyciu naszego klucza publicznego bez hasła. Jest to ważne w naszym przykładzie, bo chcemy uzyskać kopię automatycznie.
Wirtualny administrator założył Wam specjalne konto na wielkim i wspaniałym serwerze o nieograniczonej przestrzeni dyskowej: backupEmila@example.com. Sprawdzamy czy jesteśmy w posiadaniu kompletu kluczy we własnym katalogu domowym.
%ls .ssh/ id_rsa id_rsa.pub known_hosts
Jeżeli nie widzicie plików id_rsa* to znaczy, że musicie wygenerować sobie klucze na własną rękę. Odpalacie więc polecenie ‘ssh-keygen -t rsa‘ i na pytanie o passphrase wciskacie Enter. Nie chcemy hasła do naszego klucza.
% ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/emil/.ssh/id_rsa): Created directory '/home/emil/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/emil/.ssh/id_rsa. Your public key has been saved in /home/emil/.ssh/id_rsa.pub. The key fingerprint is: 6f:53:8b:69:79:2c:6e:fc:ef:a6:6b:bc:83:d8:8e:53 emil@jamaica
Proces generowania może wyglądać delikatnie inaczej na Waszych komputerach. Ostatecznie mamy swoje klucze. Teraz trzeba przegrać klucz publiczny na serwer, który będzie trzymał nasze kopie danych.
% scp .ssh/id_rsa.pub backupEmila@example.com:/home/backupEmila
Program scp kopiuje pliki przez SSH. Zwróćcie uwagę na drugą część, która składa się z następujących elementów: login@host:/path. Musicie więc znać ścieżkę do swojego katalogu domowego, który nie zawsze znajduje się w /home (na OS X będzie na ten przykład w /Users). Podajecie hasło i klucz publiczny powinien być już na miejscu. Zalogujcie się normalnie na zdalny system
ssh backupEmila@example.com
Sprawdźcie, czy macie już katalog .ssh; jeżeli nie, należy go stworzyć. Teraz powiemy systemowi, że nasz publiczny klucz wpuszcza Nas jak bramkarz ekskluzywnego klubu na widok ryja z Faktu, czyli bez pytania.
cat id_rsa.pub >>.ssh/authorized_keys
Stworzylismy plik .ssh/authorized_keys w którym składowane są publiczne klucze. Wylogowujemy się i logujemy ponownie. Tym razem powinno przejść bez hasła. Jeżeli nie udało Ci się zalogować bez hasła, to prawdopodobnie masz jeszcze szanse na jakąś karierę, nie wiem, w polityce chyba wiele nie trzeba, musisz tylko dobrze wyglądać w krawacie.
Spróbujmy coś przegrać używając rsync. Stworzymy sobie katalog zupa_z_zabawkami na lokalnym komputerze, wrzucimy tam kilka dziwnych plików i zobaczymy, co nam z tego wyjdzie.
% rsync -zaP zupa_z_zabawkami backupEmil@example.com:/home/backupEmilla/zupa_z_backupami building file list ... 1212 files to consider zupa_z_zabawkami/apt/ zupa_z_zabawkami/apt/apt.conf.d/ zupa_z_zabawkami/apt/listbugs/ zupa_z_zabawkami/console-tools/ zupa_z_zabawkami/console/ zupa_z_zabawkami/cron.d/ zupa_z_zabawkami/cron.daily/ zupa_z_zabawkami/cron.hourly/ zupa_z_zabawkami/cron.monthly/ zupa_z_zabawkami/cron.weekly/ [...] sent 36339 bytes received 20 bytes 14543.60 bytes/sec total size is 30671705 speedup is 843.58
Możemy się zalogować na maszynę z kopiami i sprawdzić, czy rzeczywiście kopia została utworzona. Jeżeli nie: polityka.
Dwa słowa o parametrach. W man-page od rsynca jest ich kilka trylionów. Zajmiemy się tylko trzema ważnymi z punktu widzenia backupu. Resztę poznacie na własną rękę.
No cóż, teraz należałoby zautomatyzować ten proces. Użyjemy do tego Crontaba. Nie będziemy się bawić w skrypty, wpiszemy po prostu wymaganą linię do konfiguracji.
%crontab -e 00 17,8 * * * rsync -zaP --delete --exclude=Desktop/p0rn /home/emil backupEmil@example.com:/home/emil/snapshot
Z crontabowego na nasze: skopiuj wszystko z katalogu domowego, prócz pornografii, na serwer każdego dnia, o ósmej i siedemnastej.
I to właściwie tyle. Prowizorki mają to do siebie, że trwają wieki i ratują Wam odbytnice za każdym razem, gdy napoicie laptopa kawą albo ktoś pożyczy go od Was w ciemnej alei, argumentując to nadmiarem ostrych narzędzi i bliskości gardła. Jeżeli jesteście zasobni w miejsce na dysku, to możecie przeprowadzić drobną modyfikację.
Logujemy się na backupEmila@example.com, odpalamy edytor i piszemy:
#!/bin/bash dateString=`date +"%y%m%d"` cp -r snapshot $dateString find . -mtime +8 -delete
Potem:
%chmod u+x copySnapshot.sh %crontab -e 00 0 * * * /home/backupEmila/copySnapshot.sh
Utworzy Wam to na zdalnym systemie katalog z zamrożoną kopią z danego dnia. Ostatnia linijka będzie kasowała dane starsze niż 8 dni. Dzięki temu macie tydzień historii zmian w systemie i administratora, który chce Wam wyciągnąć nerkę przez gardło. Jeżeli nie macie zdalnego serwera, na który moglibyście wrzucić takie ilości danych, możecie zawsze polegać na zewnętrznym dysku, pominąć kawałek o generowaniu kluczy i zmienić ścieżki z backupEmil@example.com:/path na /path do punktu montowania dysku.
W następnym odcinku będziemy zrzucać dane z rozmaitych serwerów w sposób, który nie jest tak młotkowy, jak ten.
« EC1 | Skrzypek przy gmachu »
Dotarłeś do końca. Czas na nową przygodę.
Eri pokonuje korporacje ołówkiem. Czerski, Piotr dziwi się światu. Waglowski prawi o prawie. Maciej występuje w roli służbisty ateistyczno-sceptystycznej religii. Patryk maca się z technologią. Gadżety, piwnice i trywialne informacje w tę stronę.
Są też tacy, którzy gadają. O filmach, grach, scepty-cyźmie, japońskich bajeczkach.
October 19th, 2009 at 18:55
co do kopiowania klucza:
ssh-copy-id user@host
załatwi wszystko bezboleśnie
October 19th, 2009 at 18:57
@kabturek
ssh-copy-id nie jest w każdej z paczek openssh-client. Dlatego nie podałem tego.
October 19th, 2009 at 19:19
a to bardzo nieładnie ze strony osób paczkujących bo to przydatne narzędzie.
Chociaż z drugiej strony każdy powinien być w stanie to zrobić też manualnie – “pokolenie ubuntu” czegoś się nauczy ;-)
October 19th, 2009 at 19:24
@kabturek
Właśnie dlatego jest manualnie. Ten artykuł to nie jest jakieś gotowe rozwiązanie, ale daje dość zabawek żeby użytkownik mógł sobie zgrzebać coś, co mu pasuje. To jedna z tych małych radości używania *NIX-ów
October 19th, 2009 at 19:36
Na wielu systemach nie trzeba podawać ścieżki do katalogu domowego – wystarczy wtedy “user@host:”
October 19th, 2009 at 20:05
@Hrw
Huh, człowiek uczy się całe życie. Nie wiedziałem. :-)
October 19th, 2009 at 20:48
“Stworzylismy plik .ssh/authorized_keys w którym składowane są odciski palców.”
Gwoli ścisłości, authorized_keys zawiera klucze publiczne, nie odciski. Dobrze jest przy tym ustawić tryb 600, coby nikt nie dopisał nam swoich kluczy (większość implementacji/konfiguracji ssh wymusza takie uprawnienia).
October 19th, 2009 at 21:14
@cezio
Masz oczywiście rację. Wpadłem w pętle “klucze”, “klucze” i nagle użyłem złego terminu, bo mi obrzydły “klucze”.
(“klucze”)
October 19th, 2009 at 21:34
1. IIRC ssh nie użyje authorized_keys z prawami innymi niż 600.
2. Polecam zapoznać się z dumpem i konceptem backupu przyrostowego, a potem wypychać tylko rsyncem to, co dump wyprodukował. Raz na tydzień pełen backup, potem róznicowe. Starsze niż np. tydzien kasujemy.
3. Niegłupim pomysłem byłoby takie paczki z dumpa czymś szyfrować. Po co ktoś ma mieć dostęp do naszego backupu?
October 19th, 2009 at 22:01
rdiff-backup + backupninja dla leniwych – graficzny konfigurator pozwoli wybrać listę katalogów do backupowania przyrostowego na zdalny serwer. Dostępne w Debianopodobnych.
October 20th, 2009 at 06:19
r już poruszył temat szyfrowania, a ja jeszcze tylko dodam, że niezaszyfrowany backup online to proszenie się o kłopoty (chyba, że naprawdę nic tajnego/osobistego nie mamy).
I warto wspomnieć o backupie klucza szyfrującego (jeśli go używamy), zwł. że backup klucza zaszyfrowany przy pomocy tego klucza to kiepski pomysł (ale z życia wzięty, nie dalej jak miesiąc temu na IRCu widziałem prośbę o pomoc w takiej sprawie).
October 20th, 2009 at 10:44
To ja ze swojej strony też dodam kilka tipów:
1. SSH domyślnie tworzy klucze DSA, a nie RSA, które są na dodatek trochę lepsze (pliki z kluczami to wtedy id_dsa i id_dsa.pub).
2. rsync -zaP oznacza trochę więcej:
-z to „kompresuj przed wysłaniem, rozpakuj na drugim końcu”; jeśli robimy backup na dysk zewnętrzny, albo po sieci lokalnej, albo backupujemy JPG/MP3/filmy, to -z lepiej pominąć – nic nie wnosi, a zabiera sporo czasu i mocy przerobowych;
-a to „zrób kopię archiwalną”, czyli zachowaj atrybuty oraz daty modyfikacji;
-P to „wyświtlaj postęp dla poszczególnych plików i – w przypadku nagłego przerwania backupu – zachowaj częściowo skopiowany plik”, czyli można to spokojnie pominąć w crontabie.
3. Co do –delete i podobnych: nowsze wersje rsynca nie czekają na przesłanie całej listy plików, tylko rozpoczynają synchronizację już podczas skanowania katalogów; na ogół jest to pożądany efekt (całość trwa krócej), ale jeśli chcemy odpalić rsynca z palca i wiedzieć ile plików pozostało do końca, warto dorzucić –delete-before (który wymusza pełen skan źródła i celu przed rozpoczęciem synchronizacji, dzięki czemu daje statystki „do końca jeszcze 1500 plików”).
October 20th, 2009 at 10:50
4. Jeśli chcemy ominąć jakąś grupę katalogów, to argument do –exclude warto wziąć w cudzysłowy, bo inaczej powłoka rozwinie:
–exclude=’/var/www/drupal/backup-*’
5. Jeśli robimy –exclude katalogów, które wcześniej kopiowaliśmy, a chcemy mieć kopię 1:1, to warto dodać –delete-excluded (który wywali wcześniejsze /var/www/drupal/backup-* trzymane w backupie).
6. Backup laptopa na dysk zewnętrzny robię tak:
$ sudo init 1
# rsync -aP –delete –exclude /cdrom –exclude /dev –exclude /media –exclude /mnt –exclude /proc –exclude /sys –exclude /tmp / /media/Deep\ Thought/X301
(serwerów na inne serwery podobnie, pomijając init 1 a za to dodając tekstowe dumpy baz itp.).
October 20th, 2009 at 10:51
(Oczywiście te wszystkie — powyżej powinny być podwójnymi minusami; węszę jakiś Textile albo inny Markdown niejawnie manglujący komentarze.)
October 20th, 2009 at 10:52
No, teraz powinienem zamienić komentarze z artykułem miejscami, co? ;) Dzięki wszystkim za dodatkowe sugestie. Mam nadzieję, że dzięki temu ktoś sobie zrobi taki setup backupów, że skończy jako Facebook Kopi Bezpieczeństwa.
October 20th, 2009 at 11:12
Heh to ja jeszcze poproszę rozwiązanie dla 2000+ hostów ;-)
A tak na poważnie to świetnie się rsync sprawdza nie tylko przy backupach. Przeniesienie systemu zainstalowanego na maszynie fizycznej na lvma dla xena też można za jego pomocą pieknie zrealizować. Tylko nie zapominajmy o –numeric-ids, które nam zachowa prawa do naszych pliczków tak jak oryginalne, niezależnie od /etc/passwd na nowej maszynie.
Czasami warto też się zastanowić nad tarem, może być szybszy.
October 20th, 2009 at 15:19
Uuuu, guys, powiało profesjonalizmem że ała.
Ja bardzo dziękuję za to info całe. Se muszę coś takiego do zrzucania danych na dysk sieciowy zrobić i pięknie Ci Opi timing wyszedł.
October 20th, 2009 at 18:08
@waltharius: to tylko gówniany TSM zostaje
@costa: przecież ty masz tajm maszin, po co ci rsync?
October 20th, 2009 at 19:37
I nigdy, przenigdy niech was nie korci żeby użyć jakiegoś “Enterprise backup” typu Amanda. Właśnie nudzę się na linii z supportem który głowi się czemu nie działa restore.
October 21st, 2009 at 14:42
@zen
Mam też hektary miejsca na NASie, które chcę obciążać kopiami rzeczy, które nie lądują mi w tajm maszin. Tajm maszin ma mi robić dobrze w bieżące prace i sprawy związane z przywróceniem systemu w razie jego wpadki. Dwa pozostałe terabajty mają się zapełniać robotowymi materiałami maści wszelakiej, które to materiały brane są z określonych miejsc na pracowym kompie (ot powiedzmy różne rzeczy z katalogu “Obrazki Fajnych Dupć Do Folderów” powinny się same zgrywać co jakiś czas w bezpieczne miejsce). W takim przypadku rsync do spółki z Automatorem i iCalem odwalą całą czarną robotę a ja jak biały człowiek będę mógł w międzyczasie ściągać jeszcze więcej Dupć do rzeczonego katalogu, coby wspomniane rsync, Atomator i iCal miały co robić :)
October 21st, 2009 at 21:56
Uroczo Ci blag przerabia double dash na ndashe.
October 21st, 2009 at 22:01
@Divide
Prawda? A myślałem, że w
presobie odpuści, czy coś. Nie chce mi się teraz tego naprawiać. Ale zerknę. Jutro.Chyba, że pojutrze.
October 21st, 2009 at 22:02
NB, tajm maszin to chyba jest właśnie jakiś obskrypcony rsync, no?
October 21st, 2009 at 22:04
@Opi,
ale w pre sobie faktycznie odpuścił, tylko tam w tym ulu dalej masz ndashe.
October 22nd, 2009 at 16:55
Można też użyć graficznej nakładki jaką jest flyback :-)
October 29th, 2009 at 14:31
Ok – do kompletu (i dla leniwych) ciekawą opcją jest dirvish – oskryptowuje rsync w ten sposób że trzyma ileś tam kolejnych pełnych backupów z wybranych dni. Przy czym robi to dość efektywnie, bo korzysta z hardlinków dla identycznych plików w kolejnych backupach. Zaleta – zawsze macie pełen backup (żadnych przyrostowych) i z więcej niż jednego dnia. Wada – jeśli agresywnie korzystacie z hardlinków, to dirvish/rsync może tego nie przeżyć (bo na liczbę hardlinków jest limit w ext2/ext3). Szczególnie jest to przyjemne dla backupów sprzed kilku miesięcy, które potrafią dzielić sporą liczbę plików z kopią aktualną (tradycyjny model z tar trzymałby dwa różne pełne backupy z tych dat). Dla ciekawych — wszystko to dzięki opcji –backupdir rsynca.