Béton brut

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ę.

• -zaP “prześlij spakowane z zachowaniem atrybutów plików,
• —exclude=Desktop/p0rn/bardzo_nielegalne wyłącza ścieżkę z tworzonej kopii,
• —delete (i wariacje jak —delete-after) kasują pliki, które zostały usunięte ze źródła. Musicie się zastanowić, czy chcecie trzymać wszystkie pliki i mieć szansę wyciągnięcia jakiegoś pochopnie skasowanego, czy też zależy Wam na archiwum 1:1 z oryginałem.

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:

1
2
3
4

#!/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.