12 уобичајених грешака при прављењу резервних копија база података

аутор Алексеј Ковјазин, 11. новембар 2015.

Преузми PDF (енглески) Овај чланак је првобитно био намењен програмерима и администраторима Firebird DBMS-а, али контакти са администраторима других база података су показали да је већина грешака заједничка и њима и да буквално сви налећу на готово исте камење. Ако можете нешто да додате на ову листу (чак и нешто специфично за одређени DBMS), контактирајте нас путем наше имејл адресе [email protected].

1. Брисање претходне резервне копије пре него што се направи нова резервна копија

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

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

Препоруке: не бришите претходну резервну копију пре него што се направи нова! (и не правите нову резервну копију у постојећу датотеку).

Препорука за Firebird: Постоји алат FBDataGuard укључен у HQbird (напредни дистрибутивни пакет Firebird-а) који брише најстарију резервну копију у историји тек након што се направи нова.

2. Преписивање постојеће базе података приликом враћања из резервне копије

Ова грешка је ређа, иако последице могу бити много горе. Ако резервна копија није верификована и испостави се да је оштећена (погледајте проблем 6), нећете имати ни претходну копију базе података ни важећу резервну копију.

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

Firebird има неку врсту заштите од ове грешке - неће бити могуће вратити базу података из резервне копије помоћу алата gbak ако је његов подразумевани прекидач -create укључен и ако наведено име датотеке указује на постојећу базу података. Нажалост, постоји начин да се заобиђе ова заштита: прекидач -rep и даље омогућава преписивање постојеће датотеке.

Препорука: никада не преписујте датотеку радне базе података без писаног налога вашег руководства.

Препорука за Firebird: Користите FBDataGuard јер он никада не преписује датотеку базе података.

3. Коришћење једностепеног прављења резервне копије/враћања без коришћења међуфазне резервне датотеке

Стандардни улазно/излазни токови омогућавају занимљив трик са многим DBMS-овима (укључујући Firebird): имплементацију стриминг резервне копије са тренутним враћањем базе из ње. Као резултат, не ствара се међуфазна резервна датотека. То је згодно за рутинско одржавање и за покретање тестног враћања (под условом да постоји друга резервна копија), али не смете то користити за аутоматско прављење резервних копија!

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

Препоруке: не користите једностепено прављење резервне копије/враћање у аутоматском режиму и увек проверавајте доступност довољно ажурне копије у ручном режиму.

4. Чување резервних копија и базе података на истом физичком уређају

Многима од вас може бити смешно што је савет који дајемо помало детињаст - АБЦ резервног копирања. Тачно је, али база података и диск могу завршити на истом систему за чување података због популарности виртуелних окружења. И сигурно ће отказати у најнеповољнијем тренутку. Поред тога, још увек има људи који верују да се њиховим подацима ништа не може догодити ако користе RAID низове (верзија 1 или виша :)). Осим тога, постоје људи који верују да су неки “брендирани” сервери отпорни на грешке, али то је посебан случај.

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

5. Нема контроле над успешним завршетком процеса прављења резервне копије

То је прилично честа грешка и међу администраторима и међу руководиоцима ИТ одељења. Ако не проверавате резултате процеса прављења резервне копије, могли бисте и да га уопште не радите. Морате примати обавештења о успешно завршеном процесу прављења резервне копије путем имејла или, још боље, и путем СМС порука. А одсуство таквих обавештења је знак проблема!

Пажљив читалац који је стигао до ове тачке у нашем чланку (иако је још рано за награду) може да пита: ‘Али какве то има везе са руководством?’ Ево какве - администратор обично конфигурише процес прављења резервне копије, али му је превише досадно да проверава обавештења, посебно када су смештена у посебну фасциклу, па никада није лоше затражити додатне извештаје о статусу процеса. То је у вези са питањем ко је крив када се чини да резервне копије постоје, а заправо их нема у тренутку када су вам потребне :)

! када се комбинује са проблемом 2, немамо ни базу података ни њену резервну копију.

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

Препорука за Firebird: FBDataGuard проверава да ли је процес прављења резервне копије завршен и шаље одговарајуће обавештење. За системе са много база података постоји збирни мониторинг другог нивоа помоћу алата Control Center који вам омогућава да видите статусе свих надгледаних сервера и база података на једној страници.

6. Нема валидације резервне копије

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

Зато морате редовно верификовати резервне копије које правите како бисте били сигурни да нису оштећене или копиране у /dev/null.

Препорука за Firebird: можете аутоматизовати валидацију резервних копија помоћу FBDataGuard-а.

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

Обично базе података користе неколико врста резервног копирања - дампове, редовне резервне копије итд. Не улазећи у детаље, можемо издвојити две категорије: верификоване и неверификоване. У случају Firebird-а, то су gbak и nbackup.

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

Nbackup (познат и као инкрементално прављење резервне копије) привремено закључава главну датотеку базе података за ажурирања (у конзистентном стању) и омогућава брзо копирање датотеке базе (у потпуности или делимично/инкрементално).

У случају великих Firebird база података (већих од 500 GB), препоручљиво је користити nbackup како се не би успоравале корисничке операције, али је истовремено неопходно валидирати базу јер су неверификоване резервне копије које он ствара копије страница базе и ако грешка постоји на нивоу записа (због квара RAM меморије) или на логичком нивоу, неверификована резервна копија ће је садржати као и оригинална база.

Да бисте то избегли, требало би да користите онлајн валидацију оригиналне базе података (онлајн валидација уз помоћ gfix-а доступна је од Firebird верзије 2.5.4, док наш FBDataGuard алат подржава онлајн валидацију базе података за верзије 1.5-2.5).

Такође, препоручљиво је да повремено обављате верификовану резервну копију (на пример, једном недељно) поред неверификоване резервне копије.

Препорука за Firebird: поред онлајн провере здравља, FBDataGuard вам омогућава да тестирате процес враћања резервне копије у аутоматском режиму.

8. Нема контроле над слободним простором за резервне копије

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

У комбинацији са проблемом 4, најбољи могући исход биће онај када систем престане да функционише јер база података такође захтева слободан простор, али је он заузет резервним копијама. Што се тиче комбинације са проблемима 5 и 2, то нас опет оставља без базе података и без њене резервне копије.

Препоруке: користите алате за резервне копије који предвиђају величину резервне копије и упозоравају вас на могући недостатак слободног простора.

Препорука за Firebird: FBDataGuard контролише величину слободног простора за потребе резервних копија, као и величину слободног простора на диску са базама података и на системском диску.

9. Нема контроле над временом потребним за креирање резервне копије

Процес резервног копирања трајао је 40 минута буквално пре пола године, а онда одједном траје већ три сата - зашто је то тако? Величина базе података је можда порасла или је диск испао из вашег RAID низа, што је резултирало знатно споријим перформансама уписа, и све ваше резервне копије можда ће ускоро нестати. Или је ваш добар колега можда покренуо још један систем за резервно копирање у исто време (узгред, Firebird вам омогућава да покренете неколико процеса резервног копирања одједном, иако није сасвим јасно зашто би то некоме уопште било потребно). Ако не контролишете време потребно за прављење резервне копије, можете превидети новонастали проблем и пропустити прилику да га решите пре него што постане масовни.

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

Препоруке: користите алате који контролишу време које процес резервног копирања захтева!

Препорука за Firebird: FBDataGuard контролише време које процес резервног копирања захтева.

10. Резервно копирање базе података док се примењују ажурирања оперативног система

То је веома чест проблем, посебно у комбинацији са проблемом 9 и омогућеним аутоматским Windows ажурирањима (подразумевано, ажурирања се примењују у 3 сата ујутру). То у најбољем случају доводи до успоравања, али ако се оперативни систем поново покрене како би се применила ажурирања, резервна копија ће бити оштећена. Барем је добра вест то што се оперативни систем не ажурира сваког дана.

Препоруке: закажите ажурирања оперативног система када не ометају процес резервног копирања.

11. Резервно копирање базе података помоћу алата за резервно копирање датотека или алата за резервно копирање виртуелних машина док је сервер базе података покренут

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

Виртуелне машине могу користити механизме снимака (snapshots) и праћења промењених блокова (Changed Block Tracking), али је неопходно синхронизовати креиране резервне копије како бисте добили конзистентну резервну копију базе података, јер ће резервна копија бити неконзистентна у случају било каквих активних операција уписа у базу података у тренутку сортирања колекције промењених блокова.

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

1. потпуно зауставити DBMS услуге и процесе тако да у кешу не остане ништа,
2. користити агенте и/или скрипте који пребацују базу података у посебан режим који чини безбедним секвенцијално копирање датотеке базе података. На пример, постоји механизам назван VSS writer за MSSQL базе података. На захтев, он пребацује базу података у режим погодан за снимке у тренутку када се снимак прави. Ако користите механизме засноване на праћењу промењених блокова, сами треба да се побринете да база података буде конзистентна у тренутку синхронизације.

Ако не пребаците базу података у режим погодан за резервно копирање, резултујућа копија базе података ће изгледати као да се на рачунару домаћину догодио тврди ресет (на пример, нестанак струје). Овај ниво поузданости је апсолутно недовољан за већину предузећа. Више о томе можете сазнати у чланку „Посебности рада са базама података на виртуелним машинама".

За Firebird, неопходно је закључати главну датотеку базе података помоћу nbackup-а пре него што процес резервног копирања почне и откључати је након што се процес заврши. За друге DBMS-ове постоје слични алати за укључивање/искључивање одговарајућих режима.

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

Корени овог погрешног схватања су јасни: агресивно оглашавање од стране програмера виртуелних машина и алата за резервно копирање обично не помиње да базе података, као и друге интензивно ажуриране датотеке, захтевају напредну конфигурацију. Не верујте хajпу - нису сви јогурти једнако корисни.

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

Препорука за Firebird: користите FBDataGuard (из HQbird дистрибутивног пакета), који пружа интеграцију са алатима за резервно копирање који подржавају VSS.

12. Замена резервног копирања репликацијом

Резервно копирање података и репликација података користе се за повећање поузданости и спречавање губитка података, али ипак су прилично различити.

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

Препоруке: Ако имате конфигурисану репликацију, не занемарујте резервне копије, користите обоје.

Препорука за Firebird: користите HQbird Enterprise дистрибутивни пакет, који укључује и алате за резервно копирање и репликацију.

Резиме

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

За Firebird (извините због рекламе) постоји пакет под називом HQbird који укључује FBDataGuard.

Такође, наша компанија пружа комплетну подршку за резервно копирање и одржавање Firebird-а и других база података; ово је добар избор за оне који нису упознати са свим техничким детаљима резервног копирања.

И, наравно, наставите да негујете своју администраторску параноју, на пример, устаните и проверите своје резервне копије одмах сада :)

Контакти

Слободно постављајте питања: [email protected]

Желите да добијате вести и чланке о Firebird-у? Придружите нам се на Telegram-у https://t.me/firebirdsql