Водич за прављење резервних копија базе података

- Ох, ниједно склониште не може да издржи удар метеорита. Али ви, као и сви остали, имате резерву, тако да не морате да бринете.

Станислав Лем, Звездани дневници Ијона Тихог

Резервна копија се односи на чување копије података негде изван њихове примарне локације за складиштење.

Главна сврха резервне копије је враћање података након што су изгубљени. С тим у вези, често чујете да ако имате реплику базе података, увек можете да вратите податке из ње и да нема потребе за резервном копијом. У ствари, резервна копија вам омогућава да решите најмање три проблема која се не могу решити помоћу реплике, а реплика се не може иницијализовати без резервне копије.

Прво, резервна копија вам омогућава да опоравите податке након логичке грешке. На пример, рачуновођа је избрисао групу трансакција или је администратор базе података уништио простор табеле. Обе операције су потпуно легалне са тачке гледишта базе података, а процес репликације ће их репродуковати у бази података реплика.

Друго, савремени ДБМС су веома поуздани софтверски системи, али повремено долази до оштећења интерних структура базе података, након чега се губи приступ подацима. Оно што је посебно увредљиво је то што се такво кршење обично дешава под великим оптерећењем или приликом инсталирања неке врсте ажурирања. Али и велико оптерећење и редовна ажурирања указују на то да база података ни у ком случају није тестна база података и да су подаци који се чувају у њој вредни.

Коначно, трећи задатак, за чије решење је потребна резервна копија, јесте клонирање базе података, на пример, за потребе тестирања.

Резервна копија базе података је на овај или онај начин заснована на једном од два принципа:

• Узорковање података и накнадно чување у прилагођеном формату;
• Снимак датотека базе података и чување дневника.

Хајде да ближе погледамо ове принципе и алате који их примењују.

Отпремање података

Скуп услужних програма укључених у било који ДБМС мора да садржи алате за отпремање и учитавање података. Подаци се чувају или у текстуалном формату или у бинарном формату специфичном за одређени ДБМС. Табела испод даје листу таквих алата:

Бинарни формат
Формат текста

пророчанство
ДатаПумп Екпорт/ДатаПумп Импорт
Екпорт-импорт
СКЛ*Плус/СКЛ*Лоадер

ПостгреСКЛ
пг_думп, пг_думпалл/пг_ресторе
пг_думп, пг_думпалл/пскл

Мицрософт СКЛ Сервер
бцп
бцп

ДБКСНУМКС
истоварити/утоварити
истоварити/утоварити

МиСКЛ

мисклдумп, мисклпумп/мискл, мисклимпорт

МонгоДБ
монгодумп/монгоресторе
монгоекпорт/монгоимпорт

Касандра
нодетоол снапсхот/сстаблелоадер
цклсх

Добра ствар у вези са текстуалним форматом је што га могу уређивати или чак креирати спољни програми, а бинарни формат је, заузврат, добар јер вам омогућава да брже отпремате и преузимате податке уштедом ресурса на конверзији формата.

Упркос једноставности и очигледности идеје преузимања података, овај метод се ретко користи за прављење резервних копија учитаних индустријских база података. Ево разлога зашто истовар није погодан за потпуну резервну копију:

• процес истовара ствара значајно оптерећење на изворном систему;
• истовар траје доста времена - до завршетка истовара више неће бити релевантно;
• Скоро је немогуће извршити координисано растерећење целе базе података под великим оптерећењем, пошто је ДБМС принуђен да чува снимак свог стања у тренутку када почиње истовар. Што је више трансакција завршено од почетка отпремања, то је већа величина снимка (небитне копије података у ПостгреСКЛ-у, поништавање простора у Орацле-у, темпдб у Мицрософт СКЛ Сервер-у, итд.);
• истовар чува логичку структуру података, али не чува њихову физичку структуру – параметре физичког складиштења табела, индекса итд.

Међутим, отпремање такође има своје предности:

• висока селективност: можете преузети појединачне табеле, појединачна поља, па чак и појединачне редове;
• преузети подаци се могу учитати у базу података друге верзије, а ако се преузимање врши у текстуалном формату, онда у другу базу података.

Дакле, отпремање се користи углавном за задатке као што је прављење резервних копија малих табела (на пример, директоријума) или дистрибуција скупова података са следећим издањем апликације.

Најчешћи метод прављења резервних копија базе података је копирање датотека базе података.

Хладно складиштење датотека базе података

Очигледна идеја је зауставити базу података и копирати све њене датотеке. Ова резервна копија се назива „хладна“ резервна копија. Метода је изузетно поуздана и једноставна, али има два очигледна недостатка:

• Из „хладне“ резервне копије можете само да вратите стање базе података које је било у време гашења; трансакције направљене након поновног покретања базе података неће бити укључене у „хладну“ резервну копију;
• Нема свака база података технолошки прозор када се база података може зауставити.

Ако вам одговара „хладна” резервна копија, морате то запамтити

• Хладна копија понекад мора укључивати дневнике. Методе за одређивање евиденција које треба да иду у „хладну” копију су индивидуалне за сваки ДБМС. На пример, у Орацле-у је потребно копирати такозвани онлајн редо, односно фиксни број лог фајлова у посебан директоријум, чак и када је база података исправно заустављена. У ПостгреСКЛ-у морате да сачувате све евиденције почевши од дневника који садржи последњу контролну тачку, информације о којој се налазе у контролној датотеци.
• Директоријум базе података може да садржи привремене датотеке простора табела које су довољно велике да не морају да буду укључене у резервну копију. Иначе, ова примедба важи и за вруће резервне копије.

Вруће чување датотека

Већина модерних резервних копија базе података се врши копирањем датотека базе података без заустављања базе података. Овде постоји неколико проблема:

• Када копирање започне, садржај базе података се можда неће подударати са садржајем датотека, јер се неке информације налазе у кешу и још нису записане на диск.
• Током копирања, садржај базе података се може променити. Ако се користе променљиве структуре података, садржај датотека се мења, а када се користе непроменљиве структуре, скуп датотека се мења: појављују се нове датотеке, а старе се бришу.
• Пошто уписивање података у базу података и читање датотека базе података нису ни на који начин синхронизовани, програм за прављење резервних копија може прочитати неисправну страницу, у којој ће половина бити из старе верзије странице, а друга половина из нове.

Да би резервна копија била конзистентна, сваки ДБМС има команду која обавештава да је процес прављења резервне копије почео. Синтактички, ова команда може изгледати другачије:

• у Орацле-у ово је посебна команда АЛТЕР ДАТАБАСЕ/ТАБЛЕСПАЦЕ БЕГИН БАЦКУП;
• у ПостгреСКЛ-у – функција пг_старт_бацкуп();
• У Мицрософт СКЛ Серверу и ДБ2, припрема за прављење резервне копије се изводи имплицитно током извршавања наредбе БАЦКУП ДАТАБАСЕ;
• у МиСКЛ Ентерприсе, Цассандра и МонгоДБ, припрему имплицитно обавља екстерни услужни програм - мисклбацкуп, ОпсЦентер и Опс Манагер, респективно.

Упркос синтаксичким разликама, процес припреме за резервну копију изгледа исто.

Овако изгледа припрема за прављење резервне копије у ДБМС-у са променљивим структурама диска, односно у свим традиционалним диск релационим системима:

1. Памти се тренутак покретања резервне копије; резервна копија ће морати да садржи евиденције базе података од овог тренутка па надаље.
2. Изводи се контролна тачка, то јест, све промене које су се десиле на страницама података пре запамћеног тренутка се испуштају на диск. Ово осигурава да евиденција није потребна пре него што резервна копија почне током опоравка.
3. Омогућен је посебан режим евидентирања: ако се страница са подацима променила први пут након учитавања са диска, онда ће уместо уписивања промена странице у дневник, база података уписати целу страницу тамо. Приликом извођења поступка припреме, све странице се испуштају на диск, тако да ће први пут када се направи промена, цео блок увек бити уписан у дневник. Али ако се страница поново избаци на диск током процеса прављења резервне копије, следећа промена на њој ће такође довести до тога да се пуна копија странице појави у евиденцији. Ово осигурава да ако се испостави да је страница нетачна приликом копирања датотеке са подацима, применом евиденције ће бити поново исправна.
4. Блокирају се промене заглавља датотеке са подацима, односно онај њен део чије промене се не одражавају у евиденцији. Ово осигурава да се заглавље исправно копира и да се евиденције правилно примењују на датотеку података.

Након што су све горе наведене процедуре завршене, можете копирати датотеке са подацима помоћу алата оперативног система - цп, рсинц и других. Омогућавање режима резервне копије смањује перформансе базе података: прво, повећава се обим евиденције, а друго, ако изненада дође до квара у режиму резервне копије, опоравак ће трајати дуже јер се заглавља датотека са подацима не ажурирају. Што се резервна копија брже заврши, то је боље за базу података, па је прикладно користити такве алате као што су снимак система датотека или разбијање огледала (БЦВ) у низу дискова. Неки ДБМС (Орацле, ПостгреСКЛ) остављају администратору могућност да самостално бира метод копирања, други (Мицрософт СКЛ Сервер) пружају интерфејс за интеграцију сопствених услужних програма за прављење резервних копија са системом датотека или механизмима складиштења.

Када се резервна копија заврши, потребно је да вратите базу података у њено нормално стање. У Орацле-у се то ради помоћу команде АЛТЕР ДАТАБАСЕ/ТАБЛЕСПАЦЕ ЕНД БАЦКУП, у ПостгреСКЛ-у позивањем функције пг_стоп_бацкуп(), ау другим базама података интерним рутинама одговарајућих команди или екстерних сервиса.

Ево како изгледа временска линија процеса прављења резервних копија:

• Припрема за резервну копију захтева време, понекад доста времена. Чак и ако се користе пресликани волумени или системи датотека који могу да снимају, процес прављења резервне копије неће бити тренутан.
• Уз фајлове са подацима, потребно је чувати евиденције од тренутка када почнете да припремате резервну копију до тренутка када се база података врати у нормално стање.
• Можете вратити из ове резервне копије у тренутку када се база врати у нормално стање. Враћање на ранију тачку није могуће.

Са базама података које користе непроменљиве структуре података (снимци меморије, ЛСМ стабла), ситуација је једноставнија. Припрема за прављење резервне копије састоји се од следећих корака:

1. Подаци из меморије се пребацују на диск.
2. Листа датотека укључених у резервну копију се снима. Док се процес прављења резервне копије не заврши, бази података је забрањено брисање ових датотека, чак и ако више нису потребне.

Након сигнала да је резервна копија завршена, база података са непроменљивим структурама може поново да обрише непотребне датотеке.

Опоравак до тачке

Резервна копија вам омогућава да вратите стање базе података до тренутка када је команда за повратак из режима резервне копије завршена. Међутим, несрећа која захтева опоравак може се десити у било ком тренутку. Задатак враћања стања базе података у произвољном тренутку назива се „опоравак у тренутку“.

Да бисте били сигурни да је то могуће, требало би да сачувате евиденције базе података почевши од краја прављења резервне копије, а током процеса опоравка наставите да примењујете евиденције на враћену копију. Након што се база података врати из резервне копије у тренутку када је копирање завршено, гарантовано је да је стање базе података (фајлови и кеширане странице) исправно, тако да посебан режим евидентирања није потребан. Применом евиденције у правом тренутку, можете добити стање базе података у било ком тренутку.

Док је брзина којом се резервна копија може вратити ограничена само пропусним опсегом диска, брзина којом се евиденције могу применити је обично ограничена перформансама процесора. Ако се промене дешавају паралелно у главној бази података, онда се током опоравка све промене изводе узастопно - редоследом којим се читају из евиденције. Дакле, време опоравка линеарно зависи од тога колико је тачка опоравка удаљена од крајње тачке резервне копије. Због тога је потребно доста често правити потпуне резервне копије – најмање једном недељно за базе података са малим оптерећењем трансакција и до дневних копија високо оптерећених база података.

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

Да бих до неке тачке убрзао опоравак, желео бих да могу да правим резервне копије што је могуће чешће, али да у исто време не заузимам додатни простор на диску и не учитавам базу података задацима резервне копије.

Решење проблема је инкрементална резервна копија, односно копирање само оних страница са подацима које су се промениле од претходне резервне копије.
Инкременталне резервне копије имају смисла само за ДБМС-ове који користе променљиве структуре података.

Повећање се може рачунати или од пуне резервне копије (кумулативна копија) или од било које претходне копије (диференцијална копија).

Нажалост, не постоји јединствена терминологија, а различити произвођачи користе различите термине:

диференцијални
Кумулативно

пророчанство
Диференцијал
Кумулативно

ПостгреСКЛ
Постепен
-

Мицрософт СКЛ Сервер
-
Диференцијал

ИБМ ДБ2
Делта
Постепен

Ако постоје инкременталне копије, процес враћања на тачку је следећи:

• последња потпуна резервна копија направљена пре обнављања;
• инкременталне копије се враћају на целу копију;
• евиденције се савијају од почетне тачке резервне копије до тачке опоравка.

Кумулативна копија убрзава процес опоравка. Тако, на пример, да бисте вратили стање базе података на тачку између Т3 и Т4, потребно је да вратите две инкременталне копије, а да вратите на тачку после Т4 само једну.
Очигледно, величина једне кумулативне копије је мања од величине неколико диференцијалних копија, јер су се неке странице мењале неколико пута, а свака инкрементална копија садржи другачију верзију странице.

Постоје три начина да направите инкременталну копију:

1. прављење пуне копије и израчунавање разлике са претходном пуном копијом;
2. анализирање дневника, креирање листе промењених страница и прављење резервних копија страница укључених у листу;
3. испитивање промењених страница у бази података.

Прва метода штеди простор на диску, али не смањује оптерећење базе података. Штавише, ако имамо потпуну резервну копију, њено претварање у инкременталну је бесмислено, јер је враћање потпуне резервне копије брже од враћања претходне потпуне резервне копије и инкременталне. Боље је делегирати задатак уштеде простора на диску овим приступом специјализованим компонентама са уграђеним механизмима за дедупликацију. То могу бити или наменски системи за складиштење (EMC DataDomain, HPE StorageWorks VLS, цела NetApp линија) или софтверски производи (ZFS, Veritas NetBackup PureFile, Windows Server Дедупликација података).

Друга и трећа метода се разликују по механизму за одређивање листе промењених страница. Парсирање дневника захтева више ресурса, плус да бисте га применили морате знати структуру датотека евиденције. Најлакши начин је да питате саму базу података које су странице промењене, али за то ДБМС кернел мора имати функцију праћења промена блокова.

Функција инкременталног прављења резервних копија је први пут представљена у софтверу Орацле Рецовери Манагер (РМАН), представљеном у издању Орацле 8и. Орацле је одмах имплементирао праћење промењених блокова, тако да нема потребе за рашчлањивањем дневника.

ПостгреСКЛ не прати модификоване блокове, па услужни програм пг_пробацкуп, који је развила руска компанија Постгрес Профессионал, утврђује измењене странице анализом дневника. Међутим, компанија такође испоручује ПостгресПро ДБМС, који укључује екстензију птрацк која прати промене страница. Када користите пг_пробацкуп са ПостгресПро ДБМС, услужни програм захтева промењене странице из саме базе података - потпуно исто као и РМАН.

Мицрософт СКЛ Сервер, као и Орацле, прати промењене странице, али команда БАЦКУП вам омогућава само да направите потпуне и кумулативне резервне копије.

ДБ2 има могућност праћења промењених страница, али је подразумевано онемогућена. Када се једном омогући, ДБ2 ће дозволити пуне, диференцијалне и кумулативне резервне копије.

Важна разлика између алата описаних у овом одељку (осим пг_пробацкуп) и алата за прављење резервних копија датотека је у томе што они захтевају слике страница из базе података уместо да сами читају податке са диска. Недостатак овог приступа је мало додатно оптерећење на бази. Међутим, овај недостатак је више него надокнађен чињеницом да је прочитана страница увек тачна, тако да нема потребе да се омогућава посебан режим евидентирања током прављења резервне копије.

Поново имајте на уму да присуство инкременталних копија не елиминише захтев да се евиденција има на располагању за опоравак до произвољног тренутка. Стога, у индустријским базама података, евиденције се стално преписују на спољне медије, а резервне копије, пуне и/или инкременталне, се креирају по распореду.

Најбоља имплементација идеје инкременталног резервног копирања данас је Zero Data Loss Recovery Appliance, хардверски и софтверски систем (у Oracle терминологији, инжењерски систем) – специјализовано Oracle решење за прављење резервних копија сопствене базе података. Систем је кластер. сервери ZDLRA има велике капацитете дискова и покреће модификовану верзију софтвера Recovery Manager. Може да ради са другим Oracle хардверским и софтверским системима (Database Appliance, Exadata, SPARC Supercluster), као и са Oracle базама података које раде на традиционалној инфраструктури. За разлику од „обичног“ RMAN-а, ZDLRA имплементира концепт „инкременталног заувек“. Систем креира комплетну копију базе података једном, а затим прави само инкременталне копије. Додатни RMAN модули вам омогућавају спајање копија, креирајући нове комплетне копије од инкременталних.

За част руских програмера, треба напоменути да пг_пробацкуп такође може да спаја инкременталне копије.

За разлику од многих сличних питања, питање „који је метод резервне копије бољи“ има јасан одговор - најбоља опција је услужни програм који се користи за ДБМС, који пружа могућност инкременталног прављења резервних копија.

За администратора базе података много су важнија питања избора стратегије прављења резервних копија и интеграције алата за прављење резервних копија базе података у корпоративну инфраструктуру. Али ова питања су ван оквира овог чланка.

Извор: ввв.хабр.цом