original in en Brian Hone
en to pl Mariusz Kozłowski
Brian Hone jest administratorem i programistą w korporacji E Ink. W wolnych chwilach żegluje na bardzo zimnych wodach i wisi na skałkach .
Mogę przytoczyć długą listę powodów, dla których archiwizazja danych to koszmar administratora. Jeśli jesteś administratorem, prawdopodobnie nie muszę tego robić. Niektóre z powodów to: drogi sprzęt, który wysiada częściej niż pracuje, drogie oprogramowanie, którego zarządzanie to koszmar i długie godziny spędzone na odzyskiwaniu odpowiednich wersji plików. Żeby jeszcze pogorszyć sprawę zwykle korporacja przykłada bardzo mało wagi do kopii zapasowych, aż do tego nieuniknionego dnia, gdy są one naprawdę potrzebne. Jeśli zarchiwizowałeś/odzyskałeś dane odbyłeś taką rozmowę:
User: "Zgubiłem plik. Chcę abyś odzyskał go natychmiast."
SysAdmin: "Ok, jak się nazywał?"
User: "Nie wiem, chyba miał 'e' w nazwie."
SysAdmin: "Ok, więc w jakim był katalogu?"
User: "Nie wiem, mógł być w jednym z tych trzech..."
SysAdmin: "*westchnięcie* Kiedy ostatnio go używałeś?"
User: "Hmmm... To chyba był czwartek w lutym czy kwietniu. W czym problem?
Myślałem, że macie kopie zapasowe w takich sytuacjach."
Rsync to bardzo dobra implementacja małego pięknego algorytmu. Jego podstawowa zaleta to możliwość efektywnego mirrorowania sysetmu plików. Używając rsync prostym jest stworzenie systemu, który będzie przechowywał świeżą kopię obserwowanego systemu plików używając różnych protokołów sieciowych jak nfs, smb czy ssh. Drugą ważną właściwością rsync jest możliwość archiwizacji starych kopii plików, które zostały zmodyfikowane lub usunięte. Istnieje zdecydowanie zbyt wiele właściwości aby je rozważać w tym artykule. Gorąco polecam lekturę rsync.samba.org.
Po krótce system ten składa się z taniej maszyny opartej na Linux'ie z masą tanich dysków i małym skryptem powłoki zwanym rsync. [Fig 1] Gdy archiwizujemy dane mówimy rsync aby stworzył katalog o nazwie 'YY-DD-MM' jako miejsce do przechowywania zmian. Następnie rsync sprawdza czy na serwerach które archiwizujemy zaszły jakieś zmiany. Jeśli jakiś plik uległ zmianie stara wersja jest kopiowana do wczesniej opisanego katalogu, a poźniej nadpisuje plik w głównym katalogu z archwizowanymi danymi. [Fig 2]
Ogólnie dzienne zmiany stanowią mały procent całego systemu plików. Wg moich testów wartość ta zwykle wacha się w przedziale 0.5% do 1%. Dlatego też z zestawem dysków o rozmiarze dwukrotnie większym od naszych archiwizowanych systemów możesz przechować około 50-100 dni zmian. Gdy dysk staje się pełny po prostu podepnij nowy zestaw dysków, a stare odepnij. W praktyce jest możliwe przechowanie ponad sześciu miesięcy zmian na dysku. Właściwie jeśli znajdziesz gdzieś miejsce możesz skopiować archiwizowane dane na inny serwer zanim zmienisz dyski. W ten sposób możesz przechować całkiem dużą liczbę katalogow zmian na dysku.
Wróćmy do powyższej, wyimaginowanej rozmowy. Wyobraź sobie teraz, że zamiast nieporęcznego systemu opartego o taśmy masz system oparty o Linux'a z czekającymi na Ciebie danymi z ostatnich sześciu miesięcy. Używając Twojej ulubionej kombinacji locate/find/grep możesz znaleźć wszystkie pliki należące do danego użytkownika zawierające 'e' z datą czwartek luty bądź kwiecień i zrzucić je do katalogu tego wlaśnie użytkownika. Problem w znalezieniu, która z wersji jest waściwa to jeden z moich ulubionych rodzajów problemu: to nie mój problem.
Nstępnie wyobraź sobie nasz ulubiony scenariusz - całkowita utrata danych. Powiedzmy, że masz wielki serwer nfs/samba, który tracisz. Jeśli zarchiwizowałeś pliki konfiguracyjne samby możesz przywrócić serwer jako chwilowo tylko do odczytu w parę minut. Chciałbym zobaczyć jak to robisz z taśmami.
| Archiwizacja na taśmie | Rsync | |
|---|---|---|
| Koszt | Bardzo duży | Mały |
| Pełna archiwizacja | Szybko | Szybko |
| Archiwizacja zmian | Szybko | Szybko |
| Pełne odzyskiwanie systemu | Bardzo wolno, prawdopodownie wiele taśm | Szybko - wszystko jest na dysku |
| Przywracanie plików | Powoli, może wiele taśm, często problem ze znalezieniem właściwej wersji. | Bardzo szybko - wszystko jest na dysku, a na dodatek masz pod ręką narzędzia systemu UN*X jak: find, grep i locate |
| Całkowita utrata danych | Jednyna możliwość to pełne odzyskiwanie systemu | Może zostać przywrócony jako serwer plików w parę minut |
Istnieje wiele kombinacji konfiguracji systemu archiwizacji. Wszystkie narzędzia są open-source, zawarte standardowo w dystrybucjach i bardzo elastyczne. Opiszemy tutaj jedną z wielu możliwości konfiguracji.
Podstawowa wersja tego skryptu pochodzi ze strony rsync. Jest to naprawdę jedno polecenie:
rsync --force --ignore-errors --delete --delete-excluded --exclude-from=exclude_file --backup --backup-dir=`date +%Y-%m-%d` -av
Kluczowe opcje to:
Poniższy skrypt może być odpalany co noc użwając linux'owego cron. Aby skrypt był uruchamiany o 23 co noc użyj polecenia "crontab -e", a potem wpisz to:
0 23 * * * /ścieżka/do/twojego/skryptu
Oto mój skrypt powłoki wiążący to wszystko w całość. Znowu istnieje wiele sposobów na zrealizowanie tego. Jest to tylko jedna z implementacji.
#!/bin/sh
#########################################################
# Script to do incremental rsync backups
# Adapted from script found on the rsync.samba.org
# Brian Hone 3/24/2002
# This script is freely distributed under the GPL
#########################################################
##################################
# Configure These Options
##################################
###################################
# mail address for status updates
# - This is used to email you a status report
###################################
MAILADDR=your_mail_address_here
###################################
# HOSTNAME
# - This is also used for reporting
###################################
HOSTNAME=your_hostname_here
###################################
# directory to backup
# - This is the path to the directory you want to archive
###################################
BACKUPDIR=directory_you_want_to_backup
###################################
# excludes file - contains one wildcard pattern per line of files to exclude
# - This is a rsync exclude file. See the rsync man page and/or the
# example_exclude_file
###################################
EXCLUDES=example_exclude_file
###################################
# root directory to for backup stuff
###################################
ARCHIVEROOT=directory_to_backup_to
#########################################
# From here on out, you probably don't #
# want to change anything unless you #
# know what you're doing. #
#########################################
# directory which holds our current datastore
CURRENT=main
# directory which we save incremental changes to
INCREMENTDIR=`date +%Y-%m-%d`
# options to pass to rsync
OPTIONS="--force --ignore-errors --delete --delete-excluded \
--exclude-from=$EXCLUDES --backup --backup-dir=$ARCHIVEROOT/$INCREMENTDIR -av"
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin
# make sure our backup tree exists
install -d $ARCHIVEROOT/$CURRENT
# our actual rsyncing function
do_rsync()
{
rsync $OPTIONS $BACKUPDIR $ARCHIVEROOT/$CURRENT
}
# our post rsync accounting function
do_accounting()
{
echo "Backup Accounting for Day $INCREMENTDIR on $HOSTNAME:">/tmp/rsync_script_tmpfile
echo >> /tmp/rsync_script_tmpfile
echo "################################################">>/tmp/rsync_script_tmpfile
du -s $ARCHIVEROOT/* >> /tmp/rsync_script_tmpfile
echo "Mail $MAILADDR -s $HOSTNAME Backup Report < /tmp/rsync_script_tmpfile"
Mail $MAILADDR -s $HOSTNAME Backup Report < /tmp/rsync_script_tmpfile
echo "rm /tmp/rsync_script_tmpfile"
rm /tmp/rsync_script_tmpfile
}
# some error handling and/or run our backup and accounting
if [ -f $EXCLUDES ]; then
if [ -d $BACKUPDIR ]; then
# now the actual transfer
do_rsync && do_accounting
else
echo "cant find $BACKUPDIR"; exit
fi
else
echo "cant find $EXCLUDES"; exit
fi