Ta opomba končuje cikel o varnostnem kopiranju. V njej bo govora o logični organizaciji namenski strežnik (ali VPS), ki je primerna za varnostno kopiranje, poleg tega pa bo predlagana možnost hitrega obnavljanja strežnika iz varnostne kopije brez večjih zamud v primeru okvare.
Izvorni podatki
Namenski strežnik običajno vsebuje vsaj dva trda diska, ki služita za organizacijo RAID prve stopnje (zrcalo). To je potrebno za nadaljevanje delovanja strežnika, če en disk odpove. Če je to običajen namenski strežnik, lahko obstaja ločen strojni RAID krmilnik z aktivno tehnologijo predpomnjenja na SSD, tako da je poleg običajnih trdih diskov možno priključiti enega ali več SSD-jev. Včasih so na voljo namenski strežniki, ki imajo le lokalne diske, kot so SATADOM (majhni diski, zasnovani kot USB ključek, priključen na SATA priključek), ali pa običajen majhen (8-16 GB) USB ključ, priključen na posebno notranjo vtičnico, pri čemer se podatki pridobivajo iz SAN, povezanega preko posebne shranjevalne omrežne povezave (Ethernet 10G, FC itd.), obstajajo pa tudi namenski strežniki, ki se nalagajo neposredno iz SAN. Takšnih možnosti ne bom obravnaval, saj v takih primerih naloga varnostnega kopiranja strežnika preide na strokovnjaka, ki upravlja SAN. Običajno so tam na voljo različne lastniške tehnologije za ustvarjanje posnetkov stanja, vgrajena deduplikacija in druge ugodnosti sistemskega administratorja, obravnavane v prejšnjih delih tega cikla. Kapaciteta diskovnega niza namenskega strežnika lahko doseže več deset terabajtov, odvisno od števila in velikosti diskov, povezanih s strežnikom. V primeru VPS so kapacitete skromnejše: običajno ne več kot 100 GB (vendar so lahko tudi večje), tarife za take VPS pa so lahko enostavno dražje od najcenejših namenskih strežnikov istega ponudnika. Pri VPS je običajno samo en disk, ker bo pod njim SAN (ali kaj hiper-konvergentnega). Včasih ima VPS več diskov z različnimi značilnostmi za različne namene:
- majhen sistemski - za namestitev operacijskega sistema;
- velik - shranjevanje uporabniških podatkov.
При переустановке системы через панель управления диск с пользовательскими данными не затирается, а системный устанавливается заново. В случае с VPS хостер может предлагать кнопку для создания снимка состояния VPS (или диска), но если установить свою операционную систему или забыть активировать нужный сервис внутри VPS, часть данных может быть потеряна. Обычно вместе с кнопкой предлагается сервис хранения данных, который часто имеет значительные ограничения. Это может быть учетная запись с доступом по протоколу FTP или SFTP, иногда также с SSH, но с ограниченным shell (например, rbash) или ограничениями на выполнение команд через authorized_keys (через ForcedCommand).
Выделенный сервер подключен к сети через два порта со скоростью 1 Гбит/с, иногда используются карты на 10 Гбит/с. У VPS, как правило, один сетевой интерфейс. Обычно датацентры не ограничивают скорость внутри датацентра, но скорость доступа в интернет может быть ограничена.
Типовая нагрузка такого выделенного сервера или VPS включает веб-сервер, базу данных и сервер приложений. Иногда могут устанавливаться различные дополнительные вспомогательные сервисы, включая поисковые движки, почтовые системы и т.д.
Резервные копии хранятся на специально подготовленном сервере, о котором будет рассказано подробнее далее.
Логическая организация файловой системы
Če je RAID krmilnik, ali gre za VPS z enim diskom, ter ni posebnih zahtev glede delovanja diskovnega sistema (na primer, ločen hiter disk za podatkovno bazo) — se ves prosti prostor razdeli tako: ustvari se en razdelek, nanj se ustvari skupina volumenov LVM, v kateri se ustvari več volumnov: 2 majhna enake velikosti, uporabljena kot korenski datotečni sistem (izmenjujeta se pri posodobitvah za hitro vračanje, ideja je bila povzeta iz distribucije Calculate Linux), še en — za izmenjevalni razdelek, preostali prosti prostor se razdeli na majhne volumnes, ki se uporabljajo kot korenski datotečni sistem za popolne kontejnerje, diske za virtualne stroje, datotečne sisteme za uporabniške račune v /home (vsak račun ima svoj datotečni sistem), datotečne sisteme za aplikacijske kontejnerje.
Pomembna opomba: volumi morajo biti popolnoma samostojni, tj. ne smejo biti odvisni drug od drugega, niti od korenskega datotečnega sistema. V primeru virtualnih strojev ali kontejnerjev je ta vidik samodejno upoštevan. Če pa gre za aplikacijske kontejnerje ali domače mape — je vredno razmisliti o ločevanju konfiguracijskih datotek spletnega strežnika in drugih storitev na način, ki čim bolj zmanjša odvisnosti med volumni. Na primer, vsaka spletna stran deluje pod svojim uporabnikom, konfiguracijske datoteke spletne strani so v uporabniški domači mapi, v nastavitvah spletnega strežnika pa se konfiguracijske datoteke spletnih strani vključujejo ne preko /etc/nginx/conf.d/.conf, ampak, na primer, /home//configs/nginx/*.conf
Če pa je diskov več — lahko ustvarite programski RAID (in nastavitve predpomnjenja na SSD, če obstaja potreba in možnosti), na katerem se nato zgradi LVM po pravilih, predlaganih zgoraj. Prav tako v tem primeru lahko uporabite ZFS ali BtrFS, vendar je tukaj vredno razmisliti večkrat: oba zahtevata mnogo resnejši pristop k virom, poleg tega pa ZFS ni priložen jedru Linux.
Ne glede na uporabljeno shemo je vedno smiselno oceniti približno hitrost zapisovanja sprememb na diske, nato pa izračunati velikost prostega prostora, ki bo rezervirana za ustvarjanje posnetkov. Na primer, če naš strežnik zapisuje podatke s hitrostjo 10 megabajtov na sekundo, skupna velikost podatkovnega niza pa znaša 10 terabajtov — lahko traja do enega dneva (22 ur - toliko bo potrebnega za prenos te količine po omrežju 1 Gbit/s) — je smiselno rezervirati približno 800 GB. V resnici bo številka manjša, lahko jo varno delimo z številom logičnih volumenov.
Strežnik za shranjevanje varnostnih kopij
Glavna razlika med strežnikom za shranjevanje varnostnih kopij so veliki, poceni in relativno počasni diski. Ker so sodobni HDD-ji že presegli mejo 10 TB na enem disku — je nujno uporabljati datotečne sisteme ali RAID s kontrolnimi vsotami, saj lahko v času prestrukturiranja niza ali obnovitve datotečnega sistema (več dni!) drugi disk odpove zaradi povečane obremenitve. Pri diskih s kapaciteto do 1 TB to ni bilo tako občutno. Za enostavnost opisa predvidevam, da je prostor na disku razdeljen na dve približno enaki size (spet na primer, s pomočjo LVM):
- volumni, ki ustrezajo strežnikom, ki se uporabljajo za shranjevanje uporabniških podatkov (na njih bo nameščena zadnja narejena varnostna kopija za preverjanje);
- volumni, ki se uporabljajo kot repozitoriji BorgBackup (tja bodo neposredno prihajali podatki za varnostne kopije).
Načelo delovanja je, da se za vsak strežnik ustvarijo posamezni volumi za repozitorije BorgBackup, kamor bodo prihajali podatki iz produkcijskih strežnikov. Repozitoriji delujejo v načinu samo dodajanja, kar izključuje možnost namernega brisanja podatkov, in zaradi deduplikacije ter občasnega čiščenja repozitorijev od starih varnostnih kopij (ostalih letne kopije, mesečne za preteklo leto, tedenske za pretekli mesec, dnevne za pretekli teden, morda - v posebnih primerih - vsakodnevne za pretekli dan: skupaj 24 + 7 + 4 + 12 + letne - približno 50 kopij za vsak strežnik).
V repozitorijih BorgBackup se ne aktivira način samo za dodavanje, umesto toga se koristi ForcedCommand u .ssh/authorized_keys otprilike ovako:
from="adresa servera",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.......Na navedenoj stazi je skripta omotač iznad borga, koja, osim što pokreće binarni fajl sa parametrima, dodatno pokreće proces vraćanja rezervne kopije nakon završetka preuzimanja podataka. U tu svrhu skripta omotač stvara datoteku-oznaku pored odgovarajućeg repozitorija. Poslednja napravljena rezervna kopija se automatski vraća na odgovarajući logički volumen nakon završetka procesa slanja podataka.
Ova konstrukcija omogućava povremeno čišćenje nepotrebnih rezervnih kopija, kao i sprečava operativne servere da brišu bilo šta na serveru za čuvanje rezervnih kopija.
Proces rezervnog kopiranja
Inicijator rezervnog kopiranja je sam posvećeni server ili VPS, pošto ova shema daje više kontrole nad procesom rezervnog kopiranja s te strane. Prvo se pravi snimak stanja aktivnog korenog fajl sistema, koji se montira i preuzima pomoću BorgBackup-a na server za čuvanje rezervnih kopija. Nakon završetka preuzimanja podataka, snimak se demontira i briše.
U slučaju male baze podataka (do 1 GB za svaku stranicu) pravi se dump baze podataka, koji se čuva u odgovarajućem logičkom volumenu, gde se nalaze ostali podaci te iste stranice, ali tako da dump nije dostupan putem web servera. Ako su baze veće, treba podesiti "vruće" preuzimanje podataka, na primer, pomoću xtrabackup za MySQL, ili rad WAL s archive_command u PostgreSQL. U tom slučaju, baza podataka će se vraćati odvojeno od podataka stranica.
Ako se koriste kontejneri ili virtuelne mašine, treba podesiti qemu-guest-agent, CRIU ili druge potrebne tehnologije. U ostalim slučajevima dodatne konfiguracije obično nisu potrebne — jednostavno pravimo snimke logičkih volumena, koji se kasnije obrađuju slično snimku stanja korenog fajl sistema. Nakon preuzimanja podataka, snimci se brišu.
Daljnji rad se obavlja na serveru za čuvanje rezervnih kopija:
- preverja se zadnja izdelana varnostna kopija v vsakem repozitoriju,
- preverja se prisotnost oznake datoteke, ki kaže, da je postopek pridobivanja podatkov končan,
- izvaja se obnovitev podatkov na ustrezni lokalni volum,
- izbriše se oznaka datoteke,
Postopek obnove delovanja strežnika,
Če glavna strežnik propade, se zažene podoben namenski strežnik, ki se naloži iz nekega standardnega imidža. Verjetno se bo nalaganje odvijalo preko omrežja, vendar lahko tehnik podatkovnega centra, ki nastavlja strežnik, takoj kopira ta standardni imidž na enega od diskov. Nalaganje se odvija v pomnilnik, po čemer se zažene proces obnove:
- izvaja se zahteva za priključitev blokovnega naprava preko iscsinbd ali drugega podobnega protokola logičnega volumena, ki vsebuje korensko datotečno sistema propadle strežnika; ker mora biti korenska datotečna sistema majhna — ta korak bi moral biti končan v nekaj minutah. Izvaja se tudi obnovitev zagonskega nalagalnika;
- obnavlja se struktura lokalnih logičnih volumenov, priključijo se logični volumeni s strežnika varnostne kopije z uporabo jedrskega modula dm_clone: začne se obnovitev podatkov, spremembe pa se takoj zapisujejo na lokalne diske,
- začne se kontejner z vsemi razpoložljivimi fizičnimi diski — popolnoma se obnovi delovanje strežnika, vendar z zmanjšano zmogljivostjo;
- po končanju sinhronizacije podatkov se logični volumeni s strežnika varnostne kopije odklopijo, kontejner se izklopi, strežnik pa se znova zažene;
Po ponovnem zagonu bo strežnik imel vse podatke, ki so bili ob trenutku ustvarjanja varnostne kopije, ter vključil vse spremembe, ki so bile narejene v procesu obnove.
Drugi članki cikla,
Varnostno kopiranje, del 7: Sklepi
Vabim vas, da razpravljate o predlagani različici v komentarjih, hvala za pozornost!
Izvor: habr.com
