от NikDaPhreak(8-02-2007)

рейтинг (25)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

Здравейте,

това е първата ми статия за linux-bg.org и се надявам като ме освирквате, да не прекалявате с доматите и яйцата, че току виж се откажа да пиша ;-)

Уточнение: Използвайки идеите от тази статия можете волно или неволно да причините вреди на информацията си, на себе си или на трети лица. Предоставената информация работи за мен, на моите машини, но отказвам да нося отговорност за действията на други хора, дори те да са провокирани от текст, написан от мен. С други думи ако използвайки тази статия Ви изгори тостера, или изтриете GPS данните за навигация и паднат 5-6 самолета, вината е изцяло Ваша.

Така. След като си измих ръцете и мога да пиша спокойно глупости, ще започна с някои по-сериозни аспекти на проблема Backup.

Много широко разпространени са 2 неверни гледни точки:


1.На мен backup ми не требе! Язе съм sysadmin (заменете с L337 ако искате)

2.Ние ползваме RAID! Данните ни са на сигурно място!

Прекрасни твърдения, де да имаха някакво покритие... Светът щеше да е прекрасен!

В реалния свят обаче нещата не се случват както на нас ни се иска. Данни можем да загубим по 2 еднакво болезнени начина – да се повреди твърд диск (ако имаме късмет ще са поне 2 едновременно, случвало ми се е в RAID5 с 4 диска в рамките на 6-7 часа - 2 жертви) или да се счупи файловата система. И за двата варианта има реален шанс и по двата начина съм губил данни. Единственото смислено решение е адекватен backup.

Съществуват много варианти на много производители за комерсиални и безплатни решения. Проблемът е, че всички по-сериозни решения изискват поне един backup сървър. Изискват и бърза връзка към сървъра и какво ли още не. Всичко това е трудно постижимо за малки проекти, където така или иначе има един единствен сървър.

Целта на днешното ми писание не е да отрека целия този софтуер, а да покажа едно елегантно и пъргаво решение, което например в условията на сървър под наем някъде по света може да даде доста гъвкавост при реализирането на backups.

За реализирането на моето предложение е необходим сървър с достатъчно място за създаване и съхранение на архиви локално. След като бъдат създадени, копията от информацията могат да се възстановят дори с Midnight Commander от директорията, в която се съхраняват, да бъдат копирани през Интернет или локалната мрежа на друг компютър и след това да бъдат архивирани или на лента или на CD/DVD.

Малко теория – най-бързият начин за копиране на данни е от един твърд диск на същия или на друг диск в рамките на една и съща машина. (Ако ползвате по-бързи технологии по-добре направо се захващайте с Bacula – доста сериозно FOSS решение.) Разбира се копирането на всички файлове всеки ден ще изяде много бързо свободното място. Тук на помощ идват hard links. С две думи това са файлове, които адресират едно и също физическо място на твърдия диск. Или иначе казано данните на диска имат две или повече имена във файловата система. За разлика от soft links / symbolic links които само сочат към името на файла, който съдържа информацията, в случая имаме два напълно независими файла, сочещи към едни и същи данни.

Да обърнем теорията в един практически пример:

/etc/exports е файл, който не се променя често. Ако създадем папка /backups и в нея създаваме всеки ден по една папка, например day1/ day2/ day3/ и т.н. и копираме /etc/exports в тези папки, след 10 дни ще имаме 10 еднакви копия на файла, плюс оригинала, който така или иначе не се е променил. Ако вместо да копираме всеки ден този файл, ние създаваме по един нов hard link към физическото място на твърдия диск, което този файл заема, след 10 дни ще имаме 10 файла, които ще заемат място колкото 1 файл, но ще са достъпни в 10 различни директории.

След като вече имаме идея как да спестим място за файлове, които не се променят, нека отбележа, че ако сега променя някой от 10те файла, създадени като hard links, ще променя всички файлове.

Следващата стъпка е да преценим какво може и какво трябва да се архивира? Внимателно трябва да прецените коя информация от сървъра ще можете да възстановите с преинсталация, коя информация не е нужна (директория /tmp например) и коя информация трябва да бъде запазена на всяка цена, тъй като възстановяването и е или много трудоемко или много скъпо или практически невъзможно.

Взимайки под внимание всичко това, можем да създадем сравнително бързо и лесно архив на целия сървър по следния начин:

mkdir /backups

Ако ще ползваме отделен твърд диск, например /dev/hdc1: mount /dev/hdc1 /backups


mkdir /backups/`date +%Y%m%d`/

rsync -ap --exclude=/backups --exclude=/proc --exclude=/tmp –exclude /var/log /* /backups/`date +%Y%m%d`/

Така получаваме копие на всички директории освен /proc, /tmp, /var/log и /backups. Разбира се можете да добавите по желание още директории, които да се изключват от архива или да пазите само /home/* вместо /*. Доколко има смисъл да се пазят /usr, /bin, /sbin, /boot, /opt и други директории със статично съдържание, възстановимо при преинсталация, оставям на всеки да прецени сам за себе си.

Добре, напълнихме диска с още едно копие на всичко, което сме сметнали за нужно. Следващата стъпка е да накараме машинката да копира само нещата, които са нови и да не заема още дисково пространство с непроменени файлове. Като знаем идеята на hard links не е трудно да го реализираме:

0. За да можем да тестваме, трябва да имаме архив от предишния ден. Най-простия начин да го създадем е:

mv backups/`date +%Y%m%d`/ /backups/`date -d$(( `date +%Y%m%d` - 1 )) +%Y%m%d`/

Разбира се ако вече има архив от предишния ден, горната команда не е нужно да се изпълнява.

1. Създаваме папка за актуалния backup и копираме съдържанието на папката с backup от предния ден:

cp -al /backups/`date -d$(( `date +%Y%m%d` - 1 )) +%Y%m%d`/* /backups/`date +%Y%m%d`/

Горният ред създава само hard links без да копира физически данните.

2. Копираме промените:

rsync -ap --delete --exclude=/backups --exclude=/proc --exclude=/tmp /* /backups/`date +%Y%m%d`/

За да сме сигурни, че всичко е копирано и няма отворени файлове е хубаво да спрем услугите, които имат навика да кешират в паметта, вместо да пишат по диска, както и да изпълним командата sync преди да копираме промените. Особено внимание обърнете на базите данни. За да работят бързо, всички бази данни пазят много информация в кеш в оперативната памет и я записват когато има възможност. Някои бази данни идват със собствени скриптове за backup, други трябва да бъдат спрени, за да не загубите данни.

След като сте тествали всичко можете да запишете командите в bash script, който да добавите в crontab. Не забравяйте да проверите на следващия ден дали всичко е изпълнено без грешка. Най-неприятната изненада е заблудата, че имате копие от всичко важно и копието се окаже развалено.

Така създадените копия могат да се пазят на сървъра докато се запълни цялото свободно място или докато се изчерпат свободните inodes. За да не се случи това е необходимо всеки ден да се изтрива най-старото копие, ако е по-старо от да речем 10 дни. За целта в скрипта можете да използвате следната команда:

rm -rf /backups/`date -d$(( `date +%Y%m%d` - 10 )) +%Y%m%d`

До тук добре. Сега остава да синхронизираме копията на сървъра с тези на друга машина, по възможност на друго физическо място.

Ако все още нямаме отделна директория за архиви на втората машина, създаваме такава. Ако ще съхраняваме архивите от повече машини, можем да създадем /backups/REMOTE, където REMOTE е или IP адреса или името на отдалечената машина, чиито архивирани данни ще съхраняваме.

rsync -apH --exclude=/backups --exclude=/proc --exclude=/tmp REMOTE:/* /backups/REMOTE/`date +%Y%m%d`/

Препоръчвам Ви да изпълните първо командата:

cp -al /backups/REMOTE/`date -d$(( `date +%Y%m%d` - 1 )) +%Y%m%d`/* /backups/REMOTE/`date +%Y%m%d`/

за да създадете повечето hard links на локалната машина и да намалите количеството данни, които rsync трябва да прехвърли.

В горните команди отново трябва да заменим REMOTE с IP адреса или името на отдалечената машина, чиито архиви ще съхраняваме.

След като вече имаме копие на данните от отдалечената, не е лошо да запишем по-важните на CD, DVD или лента.

Предимства на така предложения метод:

1. Данните могат да се възстановят много лесно и бързо, при нужда дори от грамотен Linux потребител.

2. Ако виждате файловете, то архивът най-вероятно е възстановим. В този ред на мисли колко често проверявате лентите или CD / DVD дали всичко е записано както трябва?

3. Минимално време за създаване на копието върху сървъра, което свежда до минимум времето, през което определени услуги на сървъра трябва да са спрени (за да няма счупени файлове) и съответно няма да са достъпни.

4. Не се налага използването на по-сложен софтуер и на допълнителен сървър, който да управлява архивирането на данни.

Капани, уловки и други неприятни изненади, с които можете да се сблъскате, ползвайки този метод за архивиране на данни:

1. Не забравяйте, че при това решение ще трябва много място на твърдия диск. Ако ще създавате копие на същия диск и свободното дисково пространство е по-малко от 60% по-добре не се захващайте. Ще препълните диска много бързо и ще останете разочаровани.

2. Счупени бази данни. Повечето SQL сървъри ползват кеш в оперативната памет, за да оптимизират скоростта на четене и писане от и в базата данни. За архивиране на базите данни ползвайте софтуерните решения, препоръчани от създателите на съответната база данни или спирайте базата данни преди да създадете архив на нейните файлове по гореописания начин.

3. Проблем може да се появи и ако сте използвали много inodes – адреси на файлове. Проблем може да се появи ако пазите backup в продължение на 10 дни и сте използвали повече от 9% (100%/(10дни+оригинални данни)=100%/11=9,09%) от inodes на диска, при копиране на същия диск или нямате поне 10 пъти повече свободни inodes на допълнителния диск, който ползвате.

4. Не прекалявате с информацията, която архивирате. Няма смисъл да копирате по мрежата или през Интернет изпълнимите файлове, които се инсталират при преинсталация на системата. Ако се наложи да възстановявате данни от разстояние, то тези файлове вече ще са инсталирани.

5. Не забравяйте, че всички команди в тази статия трябва да се изписват на един ред или да се използва „“ за пренасяне на командата на нов ред.

И една хитрост за тези, които имат повече опит с Linux – има вариант да се ползват атрибути на файла и да се ползва Copy On Write за да се спести още място при създаването на първия backup и да се избегне случайното унищожаване на всички копия при промяна на едно. В тази ситуация създайте първото копие с cp -al вместо rsync.



<< | Правене на архиви по "лесния начин" >>