Artykuł ten traktuje o maksymalnym uproszczeniu sobie codziennych spraw związanych z utrzymywaniem naszego systemu, tj. kopiami bezpieczeństwa i synchronizacją danych między komputerami, z wykorzystaniem bezpiecznego połączenia SSH.

Co mogę zyskać czytając ten artykuł? W skrócie: zyskasz na czasie i wygodzie, nie będziesz musiał przejmować się tworzeniem kopii swoich danych, jednym kliknięciem uaktualnisz swoje domowe pliki o treści dodane w pracy, bądź komputer zrobi to samoczynnie. Ostatecznie zdobędziesz trochę wiedzy, którą być może kiedyś wykorzystasz.

W kolejnych punktach artykułu, krok po kroku przejdziemy od rzeczy podstawowych do tych bardziej skomplikowanych, a wszystko zostanie poparte przykładami dla jak największej czytelności.

Jak wspomniałem w tytule, artykuł powstał w oparciu o Kubuntu, więc poruszone zagadnienia zadziałają na nim (a także na innych systemach opartych o Debiana i KDE) “od kopa”, jednak można je z powodzeniem przystosować do jakiejkolwiek dystrybucji po zmianie lokalizacji skryptów.

Zdalne wykonywanie komend (ssh)

To co nas najbardziej interesuje w SSH to to, że dzięki niemu możemy nawiązać bezpieczne połączenie z komputerami zdalnymi. Nie będziemy się tutaj zajmować historią i polityką, czyli tym dlaczego akurat to rozwiązanie, jak powstało itd… zostawimy to innym, a sami skupimy się na praktycznych zastosowaniach.

Po pierwsze musimy mieć serwer SSH na komputerze na którym będziemy chcieli zdalnie pracować, w tym wypadku na naszym serwerze. Aby to sprawdzić musimy się upewnić, że takowy jest na nim uruchomiony, w tym celu wpisujemy w konsoli:

$ ps -A | grep ssh

Jeśli polecenie to zwróci nam linie zawierającą sshd to znaczy, że serwer już działa a my możemy przejść dalej, do etapu tworzenia kluczy.

Gdy go nie mamy, to instalujemy:

# apt-get install openssh-server

Aby umożliwić automatyczne logowanie do serwera SSH należy utworzyć na naszych stacjach roboczych parę kluczy, co osiągniemy wydając następującą komendę:

$ ssh-keygen -t rsa

Zapytani o hasło, zostawiamy puste pole i po prostu wciskamy dwukrotnie [Enter] - dla samego hasła i jego potwierdzenia. Nie ma tutaj niebezpieczeństwa, że nagle pozostawimy takie konto bez zabezpieczeń. Jedno, co się stanie to to, że uprawnieni użytkownicy dostaną możliwość automatycznego logowania w oparciu o ich klucz szyfrujący. Podanie w tym momencie jakiegokolwiek hasła skutecznie zablokuje nam możliwość automatycznego logowania do serwera, na czym nam bardzo zależy, gdyż przy każdej próbie logowania wyskoczy monit o jego podanie.A przekreśli nam możliwość wygodnego użycia takich narzędzi jak choćby scp, rsync czy rdiff-backup.

Po wydaniu ostatniej komendy powstają następujące pliki w katalogu ~/.ssh:

• id_rsa – nasz klucz prywatny który należy zachować tylko dla siebie,
• id_rsa.pub – klucz publiczny do rozesłania na zdalne hosty,
• known_hosts – lista zaakceptowanych serwerów.

Ich umiejscowienie warto sobie zapamiętać, gdyż w wypadku jakichkolwiek zmian sygnatury serwera(zmiany sprzętu, itp.) stracimy możliwość połączenia dopóki nie poprawimy odpowiedniego wpisu w trzecim z plików, o czym zresztą zostaniemy poinformowani przez naszego klienta ssh.

Następnie należy skopiować nasz klucz publiczny do naszego serwera, bądź też innych komputerów na które zamierzamy się automatycznie logować:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Oczywiście zastępujemy user nazwą odpowiedniego w naszym przypadku użytkownika a host odpowiednią nazwą lub adresem IP. Musimy jeszcze potwierdzić wymianę kluczy odpowiadając yes i wprowadzając hasło skojarzone z danym użytkownikiem na naszym serwerze.
W tym momencie na naszym serwerze w podkatalogu ~/.ssh na koncie usera powstaje plik authorized_keys zawierający zaakceptowane klucze i skojarzonych z nimi użytkowników. O tym jak istotny jest to plik przyjdzie nam się przekonać, gdy postanowimy ograniczyć możliwość automatycznego logowania pewnym użytkownikom lub wykonywać określone komendy na ich logowanie. Nie uprzedzajmy jednak faktów, a przejedzmy dalej.

W tym momencie możemy już się połączyć z naszym serwerem:

$ ssh user@host

Przy czym nie powinniśmy zostać zapytani o jakiekolwiek hasło, lecz od razu przejść na konsole zdalnego komputera. Jeśli wszystko działa poprawnie to gratulacje, właśnie zakończyliśmy pierwszy etap konfiguracji naszych komputerów.

Kopiowanie w tunelu ssh (scp)

Scp służy do kopiowania plików przy użyciu bezpiecznego połączenia ssh. Jeśli przeszliśmy przez poprzedni krok to na pewno mamy go w naszym systemie. Składnia jest równie nieskomplikowana co w wypadku większości linuksowych poleceń, mamy więc:

$ scp [opcje] [co] [gdzie]

Poleceniem:

$ scp user@host:~/plik ~/

skopiujemy plik do naszego katalogu domowego z katalogu domowego usera na hoście. Aby skopiować ten sam plik do naszego katalogu bieżącego wydajemy polecenie:

$ scp user@host:~/plik .

Natomiast poleceniem:

$ scp plik user@host:~/

skopiujemy nasz plik z bieżącego katalogu do katalogu domowego usera na hoście.

Dodanie opcji -r spowoduje rekursywne kopiowanie katalogu wraz z całą jego strukturą. A jeśli ustawiliśmy serwer ssh do nasłuchiwania na niestandardowym porcie to przyda się opcja -P [nr portu], która skieruje polecenie pod odpowiedni adres.

Synchronizacja danych (rsync)

Wyobraźmy sobie sytuacje, w której pracujemy na dwóch lub więcej komputerach (np. praca/dom), wprowadzamy kolejne dane do plików, powiększamy listę kontaktów. W pewnym momencie nie jesteśmy już w stanie zapanować nad ręcznym uaktualnianiem danych lub po prostu szkoda nam tracić czasu. W takich sytuacjach przydatnym narzędziem okazuje się program do synchronizacji danych jakim jest rsync, umożliwiającym nam pracę zarówno z dyskami lokalnymi jak i z komputerami zdalnymi. Ta druga opcja będzie szczególnie przydatna w naszej sytuacji, na której się szczególnie skupimy.

Tym czym rsync zyskał sobie sporą rzeszę fanów jest sposób w jaki działa. Otóż stara się minimalizować zbędne operacje na plikach, przez co jest względnie szybki i oszczędnie gospodaruje pasmem w wypadku pracy przez sieć. Kolejną jego zaletą jest współpraca z ssh co pozwoli nam synchronizować dane pomiędzy naszymi komputerami w sposób niemalże dla nas niewidoczny. Rsync powinien być standardowo zainstalowanym narzędziem w naszej dystrybucji, jeśli tak nie jest należy go doinstalować (apt-get install rsync).

Podstawowa składnia programu jest następująca:

$ rsync [parametry] [co] [gdzie]

W wypadku rsynca szczególne znaczenie mają parametry programu, to dzięki nim możemy dostosować jego działanie do własnych potrzeb. Z najważniejszych należy wymienić:

• a [archive] - to multi-parametr przekazujący wiele opcji jak działanie rekursywne, zachowywanie linków, uprawnień, czasów, itd. Jest to podstawowy parametr rsynca,
• u [update] - ten parametr pozwala nam zachować w niezmienionej postaci pliki które są nowsze na synchronizowanym komputerze. W tym momencie istotną kwestią staje się synchronizacja czasu naszych komputerów. Warto pomyśleć o własnym serwerze ntp lub choćby korzystaniu z tego samego serwera publicznego na wszystkich komputerach w sieci,
• v [verbose] - z tym parametrem program robi się bardziej gadatliwy. Można zmusić go do jeszcze większej gadatliwości poprzez zwielokrotnienie tego parametru, przy (-vvv) co jest wartością maksymalna nasz program staje się aż nadto wylewny,
• h [human-readable] - przedstawia nam dane w czytelnej dla nas postaci,
• z - jest parametrem odpowiedzialnym za kompresje danych podczas transferu co może być szczególnie istotne w wypadku rozbudowanych sieci komputerowych,
• e ssh - tym parametrem przekazujemy rsyncowi z jakiej zdalnej konsoli mamy zamiar skorzystać. W naszym wypadku SSH,
• progress - dzięki temu parametrowi widzimy w którym etapie synchronizacji właśnie się znajdujemy,
• exclude=[maska] - tutaj możemy wykluczyć grupę plików których nie chcemy przenosić, co jest bardzo użyteczne do blokowania transferu plików tymczasowych,
• delete - użycie tej opcji musi zostać szczególnie przemyślane, gdyż nieodpowiednie jej użycie może pozbawić nas plików które chcielibyśmy zachować. W założeniu dzięki tej opcji z katalogu synchronizowanego zostaną skasowane pliki/katalogi, których nie ma w katalogu synchronizującym(źródle).

Oczywiście można w ramach polecenia korzystać z symboli wieloznacznych, wykluczeń plików, itp. Szczegółowy opis parametrów uzyskamy po wydaniu polecenia:

$ rsync --help

Jest to bardzo zalecane, gdyż pozwoli dostosować działanie programu do naszych potrzeb.

W tym momencie musimy się zastanowić co, jak i kiedy synchronizować.

Jak ?

Powrócimy do naszej sytuacji, czyli dwóch komputerów które należy zsynchronizować. Otóż możemy synchronizować nasze dane na wiele sposobów, np. korzystając z pamięci USB, internetu albo sieci lokalnej. Wybór optymalnej metody zależy od wielu czynników, w tym ilości danych do przeniesienia, szybkości i ceny połączeń z internetem.

Tutaj skupimy się na synchronizacji danych w sieciach lokalnych, co niewielkim nakładem pracy możemy rozszerzyć o synchronizacje poprzez internet. Wydaje się, że optymalnym byłoby skorzystanie w tym celu z domowego routera/serwera, który z racji swojego przeznaczenia jest włączony non stop. Po prostu dołożymy mu trochę zadań i kolejne konto użytkownika. Od tego momentu zawsze, o ile znajdziemy połączenie do internetu, będziemy mogli synchronizować nasze dane, nie tylko w obrębie sieci lokalnej, ale z każdego zakątka świata.

Innym sposobem, jeśli nie mamy linuksowego routera, jest bezpośrednia wymiana danych pomiędzy naszymi komputerami, co będzie wymagało pozostawienia włączonym dwóch komputerów do momentu ukończenia synchronizacji.

Kiedy ?

Innym aspektem wartym przemyślenia jest moment synchronizacji. Kiedy właściwie synchronizować nasze dane? Synchronizować manualnie, czy może lepiej automatycznie podczas startu komputera? Nie ma tutaj jednoznacznej odpowiedzi, każda z opcji ma swoje plusy i minusy. Metoda manualna daje nam możliwość aktualizacji dokładnie kiedy chcemy, w momencie gdy na przykład skończyliśmy pracę nad ważnym projektem. Choć z drugiej strony czasami możemy zapomnieć o synchronizacji, popracować na drugim z komputerów no i problem gotowy. W zależności od opcji zastosowanych w skryptach synchronizujących, albo pojawi się nam trochę plików, których wcale nie chcieliśmy albo skasujemy te nad którymi właśnie pracowaliśmy.

Z tych względów najlepiej chyba jest wysyłać naszą pracę na nasz serwer w momencie wylogowania, po to żeby w momencie logowania nasze dane synchronizowały się w oparciu o najnowsze dostępne na nim wersje. Dodatkowo można tą metodę uzupełnić o manualnie uruchamiany skrypt, tworząc hybrydę tych dwóch rozwiązań co powinno być wystarczające dla potrzeb większości użytkowników.

Co ?

Właśnie doszliśmy do momentu, w którym musimy sobie odpowiedzieć na pytanie: co właściwie synchronizować? W tym momencie aż chciałoby się odpowiedzieć… Jak to co?! Wszystko! Dokumenty, ulubione/zakładki, zdjęcia, ustawienia dziesiątek programów, wyglądy menu i setki innych. Niestety, nie tak szybko, nie tyle, że jest to niemożliwe to po prostu niepotrzebne. W tym miejscu czyha najwięcej pułapek. Uprzedzając pytanie: Nie, nawet jeśli mamy dwa identyczne komputery…

Problem w tym, że programy tworzą ogromne ilości danych tymczasowych. Dodatkowo bardzo często tworzone są pliki lub katalogi z przypadkowo generowanymi częściami nazw (np. Firefox). Żeby było gorzej ich pliki konfiguracyjne odwołują się do tych specyficznych nazw. Częstokroć zdarza się, że jeden z komputerów ma zainstalowane oprogramowanie, którego nie ma na drugim. W wypadku różnic sprzętowych sprawy mają się jeszcze gorzej.

Nie piszę tego po to by kogoś zniechęcać, a po to żeby wszystko sobie przemyśleć. Najlepiej parę razy, i ponadto ZROBIĆ KOPIĘ DANYCH, najlepiej w tym momencie zanim zaczniemy tworzyć własny skrypt, tak na wszelki wypadek.

Przejdźmy do przykładowych skryptów. To pozwoli nam bardziej zrozumieć sytuację.

Najpierw zajmiemy się skryptem wysyłającym dane do naszego serwera. Przedstawiony skrypt zapisujemy w ~/.kde/shutdown/Synchro_stop.sh i nadajemy mu atrybut do wykonywania. Jeśli nie mamy katalogu shutdown to należy go utworzyć, od tej pory wszystkie skrypty które się w nim znajdą będą wykonywane na nasze wylogowanie się z KDE.

#!/bin/bash
rsync --progress --exclude='*~' -auvhze ssh --delete ~/Dokumenty/ 
	user@host:~/nasz_katalog/Dane/Dokumenty/
rsync --progress --exclude='*humb.db' -auvhze ssh --delete ~/Zdjęcia/ 
	user@host:~/nasz_katalog/Dane/Zdjęcia/
rsync --progress --exclude='tmp-*' --exclude='cache-*' 
	--exclude='socket-*' -avhze ssh --delete ~/.kde/ 
	user@host:~/nasz_katalog/Dane/.kde/
rsync --progress -auvhze ssh --delete ~/.kadu/ 
	user@host:~/nasz_katalog/Dane/.kadu/
rsync --progress -auvhze ssh --delete ~/.Skype/ 
	user@host:~/nasz_katalog/Dane/.Skype/
rsync --progress --exclude='*.default' -avhze ssh --delete ~/.mozilla/ 
	user@host:~/nasz_katalog/Dane/.mozilla/
rsync --progress --exclude='Cache' -avhze ssh --delete 
	~/.mozilla/firefox/*.default/  
	user@host:~/nasz_katalog/Dane/.mozilla_firefox/

Uwaga: Każda linijka skryptu rozpoczyna się od rsync, tutaj ze względu na ich długość zostały one przełamane (znak \). Należy to poprawić tworząc własny skrypt.

W powyższym przykładzie wysyłamy dane do naszego_katalogu na naszym serwerze. Najpierw zostaną zsynchronizowane Dokumenty, bez plików tymczasowych – tych z zakończeniem *~, a później nasze zdjęcia (bez plików Thumb.db). Kolejna linijka odpowiada za synchronizacje elementów KDE (wygląd menu, wszystkie programy wchodzące w skład pakietu). Aby lepiej zobrazować jak istotna to linijka wspomnę o kilku programach, które pod nią podlegają.

Jeśli naszym menedżerem okien jest Konqueror, to w tym momencie przenosimy nasze profile (nie ma więc potrzeby ponownego przekopywania się przez setki okien na drugim z komputerów aby odtworzyć porządane zachownie się programu). Kolejnym jest Kmail, czyli klient poczty (nigdy więcej nie musimy pamiętać na którym z komputerów odebraliśmy pocztę, mamy ją, właściwie to będziemy mieli ją wszędzie gdzie potrzebujemy bez ponownego łączenia się z serwerem poczty).

Chociaż to bardzo wygodne, to może się zdarzyć, że znajdzie się ktoś dla kogo takie rozwiązanie jest niedopuszczalne. Jedynym wyjściem pozostaje wtedy zdać się na synchronizację poszczególnych elementów pakietu z osobna. Oczywiście w naszym przykładzie pomijamy wszelkie pliki tymczasowe.

Kolejne dwie linijki odpowiadają za synchronizacje Kadu i Skype.

W dalszej części przechodzimy do Firefoxa. Tutaj ze względu specyfikę programu, o której już wspomniałem wyżej, synchronizacja musiała zostać rozdzielona na dwa etapy. Problemy zawdzięczamy podkatalogowi *.default z przypadkowo utworzoną początkową częścią nazwy i plikowi profiles.ini, który na owego wskazuje.

Nie muszę już chyba wspominać, że nasze ulubione/zakładki wpisujemy tylko raz, a jeśli chodzi o pluginy… wszystko załatwione, już nie muszą być podwójnie instalowane i konfigurowane.

Ponieważ nie jestem użytkownikiem Thunderbirda może się okazać, że jego użytkownicy będą musieli poświęcić chwile na dostosowanie tej części skryptu do ich potrzeb.

Folder nasz_katalog odpowiada naszej nazwie użytkownika, tzn. wszystkie nasze dane będą w nim zawarte i odpowiednio dane innych znajdą się w odpowiadających im katalogach, np. katalog_marty, itd. Dzięki temu nie musimy tworzyć oddzielnych kont dla wszystkich użytkowników, których dane chcemy synchronizować.

O ile pokazane tu rozwiązania chcemy zastosować w sieci domowej, to myślę, że jest to optymalna metoda. W wypadku większych sieci sytuacja nieco się komplikuje, gdyż wzrasta prawdopodobieństwo natrafienia na owcę o barwie i myślach czarniejszych od sumienia faszysty, co wystawi nasze poufne dane na niebezpieczeństwo.

Jeśli zachodzi taka obawa należy niezwłocznie utworzyć odpowiednią ilość kont na naszym serwerze, tak aby każdy z użytkowników mógł czuć się bezpiecznie, po czym odpowiednio poprzerabiać skrypty.

Przejdźmy teraz do skryptu, uaktualniającego nasze dane. Zapisujemy go w ~/.kde/Autostart/Synchro_start.sh

#!/bin/bash
rsync --progress -auvhze ssh --delete
	user@host:~/nasz_katalog/Dane/Dokumenty/ ~/Dokumenty/
rsync --progress -auvhze ssh --delete
	user@host:~/nasz_katalog/Dane/Zdjęcia/ ~/Zdjęcia/
rsync --progress --exclude='tmp-*' --exclude='cache-*'
	--exclude='socket-*' -avhze ssh --delete
	user@host:~/nasz_katalog/Dane/.kde/ ~/.kde/
rsync --progress -auvhze ssh --delete
	user@host:~/nasz_katalog/Dane/.kadu/ ~/.kadu/
rsync --progress -auvhze ssh --delete
	user@host:~/nasz_katalog/Dane/.Skype/ ~/.Skype/
rsync --progress --exclude='profiles.ini' -auvhze ssh
	user@host:~/nasz_katalog/Dane/.mozilla/ ~/.mozilla/
rsync --progress --exclude='Cache' -avhze ssh --delete
	user@host:~/nasz_katalog/Dane/.mozilla_firefox/
	~/.mozilla/firefox/*.default/

Uwaga: Tutaj podobnie jak wyżej należy pamiętać o przełamaniu skryptu

Dla odnotowania, gdybyśmy zdecydowali się na przenoszenie danych z wykorzystaniem dysku przenośnego poniższą komendą:

$ rsync -a ~/katalog/ /media/disk/katalog/

skopiujemy nasze dane z lokalnego katalogu do katalogu na dysk USB.

Na zakończenie polecam za pierwszym razem ręcznie wykonać skrypty synchronizujące, z tym że najpierw wykonujemy skrypty na wylogowanie.

Po pierwsze może to zająć trochę czasu (nawet do kilku godzin jeśli postanowimy przenieść cała kolekcję mp3 i filmów), co w wypadku bardziej nerwowych użytkowników uratuje cenny sprzęt przed zdemolowaniem.

Po drugie, mając podgląd na wyjście skryptu zorientujemy się o co w tym wszystkim chodzi i jak to działa.

Czas trwania każdego kolejnego wywołania skryptu będzie zależał od różnic w stanie naszych plików, przez co powinien być znacznie krótszy.

Kopie bezpieczeństwa (rdiff-backup)

Tworzenie kopii bezpieczeństwa.

Rdiff-backup jest programem, a właściwie skryptem napisanym w pythonie [dzięki pooh], tworzącym kopie przyrostowe opartym o algorytm rsynca, dzięki czemu powiela wiele jego właściwości. Podobnie jak w wypadku rsynca jego działanie najlepiej oprzeć o skrypt. Analogicznie jego pierwsze uruchomienie zajmie nam najwięcej czasu, gdyż podczas niego zostaną skopiowane wszystkie wskazane pliki do nowej lokalizacji. Nie ma zatem sensu silić się na backup, jeśli nie możemy zapewnić odpowiedniej ilości miejsca na kopie naszych danych.

Długość każdego kolejnego uruchomienia będzie proporcjonalna do ilości zmian dokonanych w obrębie archiwizowanych danych.

Aby nie generować zbytniego ruchu w naszej sieci lokalnej sporządzaniem kopii zajmie się nasz serwer. Choć nic nie stoi na przeszkodzie żeby tworzyć kopie choćby na przenośnych dyskach.

Musimy upewnić się czy na naszym serwerze jest odpowiedni pakiet:

$ dpkg -l | grep rdiff-backup

Jakby go nie było to należy wydać polecenie:

$ sudo apt-get install rdiff-backup

po czym wpisać hasło roota.

W tym momencie możemy już przejść do etapu wykonywania kopii. Jeszcze tylko musimy się zdecydować kiedy jest odpowiednia ku temu pora. Najlepiej skorzystać z okresu, nie przypadającego na szczytowe wykorzystanie zasobów naszego serwera, w większości wypadków okres taki przypada na późne godziny nocne bądź wczesny ranek.

W poprzednim punkcie utworzyliśmy konto na którym składujemy nasze dane. Aby sytuacja była dla nas bardziej przejrzysta zmodyfikujemy odrobinę strukturę katalogów na tym koncie. W tej chwili mamy w katalogu domowym podkatalogi odpowiadające użytkownikom, którzy korzystają z synchronizacji, a w nim katalog Dane przeznaczony na przechowywanie danych programów. W każdym katalogu użytkownika dodajemy folder Backup, w którym znajdą się nasze kopie zapasowe. Tworzymy w tym celu skrypt, nadajemy mu odpowiednie atrybuty i dopisujemy jego wywołanie do crona o określonej porze.

#!/bin/bash

echo `date +%Y.%m.%d_%H:%M:%S` Rozpoczęcie > /root/Backup_Profili.txt

for UZYT in /home/user/*
do

   if [ -d $UZYT/Backup ]
   then
	echo `date +%Y.%m.%d_%H:%M:%S` $UZYT >> /root/Backup_Profili.txt
	rdiff-backup $UZYT/Dane $UZYT/Backup
	rdiff-backup --remove-older-than 6M $UZYT/Backup
   fi

done

echo `date +%Y.%m.%d_%H:%M:%S` Koniec >> /root/Backup_Profili.txt

W powyższym skrypcie…

Pierwszy blok instrukcji tworzy nam plik raportu z tworzenia kopii i zapisuje go w pliku na koncie roota.

Drugi blok instrukcji sprawdza czy katalog do backupu (Backup) znajduje się w naszym katalogu użytkownika i jeśli tak jest, to przechodzimy do tworzenia kopii.

Tym prostym sposobem możemy określić które katalogi spośród katalogów użytkowników będą kopiowane, a które nie. Dzięki temu możemy utworzyć oddzielny katalog odpowiedzialny za przechowywanie wspólnych filmów nie martwiąc się, że zrobienie kopii bezpieczeństwa zajmie nam całą pojemność naszego dysku. Jeśli skrypt nie odnajdzie katalogu Backup to zwyczajnie pominie taki folder.

Jeśli skrypt ma się zająć naszym folderem to dopisuje jego nazwę i czas rozpoczęcia archiwizacji do naszego raportu, po czym przechodzi do właściwego procesu archiwizacji. Po jego zakończeniu sprawdza czy pomiędzy zarchiwizowanymi plikami nie znajdują się takie które zostały skasowane na naszym lokalnym komputerze 6 miesięcy temu lub więcej (można tu używać oznaczeń jak: Y - rok, M - miesiąc, W - tydzień, D - dzień, h - godzina, m - minuta, s - sekunda, lub ich kombinacji, np… 2Y3M4h - 2 lata 3 miesiące i 4 godziny), jeśli takowe znajdzie to je kasuje. Po czym sprawdza kolejne konta użytkowników dopisując na koniec czas ukończenia zadania.

Utworzony w ten sposób skrypt zapisujemy na naszym serwerze (w tym wypadku /usr/sbin/backup_profili.sh), po czym dodajemy odpowiednią dla nas linijkę do /etc/crontab.

W wypadku wywołania skryptu o 4:15 będzie to:

15 4    * * *   root    /usr/sbin/backup_profili.sh

Warto w tym momencie wspomnieć w jaki sposób rdiff rozpatruje parametry include/exclude. Otóż są one rozpatrywane od lewej do prawej z tym, że warunki wyższe w hierarchi (te bardziej z lewej) mają większą wartość od warunków podrzędnych, tzn. że los pliku (zakwalifikowany bądź wykluczony przez nadrzędne parametry) nie zostanie zmieniony przez parametry stojące za nimi. Co daje nam wręcz nieograniczone możliwości filtrowania plików, które powinny zostać zarchiwizowane.

Jeśli zdecydujemy się na wykonywanie kopii na komputerze zdalnym, skorzystamy z nieco zmodyfikowanego polecenia. Dla naszych ulubionych z Firefoxa będzie ono miało postać:

$ rdiff-backup --include '**bookmarks.html' --exclude '**'
~/.mozilla/firefox/*.default user@host::/home/user/katalog_do_backupu

Uwaga: Proszę zwrócić uwagę na dwa dwukropki i przełamanie kodu

Odtwarzanie danych

Na samym początku bardzo istotna uwaga, którą warto zapamiętać. Jeśli awarii nie uległ cały katalog z naszymi danymi (nieumyślne skasowanie części plików, itp.), najlepszą praktyką wydaje się odzyskiwanie danych nie bezpośrednio do katalogu w którym oryginalnie trzymaliśmy dane, lecz do jakiegoś katalogu podrzędnego wobec niego. Dzięki temu unikniemy sytuacji, w której utracimy część danych na skutek nadpisania nowszych wersji plików z ich stanem z przeszłości.

Jeśli w którymś momencie pracy z komputerem nieopatrznie skasowaliśmy ważny plik, możemy wywołać ręcznie startową synchronizację danych. Oczywiście należy pamiętać o uprzednim przeniesieniu plików, które właśnie edytowaliśmy w bezpieczne miejsce (np. na pulpit). Później zastępujemy odpowiednie pliki ich kopiami z pulpitu i mamy kłopot z głowy.

W wypadku gdybyśmy chcieli odzyskać nasze dane w stanie z jakiegoś bardziej sprecyzowanego momentu, najpierw posłużymy się poleceniem:

$ rdiff-backup -r 2D ~/nasz_katalog/Backup/Dokumenty
		~/nasz_katalog/Dane/Dokumenty 

Uwaga: Proszę zwrócić uwagę na przełamanie kodu

Powyższe polecenie oczywiście wykonujemy na naszym serwerze, po czym ręcznie wymuszamy synchronizację danych.

Podczas odzyskiwania danych posługujemy się tymi samymi oznaczeniami czasu jak w wypadku tworzenia kopii. W powyższym wypadku nadpiszemy stan katalogu Dokumenty ich stanem sprzed 2 dni. Jeśli nie mamy kopii danych z tego okresu, to rdiff samoczynnie znajdzie kopię starszą od zadanej przez nas(czyli, np. sprzed 3 dni).

Należy mieć na uwadze, że rdiff to narzędzie znacznie bardziej rozbudowane niż jest to przedstawione tutaj. W tym artykule skupiliśmy się na jego podstawach, co niewątpliwie przybliża tematykę i daje dobrą bazę do dalszej pracy. Doskonałym źródłem informacji okazuje się lektura podręcznika do programu, a po kolejne przykłady praktycznego zastosowania odsyłam do internetu.

Kilka słów na zakończenie

Nie są to jedyne narzędzia, które możemy wykorzystać aby ułatwić sobie prace administratora, mam tu szczególnie na myśli backup danych. Zatem nie jest powiedziane, że każdemu przedstawione tu rozwiązania będą pasowały. W chwili obecnej mamy taki wybór programów, że każdy powinien znaleźć coś dla siebie.

Na koniec gorąco zachęcam wszystkich do eksperymentowania, przerabiania kodu no i publikowania wyników.

Strony które warto odwiedzić

• http://jakilinux.org/aplikacje/sztuczki-z-ssh/
• http://www.suso.org/docs/shell/ssh.sdf
• http://troy.jdmz.net/rsync/index.html
• http://freebsd.peon.net/quickies/21/
• http://rdiff-backup.stanford.edu/rdiff-backup.1.html
• http://arctic.org/~dean/rdiff-backup/unattended.html
• http://www.nongnu.org/rdiff-backup/index.html
• http://www.howtoforge.com/linux_rdiff_backup

Korekta: oZz