Центрове За Данни

Правилното резервиране пести време, пропускателна способност, пространство

Владимир Владков

Едно от основните неща, които трябва да се разберат за създаването на резервни копия (backup) и възстановяване, е концепцията за нивата на резервиране и какво точно означават те. Без правилно разбиране на онова, което представляват нивата и как точно работят те, компаниите биха се опрели на лоши практики. Тези практики варират от излишно натоварване на пропускателните канали за връзка към системите за съхранение (особено ако са облачно базирани и се плаща за WAN линии), през похабяване на ресурсите на тези системи с излишни данни до липсата на важни данни в тези резервни копия. Разбирането на тези концепции е критично, когато се избират нови продукти или услуги за защита на данните.

Пълно резервно копиране (Full backup)

Пълното резервно копие съдържа всички данни от цялата система. Пълното резервиране на диск C:\ в Windows съдържа всеки файл на този диск C. Пълно резервиране на Windows система би трябвало да съдържа копие на всеки файл от всеки диск в машината или виртуалната машина VM (например C:\, D:\, F:\ и т.н.). Същото се случва с пълното резервно копиране на UNIX или Linux машина; то съдържа всеки файл от всяка файлове система на машината (например  /home, /opt, и т.н.).

Единственото нещо, което трябва да бъде изключено от пълно резервно копие, са файловете, които са специално изключени при конфигурирането. Например много системни администратори избират да изключват директории, които няма да имат никаква стойност по време на възстановяване (например / Boot или / dev) или съдържат преходни файлове (например C:\Windows\TEMP в Windows или /tmp в Linux).

Има две философии, които разглеждат какви файлове трябва да бъдат включени или изключени от резервното копиране: резервиране на всичко и изключване на онова, от което знаете, че нямате нужда, или избирате само това, което искате да архивирате. Първият подход е по-безопасен вариант, но вторият ще спести пространство в резервната ви система. Някои хора смятат за излишно да правят резервни копия на файловете на приложенията, например директорията, в която сте заредили Oracle или SQL Server. Те смятат, че просто ще презаредят приложението по време на възстановяване.

Рискът при този подход е, че някой ще постави ценни данни в директория, която не е избрана за резервно копиране. Например, ако изберете само /home1 или D:\Data, които да бъдат резервирани, как системата за резервиране ще знае, че някой е добавил /home2 или E:\Data? Ето защо е много по-безопасно да направите резервно копие на всичко и да изключите само файловете, от които наистина не се нуждаете, дори това да отнеме известно допълнително място на дисковете. Изключение от това правило може да има, ако разполагате със силно контролирана среда, в която всички данни винаги се зареждат на едно и също място и имате добре оркестрирано решение за замяна на операционната система и приложенията при възстановяването.

Инкрементално резервиране

Инкременталното резервиране обикновено прави резервно копие на всички данни, които са променени след последното копиране. В исторически план такива резервни копия са били копия на файлове, което означава, че те правят резервно копие на всички файлове, които са се променили от последното копиране. Предизвикателството от гледна точка на модерната защита на данните е, че се опитваме по всякакъв начин да минимизираме влиянието на I/O операциите върху резервирането на сървъра (особено при резервно копиране на виртуални машини - VM) и да правим копие на 10 GB файл само защото е променен само 1MB, не е много ефективно.

Ето защо много производители преминават към инкрементално резервно копиране, базирано на блокове, като се прави ново копие само на променените блокове. Най-често срещаният метод за тази операция е, когато софтуерни продукти за бекъп правят резервно копие на VMware или Hyper-V, използвайки техните API интерфейси. Приложението уведомява съответния API интерфейс, че прави инкрементално блоково базирано копие, след което му „подава“ списък с блоковете, които трябва да се копират. 

Диференциално резервно копиране

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

Ако все още правите резервни копия на лента, помислете за този подход: преминете от седмични пълни копия към месечни пълни, седмични диференциални и ежедневни инкрементални. Възстановяването ще трябва да зареди още едно резервно копие, вместо да се товари всяка седмица пълен архив. Това спестява огромно количество лентов ресурс и мрежов трафик. Методът е доста популярен сред онези организации, които все още използват лентови библиотеки.

Завинаги инкрементално

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

Архивен бит

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

Много привърженици на резервното копиране не харесват архивния бит, макар и само защото той трябвало да се нарича резервен бит - тъй като резервните копия не са архиви. Другите проблеми с архивния бит включват факта, че ако имате две приложения за бекъп, работещи едновременно, те ще се застъпват, изчиствайки архивния бит.

Преходът на повечето компании към виртуализация и използването на бекъп API интерфейси на виртуализационно ниво, последвано от използването на блоково базирано инкрементално резервно копиране, направи почти излишен архивния бит. Днес той се използва само в хост базирано резервно копиране, което става все по-рядко.





© Ай Си Ти Медиа ЕООД 1997-2019 съгласно Общи условия за ползване

X