Оваа белешка го комплетира циклусот за резервна копија. Ќе разговара за логичката организација на посветен сервер (или VPS), погоден за резервна копија, а исто така ќе понуди опција за брзо враќање на серверот од резервна копија без многу прекини во случај на катастрофа.
Сурови податоци
Посветен сервер најчесто има најмалку два хард дискови кои служат за организирање на RAID низа од прво ниво (огледало). Ова е неопходно за да може да продолжи да работи со серверот ако еден диск не успее. Ако ова е обичен посветен сервер, може да има посебен хардверски RAID контролер со технологија за активно кеширање на SSD, така што покрај обичните хард дискови, може да се поврзат еден или повеќе SSD-а. Понекогаш се нудат посветени сервери, во кои единствените локални дискови се SATADOM (мали дискови, структурно флеш драјв поврзан со SATA порта), или дури и обичен мал (8-16 GB) флеш диск поврзан со специјална внатрешна порта, и податоците се земени од системот за складирање, поврзани преку посветена мрежа за складирање (Ethernet 10G, FC, итн.), а има посветени сервери кои се вчитуваат директно од системот за складирање. Нема да ги разгледам таквите опции, бидејќи во такви случаи задачата за правење резервна копија на серверот непречено преминува на специјалистот кој го одржува системот за складирање; обично постојат различни сопственички технологии за создавање снимки, вградена дедупликација и други радости на администраторот на системот , дискутирано во претходните делови од оваа серија. Обемот на диск низата на посветен сервер може да достигне неколку десетици терабајти, во зависност од бројот и големината на дисковите поврзани со серверот. Во случај на VPS, волумените се поскромни: обично не повеќе од 100 GB (но има и повеќе), а тарифите за таквите VPS лесно можат да бидат поскапи од најевтините посветени сервери од истиот хостер. VPS најчесто има еден диск, затоа што ќе има систем за складирање (или нешто хиперконвергирана) под него. Понекогаш VPS има неколку дискови со различни карактеристики, за различни цели:
- мал систем - за инсталирање на оперативниот систем;
- големо - складирање на кориснички податоци.
Кога повторно ќе го инсталирате системот користејќи ја контролната табла, дискот со кориснички податоци не се препишува, туку системскиот диск целосно се полни. Исто така, во случај на VPS, хостерот може да понуди копче што прави слика од состојбата на VPS (или дискот), но ако инсталирате сопствен оперативен систем или заборавите да ја активирате саканата услуга внатре во VPS, некои од податоците сè уште може да се изгубат. Покрај копчето, обично се нуди услуга за складирање податоци, најчесто многу ограничена. Вообичаено ова е сметка со пристап преку FTP или SFTP, понекогаш заедно со SSH, со одземена обвивка (на пример, rbash) или ограничување за извршување на команди преку autorized_keys (преку ForcedCommand).
Посветен сервер е поврзан на мрежата со две порти со брзина од 1 Gbps, понекогаш тоа може да бидат картички со брзина од 10 Gbps. VPS најчесто има еден мрежен интерфејс. Најчесто, центрите за податоци не ја ограничуваат брзината на мрежата во центарот за податоци, туку ја ограничуваат брзината на пристап до Интернет.
Типичното оптоварување на таков посветен сервер или VPS е веб-сервер, база на податоци и сервер за апликации. Понекогаш може да се инсталираат разни дополнителни помошни услуги, вклучително и за веб-сервер или база на податоци: пребарувач, систем за пошта итн.
Специјално подготвен сервер делува како простор за складирање на резервни копии; ние ќе пишуваме за тоа подетално подоцна.
Логичка организација на системот на дискот
Ако имате RAID контролер или VPS со еден диск и нема посебни поставки за работата на потсистемот на дискот (на пример, посебен брз диск за база на податоци), целиот слободен простор е поделен на следниов начин: една партиција се креира, а врз него се создава група за волумен на LVM, во неа се создаваат неколку тома: 2 мали со иста големина, кои се користат како root датотечен систем (се менуваат еден по еден за време на ажурирањата за можност за брзо враќање назад, идејата е преземена од дистрибуцијата Пресметај Линукс), друга е за swap партицијата, остатокот од слободниот простор е поделен на мали томови, се користи како root датотечен систем за полноправни контејнери, дискови за виртуелни машини, датотека системи за сметки во /home (секоја сметка има свој датотечен систем), датотечни системи за контејнери за апликации.
Важна забелешка: томовите мора да бидат целосно самостојни, т.е. не треба да зависат еден од друг или од root датотечен систем. Во случај на виртуелни машини или контејнери, оваа точка се забележува автоматски. Ако ова се контејнери за апликации или домашни директориуми, треба да размислите за одвојување на конфигурациските датотеки на веб-серверот и другите услуги на таков начин што ќе ги елиминирате зависностите помеѓу томовите колку што е можно повеќе. На пример, секоја локација работи од свој корисник, датотеките за конфигурација на страницата се во домашниот директориум на корисникот, во поставките на веб-серверот, датотеките за конфигурација на страницата не се вклучени преку /etc/nginx/conf.d/.conf и, на пример, /home//configs/nginx/*.conf
Ако има неколку дискови, можете да креирате софтверска RAID низа (и да го конфигурирате неговото кеширање на SSD, доколку има потреба и можност), на врвот на која можете да изградите LVM според правилата предложени погоре. Исто така, во овој случај, можете да користите ZFS или BtrFS, но треба да размислите двапати за ова: и двете бараат многу посериозен пристап кон ресурсите, а покрај тоа, ZFS не е вклучен во кернелот на Linux.
Без оглед на шемата што се користи, секогаш вреди однапред да се процени приближната брзина на запишување промени на дисковите, а потоа да се пресмета количината на слободен простор што ќе биде резервиран за создавање снимки. На пример, ако нашиот сервер запишува податоци со брзина од 10 мегабајти во секунда, а големината на целата низа податоци е 10 терабајти - времето на синхронизација може да достигне еден ден (22 часа - еве колку ќе се пренесе таков волумен преку мрежата 1 Gbps) - вреди да се резервира околу 800 GB . Во реалноста, бројката ќе биде помала, можете безбедно да ја поделите со бројот на логички волумени.
Уред за сервер за складирање резервни копии
Главната разлика помеѓу серверот за складирање резервни копии е неговите големи, евтини и релативно бавни дискови. Бидејќи современите HDD веќе ја поминале лентата од 10 TB на еден диск, неопходно е да се користат датотечни системи или RAID со контролни суми, бидејќи за време на обновата на низата или обновувањето на датотечниот систем (неколку дена!) вториот диск може да не успее поради до зголемен товар. На дискови со капацитет до 1 TB ова не беше толку чувствително. За едноставност на описот, претпоставувам дека просторот на дискот е поделен на два дела со приближно еднаква големина (повторно, на пример, користејќи 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, бидејќи оваа шема дава поголема контрола врз процесот на резервна копија од страна на овој сервер. Прво, се прави снимка од состојбата на активниот root датотечен систем, кој е монтиран и поставен со помош на BorgBackup на серверот за складирање резервни копии. Откако ќе заврши снимањето на податоците, снимката се демонтира и се брише.
Доколку има мала база на податоци (до 1 GB за секоја локација), се прави депонија на базата, која се зачувува во соодветен логички волумен, каде што се наоѓаат останатите податоци за истата локација, но така што депонијата е не е достапен преку веб-серверот. Ако базите на податоци се големи, треба да го конфигурирате отстранувањето на „жешките“ податоци, на пример, користејќи xtrabackup за MySQL или да работите со WAL со archive_command во PostgreSQL. Во овој случај, базата на податоци ќе се обнови одделно од податоците на страницата.
Ако се користат контејнери или виртуелни машини, треба да конфигурирате qemu-guest-agent, CRIU или други потребни технологии. Во други случаи, најчесто не се потребни дополнителни поставки - ние едноставно создаваме снимки од логички волумени, кои потоа се обработуваат на ист начин како слика од состојбата на root датотечен систем. Откако ќе се направат податоците, сликите се бришат.
Понатамошна работа се врши на серверот за резервна копија:
- се проверува последната резервна копија направена во секое складиште,
- се проверува присуството на датотека со ознаки, што покажува дека процесот на собирање податоци е завршен,
- податоците се прошируваат на соодветниот локален волумен,
- датотеката со ознаки е избришана
Процес за обновување на серверот
Ако главниот сервер умира, тогаш се лансира сличен посветен сервер, кој се подига од некоја стандардна слика. Најверојатно преземањето ќе се одвива преку мрежата, но техничарот на центарот за податоци што го поставува серверот може веднаш да ја копира оваа стандардна слика на еден од дисковите. Преземањето се случува во RAM меморијата, по што започнува процесот на обновување:
- се бара да се прикачи блок уред преку iscsinbd или друг сличен протокол на логичен волумен кој го содржи root датотечен систем на починатиот сервер; Бидејќи коренскиот датотечен систем мора да биде мал, овој чекор треба да се заврши за неколку минути. Подигнувачот исто така е обновен;
- структурата на локалните логички тома е повторно креирана, логичките томови се прикачени од резервниот сервер со помош на модулот за кернелот dm_clone: започнува обновувањето на податоците и промените се запишуваат веднаш на локалните дискови
- се лансира контејнер со сите достапни физички дискови - функционалноста на серверот е целосно вратена, но со намалени перформанси;
- по завршувањето на синхронизацијата на податоците, логичките волумени од резервниот сервер се исклучуваат, контејнерот е исклучен и серверот се рестартира;
По рестартирањето, серверот ќе ги има сите податоци што биле таму во моментот на креирање на резервната копија, а исто така ќе ги вклучи и сите промени што биле направени за време на процесот на обновување.
Други статии во серијата
Бекап Дел 7: Заклучоци
Ве поканувам да разговарате за предложената опција во коментарите, ви благодариме за вниманието!
Извор: www.habr.com