За един малък домашен проект ми се наложи да измисля бекъп решение за кодовото хранилище и базата данни. Хрумнаха ми два бързи варианта:
- Закачам USB памет на щайгата и копирам там всекидневно експорти;
- Регистрирам в Google потребител за електронната им поща и пускам там бекъп-а по gmailfs.
Разбира се, като всеки уважаващ себе си програмист, нямам резервни USB стърчишки, особено ако трябва да ги завирам в архаична щайга (Celeron 433 MHz / HDD 20GB / RAM 512 MB) за постоянно. Трябва да поясня, че в Wikipedia не препоръчват gmail да се използва за бекъп – имат навика да трият акаунта при прекомерно използване, а и не се знае кога ще сменят API-то и ще угаснат файловете там.
Подминавам предупреждението и давам смело напред. Първо да идентифицирам какво точно ми трябва:
- Бекъп пространство – поща в gmail, към момента дават 2-3 GB, напълно достатъчно за случая;
- Скрипт за експорт на кодовите хранилища, по възможност да проверява дали има нови версии и ако няма да прескача стъпката с бекъпа;
- Скрипт за пълен експорт на PostgreSQL-а;
- Възможност за добро компресиране и силно криптиране на файловете – използвах 7z, видя ми се подходящ за случая;
- Пилешки познания по bash scripting (е нека и гурутата да се посмеят сега), обилно гарнирани с крушова водка. Последното е необходимо на автора за да си припомни bash-а, че рядко му се налага да злоупотребява с него…
След известно ръчкане настъпих и първите мотики:
- Използвам Ubuntu Gutsy Gibbon, към момента е dev версия. gmailfs-а при опит да се mount-не ме наплюва с 400: Bad Request. Това очевидно идва от гугълските сървъри, където някой нещо реже с флекс. По най-грубия възможен начин решавам проблема така: след известно взиране в python кода откривам, че грешката е в libgmail. Отивам на страницата на библиотеката, завирам се в cvs-а, от където измъквам топла-топла последната версия, само на два дена, милата. Грозно намазвам старата библиотека, намираща се в /usr/share/pycentral/python-libgmail/site-packages с тайната надежда, че когато поддържащия ubuntu-джия, обнови пакета, ще имам по-нова версия, ако ли не поне същата.
Разбира се, номера минава и вече имам достъп до gmail пощата. - gmailfs не се mount-на човешки (поне при мен), в резултат на което на нея не можах да използвам примерно mv
След още малко човъркане и двойно повече взиране в man страниците, изковах следните скриптчета:
svn_backup
#!/bin/bash
#Backup svn repos, alex [at] stanev.org
svnbase='/var/svn'
backup_target='/mnt/gmail'
svndump='/tmp/backup'
pass='archive_password'
wd=$PWD
cd $svnbase
for repo in $(ls -d */); do
repo=${repo%/}
svn info file://$svnbase/$repo > $svndump/$repo.curr
touch $svndump/$repo.last
if ! cmp -s $svndump/$repo.curr $svndump/$repo.last ; then
svnadmin dump -q $svnbase/$repo | 7z a -mx=9 -p$pass -si$repo $svndump/$repo.7z
if ! [[ -f $backup_target/$repo.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/$repo.7z -nt $backup_target/$repo.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/$repo$ext
else
ext='.7z'
rm $backup_target/$repo$ext
fi
cp $svndump/$repo.7z $backup_target/$repo$ext
mv -f $svndump/$repo.curr $svndump/$repo.last
rm $svndump/$repo.7z
fi
done
cd $wd
pg_backup
#!/bin/bash
#Backup postgre db, alex [at] stanev.org
backup_target='/mnt/gmail'
pgdump='/tmp/backup'
pass='archive_password'
sudo -u postgres pg_dumpall | 7z a -mx=9 -p$pass -sipostgres $pgdump/postgres.7z
if ! [[ -f $backup_target/postgres.7z ]] ; then
ext='.7z'
elif ! [[ -f $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
elif [[ $backup_target/postgres.7z -nt $backup_target/postgres.1.7z ]] ; then
ext='.1.7z'
rm $backup_target/postgres$ext
else
ext='.7z'
rm $backup_target/postgres$ext
fi
cp $pgdump/postgres.7z $backup_target/postgres$ext
rm $pgdump/postgres.7z
Накратко, горните упражнения правят следното:
svn_backup обикаля всички хранилища и изтегля информация за HEAD revision. Ако има промени се прави копие към директорията за бекъп. Тъй като в случая с gmailfs използваме отдалечена файлова система, отсреща се пазят по две копия на един и същи файл. При качване на следващия винаги се изтрива по-стария. Това повишава мижавата вероятност са имаме поне един цял файл, ако връзката се разпадне в момента на предаване.
За pg_backup е аналогично, с разликата, че там бекъпа винаги се изпълнява, без да се правят по-специални проверки.
Настройте вашите пътища, сменете паролата и сте почти готови!
Остава двете скриптчета да се назначат за периодично изпълнение и да проследим първите бекъпи.
За накрая пожелавам на никой да не му се налага да си спасява работата. *Винаги* тествайте обратния процес на възстановяване – периодично се уверявайте, че задната вратичка е достатъчно широка, за да можете да се измъкнете, когато се подпали къщичката ;)
Leave a Reply