Овом напоменом се завршава циклус око прављења резервних копија. Разговараће се о логичкој организацији наменског сервера (или ВПС-а), погодног за прављење резервних копија, а такође ће се понудити опција за брзо враћање сервера из резервне копије без много застоја у случају катастрофе.
Необрађени подаци
Наменски сервер најчешће има најмање два чврста диска који служе за организовање РАИД низа (огледала) првог нивоа. Ово је неопходно да бисте могли да наставите са радом сервера ако један диск поквари. Ако је ово обичан наменски сервер, може постојати посебан хардверски РАИД контролер са активном технологијом кеширања на ССД-у, тако да поред обичних чврстих дискова може да се повеже један или више ССД-ова. Понекад се нуде наменски сервери у којима су једини локални дискови САТАДОМ (мали дискови, структурно флеш диск повезан са САТА портом), или чак обичан мали (8-16ГБ) флеш диск повезан на посебан интерни порт, а подаци се преузимају из система за складиштење података, повезани преко наменске мреже за складиштење података (Етхернет 10Г, ФЦ, итд.), а постоје наменски сервери који се учитавају директно из система за складиштење података. Нећу разматрати такве опције, јер у таквим случајевима задатак прављења резервне копије сервера глатко прелази на специјалисте који одржава систем за складиштење; обично постоје различите власничке технологије за креирање снимака, уграђену дедупликацију и друге радости администратора система , о којој је било речи у претходним деловима ове серије. Обим дисковног низа наменског сервера може да достигне неколико десетина терабајта, у зависности од броја и величине дискова повезаних са сервером. У случају ВПС-а, запремине су скромније: обично не више од 100 ГБ (али их има и више), а тарифе за такав ВПС лако могу бити скупље од најјефтинијих наменских сервера са истог хостера. ВПС најчешће има један диск, јер ће се испод њега налазити систем за складиштење података (или нешто хиперконвергирано). Понекад ВПС има неколико дискова са различитим карактеристикама, за различите сврхе:
- мали систем - за инсталирање оперативног система;
- велики - чување корисничких података.
Када поново инсталирате систем помоћу контролне табле, диск са корисничким подацима се не преписује, већ се системски диск потпуно поново пуни. Такође, у случају ВПС-а, хостер може понудити дугме које прави снимак стања ВПС-а (или диска), али ако инсталирате сопствени оперативни систем или заборавите да активирате жељену услугу унутар ВПС-а, неки података се и даље може изгубити. Поред дугмета, обично се нуди и услуга складиштења података, најчешће веома ограничена. Обично је ово налог са приступом преко ФТП-а или СФТП-а, понекад заједно са ССХ-ом, са смањеном љуском (на пример, рбасх) или ограничењем покретања команди преко аутхоризед_кеис (преко ФорцедЦомманд).
Наменски сервер је повезан са мрежом преко два порта са брзином од 1 Гбпс, понекад то могу бити картице са брзином од 10 Гбпс. ВПС најчешће има један мрежни интерфејс. Дата центри најчешће не ограничавају брзину мреже унутар дата центра, већ ограничавају брзину приступа Интернету.
Типично оптерећење таквог наменског сервера или ВПС-а је веб сервер, база података и сервер апликација. Понекад се могу инсталирати разне додатне помоћне услуге, укључујући веб сервер или базу података: претраживач, систем поште итд.
Посебно припремљен сервер служи као простор за чување резервних копија, о чему ћемо детаљније писати касније.
Логичка организација диск система
Ако имате РАИД контролер или ВПС са једним диском, а нема посебних преференција за рад подсистема диска (на пример, одвојени брзи диск за базу података), сав слободан простор је подељен на следећи начин: једна партиција се креира, а на врху се креира ЛВМ група волумена, у њој се креира неколико волумена: 2 мала исте величине, који се користе као основни систем датотека (промењени један по један током ажурирања ради могућности брзог враћања, идеја је преузета из Цалцулате Линук дистрибуције), друга је за свап партицију, остатак слободног простора је подељен на мале волумене, користи се као основни систем датотека за пуноправне контејнере, дискове за виртуелне машине, фајл системи за налоге у /хоме (сваки налог има свој систем датотека), систем датотека за контејнере апликација.
Важна напомена: свеске морају бити потпуно самосталне, тј. не би требало да зависе једно од другог или од основног система датотека. У случају виртуелних машина или контејнера, ова тачка се посматра аутоматски. Ако су ово контејнери апликација или кућни директоријуми, требало би да размислите о одвајању конфигурационих датотека веб сервера и других услуга на такав начин да елиминишете зависности између волумена што је више могуће. На пример, свака локација се покреће од сопственог корисника, датотеке конфигурације сајта су у корисничком кућном директоријуму, у подешавањима веб сервера, конфигурационе датотеке сајта нису укључене преко /етц/нгинк/цонф.д/.цонф и, на пример, /хоме//цонфигс/нгинк/*.цонф
Ако постоји неколико дискова, можете креирати софтверски РАИД низ (и конфигурисати његово кеширање на ССД-у, ако постоји потреба и прилика), на врху којег можете изградити ЛВМ према горе предложеним правилима. Такође у овом случају можете користити ЗФС или БтрФС, али треба двапут размислити о томе: оба захтевају много озбиљнији приступ ресурсима, а осим тога, ЗФС није укључен у Линук кернел.
Без обзира на шему која се користи, увек је вредно унапред проценити приближну брзину писања промена на дискове, а затим израчунати количину слободног простора који ће бити резервисан за креирање снимака. На пример, ако наш сервер пише податке брзином од 10 мегабајта у секунди, а величина читавог низа података је 10 терабајта - време синхронизације може да достигне један дан (22 сата - ово је колико ће се такав волумен пренети преко мреже 1 Гбпс) - вреди резервисати око 800 ГБ. У стварности, цифра ће бити мања; можете је безбедно поделити бројем логичких волумена.
Уређај сервера за складиштење резервних копија
Главна разлика између сервера за чување резервних копија је велики, јефтини и релативно спори дискови. Пошто су савремени ХДД-ови већ прешли границу од 10ТБ на једном диску, неопходно је користити системе датотека или РАИД са контролним збировима, јер током реконструкције низа или рестаурације система датотека (неколико дана!) други диск може отказати због тога што је дошло до квара другог диска. до повећаног оптерећења. На дисковима капацитета до 1ТБ ово није било тако осетљиво. Ради једноставности описа, претпостављам да је простор на диску подељен на два дела приближно једнаке величине (опет, на пример, користећи ЛВМ):
- волумени који одговарају серверима који се користе за складиштење корисничких података (последња направљена резервна копија ће бити распоређена на њима ради верификације);
- волумени који се користе као БоргБацкуп спремишта (подаци за резервне копије ће ићи директно овде).
Принцип рада је да се за сваки сервер креирају посебни волумени за БоргБацкуп репозиторије, где ће ићи подаци са борбених сервера. Спремишта раде у режиму само додавања, што елиминише могућност намерног брисања података, а због дедупликације и периодичног чишћења спремишта из старих резервних копија (остају годишње копије, месечно за прошлу годину, недељно за последњи месец, дневно за прошле недеље, могуће у посебним случајевима - сваки сат за последњи дан: укупно 24 + 7 + 4 + 12 + годишње - приближно 50 копија за сваки сервер).
БоргБацкуп спремишта не омогућавају режим само додавања; уместо тога, ФорцедЦомманд у .ссх/аутхоризед_кеис се користи отприлике овако:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Наведена путања садржи скрипту омотача на врху борга, која, поред покретања бинарне датотеке са параметрима, додатно покреће процес враћања резервне копије након уклањања података. Да би то урадила, скрипта омотача креира датотеку ознаке поред одговарајућег спремишта. Последња направљена резервна копија се аутоматски враћа на одговарајући логички волумен након што се процес попуњавања података заврши.
Овај дизајн вам омогућава да повремено чистите непотребне резервне копије, а такође спречава борбене сервере да избришу било шта на серверу за складиштење резервних копија.
Бацкуп Процесс
Иницијатор резервне копије је наменски сервер или сам ВПС, пошто ова шема даје већу контролу над процесом прављења резервне копије на делу овог сервера. Прво се прави снимак стања активног основног система датотека, који се монтира и отпрема помоћу БоргБацкуп-а на сервер за складиштење резервних копија. Након што је снимање података завршено, снимак се уклања и брише.
Уколико постоји мала база података (до 1 ГБ за сваки сајт), прави се думп базе података, који се чува у одговарајућој логичкој запремини, где се налази и остатак података за исти сајт, али тако да је думп није доступно преко веб сервера. Ако су базе података велике, требало би да конфигуришете „вруће“ уклањање података, на пример, користећи ктрабацкуп за МиСКЛ, или радите са ВАЛ-ом са арцхиве_цомманд у ПостгреСКЛ-у. У овом случају, база података ће бити враћена одвојено од података о локацији.
Ако се користе контејнери или виртуелне машине, требало би да конфигуришете кему-гуест-агент, ЦРИУ или друге неопходне технологије. У другим случајевима, додатна подешавања најчешће нису потребна – једноставно креирамо снимке логичких волумена, који се затим обрађују на исти начин као и снимак стања основног система датотека. Након снимања података, слике се бришу.
Даљи рад се обавља на серверу за складиштење резервних копија:
- проверава се последња резервна копија направљена у сваком спремишту,
- проверава се присуство датотеке са ознакама, што указује да је процес прикупљања података завршен,
- подаци се проширују на одговарајући локални волумен,
- датотека ознаке је избрисана
Процес опоравка сервера
Ако главни сервер умре, онда се покреће сличан наменски сервер који се покреће са неке стандардне слике. Највероватније ће се преузимање одвијати преко мреже, али техничар центра података који поставља сервер може одмах да копира ову стандардну слику на један од дискова. Преузимање се дешава у РАМ, након чега почиње процес опоравка:
- подноси се захтев за прикључивање блок уређаја преко исцсинбд или другог сличног протокола на логичку запремину која садржи основни систем датотека преминулог сервера; Пошто основни систем датотека мора бити мали, овај корак би требало да се заврши за неколико минута. Боотлоадер је такође враћен;
- структура локалних логичких волумена је поново креирана, логички волумени се прикључују са резервног сервера помоћу модула језгра дм_цлоне: почиње опоравак података, а промене се одмах уписују на локалне дискове
- покреће се контејнер са свим доступним физичким дисковима - функционалност сервера је потпуно враћена, али са смањеним перформансама;
- након што је синхронизација података завршена, логички волумени са резервног сервера се искључују, контејнер се искључује и сервер се поново покреће;
Након поновног покретања, сервер ће имати све податке који су били тамо у време креирања резервне копије, а такође ће укључити све промене које су направљене током процеса враћања.
Остали чланци у серији
Резервни део 7: Закључци
Позивам вас да разговарате о предложеној опцији у коментарима, хвала вам на пажњи!
Извор: ввв.хабр.цом