Тази бележка завършва цикъла за резервно копиране. В нея ще се обсъди логичната организация на выделен сървър (или VPS), удобна за резервно копиране, а също така ще бъде предложен вариант за бързо възстановяване на сървъра от резервно копие без значителни закъснения в случай на инцидент.
Изходни данни
Обикновено выделен сървър разполага с поне два твърди диска, които служат за организиране на RAID масив от първи ниво (огледало). Това е необходимо, за да може сървърът да продължи да функционира, ако един от дисковете се провали. Ако това е стандартен выделен сървър — може да има отделен хардуерен RAID контролер с активна технология за кеширане на SSD, така че в допълнение към обикновените твърди дискове може да бъде свързан един или повече SSD. Понякога се предлагат выделени сървъри, в които локалните дискове съдържат само SATADOM (малки дискове, конструктивно — флашка, свързана в SATA порт), или дори обикновена малка (8-16GB) флашка, свързана в специален вътрешен порт, като данните се взимат от СХД, свързана чрез отделна мрежа за съхранение на данни (Ethernet 10G, FC и т.н.), а има и выделени сървъри, които зареждат файла директно от СХД. Подобни опции няма да разглеждам, тъй като в такива случаи задачата за резервно копиране на сървъра плавно преминава на специалиста, който обслужва СХД, обикновено там има различни фирмени технологии за създаване на моментни снимки на състоянието, вградена дедупликация и други удобства за системния администратор, разгледани в предишните части на този цикъл. Обемът на дисковия масив на выделен сървър може да достигне десетки терабайти, в зависимост от броя и обема на дисковете, свързани към сървъра. При VPS обемите са по-скромни: обикновено не надвишават 100GB (но могат да бъдат и по-големи), а тарифите за такива VPS лесно могат да бъдат по-високи от най-евтините выделени сървъри на същия хостър. Често при VPS има само един диск, тъй като под него ще бъде СХД (или нещо хиперконвергентно). Понякога при VPS се срещат няколко диска с различни характеристики, за различни цели:
- малък системен — за инсталиране на операционната система;
- голям — за съхранение на потребителски данни.
При повторна инсталация на системата чрез контролния панел, дискът с потребителските данни не се заличава, а системният се презаписва изцяло. В случай на VPS, хостът може да предложи бутон, който да направи снимка на състоянието на VPS (или на диска), но ако инсталирате собствена операционна система или забравите да активирате необходимата услуга в VPS, част от данните може да бъде все пак загубена. Освен бутона обикновено се предлага услуга за съхранение на данни, която най-често е силно ограничена. Обикновено това е сметка с достъп чрез протокол FTP или SFTP, понякога заедно с SSH, със съкратен shell (например rbash) или ограничение за изпълнение на команди чрез authorized_keys (чрез ForcedCommand).
Посветеният сървър е свързан към мрежата чрез два порта със скорост 1 гбит/сек, понякога това могат да бъдат карти със скорост 10 гбит/сек. При VPS мрежовият интерфейс обикновено е един. Обикновено центровете за данни не ограничават скоростта на мрежата вътре в центъра за данни, но ограничават скоростта за достъп до интернет.
Типичната натовареност на подобен посветен сървър или VPS включва уеб сървър, база данни, сървър за приложения. Понякога могат да бъдат инсталирани различни допълнителни помощни услуги, включително за уеб сървъра или базата данни: търсеща машина, пощенска система и т.н.
Като пространство за съхранение на резервни копия се използва специално подготвен сървър, за който ще бъде написано по-подробно по-късно.
Логическа организация на дисковата система
Ако имате RAID контролер или това е VPS с един диск и също така нямате специфични предпочитания относно работата на дисковата подсистема (например, отделен бърз диск за база данни) — цялото свободно пространство се разпределя така: създава се един дял, върху който се създава група томове LVM, в нея се създават няколко тома: 2 малки равни по размер, които служат като коренова файлова система (разменят се последователно при обновления за възможност за бързо възстановяване, идеята е заимствана от разпространението Calculate Linux), един друг — за дяла за размяна, останалото свободно пространство се разпределя на малки томове, които се използват като коренова файлова система за пълноценни контейнери, дискове за виртуални машини, файлови системи за акаунти в /home (всяка акаунт — своя файлова система), файлови системи за контейнерни приложения.
Важно забележка: томовете трябва да бъдат напълно самообслужващи, т.е. не трябва да зависят от друг друг, а също и от кореновата файлова система. В случая с виртуални машини или контейнери този аспект автоматично се спазва. Обаче, ако става въпрос за контейнери приложения или домашни каталози — трябва да се помисли за разделяне на конфигурационните файлове на уеб сървъра и други услуги по такъв начин, че максимално да се премахнат зависимостите между томовете. Например, всеки сайт работи под свой потребител, конфигурационните файлове на сайта — в домашния каталог на потребителя, в настройките на уеб сървъра конфигурационните файлове на сайтовете не се включват чрез /etc/nginx/conf.d/.conf, а например /home//configs/nginx/*.conf
Ако имате няколко диска — можете да създадете софтуерна RAID маска (и да настроите кеширането на SSD, ако имате нужда и възможности), над която да изградите LVM според правилата, предложени по-горе. Също така в този случай можете да използвате ZFS или BtrFS, но тук трябва да се помисли внимателно: и двете изискват много по-сериозен подход към ресурсите, а ZFS не е включен в ядрото на Linux.
Независимо от избраната схема, винаги е добре предварително да се прецени приблизителната скорост на запис на промените върху дисковете, след което да се изчисли размерът на свободното пространство, което ще бъде резервирано за създаване на снимки. Например, ако нашият сървър записва данни със скорост 10 мегабайта в секунда, а целият обем на данните е 10 терабайта — времето за синхронизация може да достигне до 22 часа (това е времето, необходимо за предаване на този обем при 1 гбит/сек) — трябва да се резервират около 800 ГБ. В действителност, числото ще бъде по-малко, можем да го делим смело на броя на логичните томове.
Устройство за съхранение на резервни копия на сървъра
Основната разлика на сървъра за съхранение на резервни копия е наличието на големи, евтини и сравнително бавни дискове. Тъй като съвременните HDD вече надминаха границата от 10 ТБ в един диск — задължително е използването на файлови системи или RAID с контролни суми, защото по време на преструктуриране на обема или възстановяване на файловата система (няколко дни!) вторият диск може да се повреди заради повишената нагрузка. При дискове с капацитет до 1 ТБ това не беше толкова чувствително. За простота на описанието приемам, че дисковото пространство е разделено на две приблизително равни по размер части (отново, например, с помощта на LVM):
- тома, които съответстват на сървърите, използвани за съхранение на потребителски данни (на тях ще бъде разгръщана последната направена резервна копия за проверка);
- тома, използвани като хранилища на BorgBackup (тук директно ще попадат данните за резервните копия).
Принципът на работа е такъв, че за всеки сървър се създават отделни тома под хранилищата на BorgBackup, където ще постъпват данните от работещите сървъри. Хранилищата работят в режим само на добавяне, което изключва възможността за умишлено изтриване на данни, а благодарение на дедупликацията и периодичното почистване на хранилищата от стари резервни копия (остават годишни копия, месечни за последната година, седмични за последния месец, ежедневни за последната седмица, а в възможни специални случаи — почасови за последния ден: общо около 24 + 7 + 4 + 12 + годишни — около 50 копия за всеки сървър).
В хранилищата на BorgBackup не се активира режим само добавяне, вместо това се използва ForcedCommand в .ssh/authorized_keys по следния начин:
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.......На указания път е поставен обвиващ скрипт над borg, който, освен че стартира бинарния файл с параметри, допълнително стартира процеса на възстановяване на резервно копие след приключване на изтеглянето на данни. За тази цел обвиващият скрипт създава файл-признак до съответното хранилище. Най-новото направено резервно копие се възстановява автоматично на съответния логически том след приключване на процеса на качване на данни.
Тази конструкция позволява периодично да се почистват ненужните резервни копия, а също така не позволява на боевите сървъри да изтриват каквото и да било на сървъра за съхранение на резервни копия.
Процес на резервно копиране
Инициатор на резервното копиране е самостоятелният сървър или VPS, тъй като такава схема предоставя по-голям контрол над процеса на резервно копиране от страна на този сървър. Първо се прави снимка на състоянието на активната коренова файлова система, която се монтира и се качва с помощта на BorgBackup на сървъра за съхранение на резервни копия. След приключване на изтеглянето на данни снимката се демонтира и изтрива.
В случай на малка база данни (до 1 гб за всеки сайт) се прави дамп на базата данни, който се съхранява в съответния логически том, където са разположени другите данни на същия сайт, но така, че дампът да не бъде достъпен чрез уеб-сървъра. Ако базите данни са големи — трябва да се настрои „горещо“ изтегляне на данни, например чрез xtrabackup за MySQL, или работа с WAL с archive_command в PostgreSQL. В този случай базата данни ще бъде възстановявана отделно от данните на сайтовете.
Ако се използват контейнери или виртуални машини — трябва да се настрои qemu-guest-agent, CRIU или други нужни технологии. В останалите случаи допълнителни настройки обикновено не са необходими — просто създаваме снимки на логическите томове, които след това се обработват подобно на снимката на състоянието на кореновата файлова система. След изтегляне на данни снимките се изтриват.
По-нататъшната работа продължава на сървъра за съхранение на резервни копия:
- проверява се последната направена резервна копия във всяко хранилище,
- проверява се наличието на файл-етикет, указващ, че процесът на извличане на данни е завършен,
- извършва се разгръщане на данните на съответния локален том,
- изтрива се файл-етикет
Процес на възстановяване на работоспособността на сървъра
Ако основният сървър се повреди, се стартира аналогичен виртуален сървър, който се зарежда от стандартен образ. Най-вероятно зареждането ще се извърши по мрежата, но техникът на ЦОД, извършващ настройката на сървъра, може веднага да копира този стандартен образ на един от дисковете. Зареждането става в оперативната памет, след което започва процесът на възстановяване:
- извършва се заявка за присъединяване на блочно устройство по iscsinbd или друг подобен протокол на логически том, съдържащ кореновата файлова система на повредения сървър; тъй като кореновата файлова система трябва да бъде малка – този етап трябва да приключи за няколко минути. Също така се извършва възстановяване на загрузчика;
- възвръща се структурата на локалните логически томове, присъединяват се логическите томове от резервното хранилище с помощта на модула на ядрото dm_clone: започва възстановяване на данните, а измененията се записват веднага на локалните дискове
- стартира се контейнер с всички налични физически дискове – напълно се възстановява работоспособността на сървъра, но с понижаваща се производителност;
- след приключване на синхронизацията на данните логическите томове от резервното хранилище се отделят, контейнерът се изключва, сървърът се перезарежда;
След перезареждане сървърът ще има всички данни, които са били налични в момента на създаване на резервната копия, както и ще включва всички изменения, направени по време на възстановяването.
Други статии от цикъла
Резервно копиране, част 7: Изводи
Каня да обсъдим предложената опция в коментарите, благодаря за вниманието!
Източник: habr.com
