Ova bilješka završava ciklus o sigurnosnom kopiranju. U njoj će se raspraviti o logičkoj organizaciji posvećenog servera (ili VPS-a) koja je pogodna za sigurnosno kopiranje, a također će biti predložen način brzog vraćanja servera iz sigurnosne kopije bez velikih zastoja u slučaju kvara.
Izvorni podaci
Posvećeni server obično ima najmanje dva tvrda diska koja služe za organizaciju RAID niza prvog nivoa (zrcalo). To je potrebno kako bi se omogućilo nastavak rada servera u slučaju kvara jednog diska. Ako je to običan posvećeni server — može postojati odvojeni hardverski RAID kontroler s aktivnom tehnologijom keširanja na SSD-u, tako da se osim običnih tvrdih diskova može priključiti jedan ili više SSD-ova. Ponekad se nude posvećeni serveri koji imaju samo lokalne diskove kao što su SATADOM (mali diskovi, konstrukcijski — USB flash uređaj priključen na SATA port), ili čak obična mala (8-16 GB) USB flash memorija priključena na poseban unutarnji port, dok se podaci preuzimaju s SAN-a (sustava za pohranu podataka) priključenog putem posebne mreže za pohranu podataka (Ethernet 10G, FC itd.), a postoje i posvećeni serveri koji se pokreću direktno s SAN-a. Takve opcije neću razmatrati, jer u tim slučajevima zadatak sigurnosnog kopiranja servera obično prelazi na stručnjaka koji upravlja SAN-om, gdje postoje različite proprietarne tehnologije za stvaranje slika stanja, ugrađena deduplifikacija i druge koristi za sistemskog administratora, o kojima je bilo reči u prethodnim delovima ovog ciklusa. Volumen diskovnog niza posvećenog servera može doseći nekoliko desetaka terabajta, u zavisnosti od broja i kapaciteta diskova priključenih na server. U slučaju VPS-a, kapaciteti su skromniji: obično ne više od 100 GB (ali ima i većih), a tarife za takve VPS-e lako mogu biti skuplje od najjeftinijih posvećenih servera istog hostera. VPS-ovi obično imaju jedan disk, jer će ispod njih postojati SAN (ili nešto hiper-konvergentno). Ponekad VPS-ovi imaju nekoliko diskova sa različitim karakteristikama za različite svrhe:
- mali sistemski — za instalaciju operativnog sistema;
- veliki — za pohranu korisničkih podataka.
Prilikom ponovne instalacije sustava putem upravljačke ploče, disk s korisničkim podacima se ne briše, dok se sustavni disk potpuno prepisuje. Također, u slučaju VPS-a, pružatelj usluga može ponuditi gumb koji snima stanje VPS-a (ili diska), ali ako se instalira vlastiti operacijski sustav ili zaboravi aktivirati potrebnu uslugu unutar VPS-a, dio podataka može biti izgubljen. Uz gumb obično se nudi i usluga pohrane podataka, koja je često značajno ograničena. Obično to uključuje račun s pristupom putem protokola FTP ili SFTP, ponekad uz SSH, s ograničenim shell-om (na primjer, rbash), ili s ograničenjem na izvršavanje komandi putem authorized_keys (putem ForcedCommand).
Posvećeni server je povezan na mrežu s dva porta brzine 1 Gbps, ponekad su to kartice brzine 10 Gbps. VPS obično ima jedan mrežni sučelje. Obično, datacentri ne ograničavaju brzinu unutar datacentra, ali ograničavaju brzinu pristupa internetu.
Tipično opterećenje sličnog posvećenog servera ili VPS-a uključuje web server, bazu podataka i server aplikacija. Ponekad mogu biti instalirane razne dodatne pomoćne usluge, uključujući za web server ili bazu podataka: pretraživač, e-mail sustav itd.
Kao prostor za pohranu sigurnosnih kopija koristi se posebno pripremljeni server, o kojem će biti više riječi kasnije.
Logička organizacija disčnog sustava
Ako postoji RAID kontroler, ili je to VPS s jednim diskom, a također nema posebnih preferencija za rad diskovne podrtške (na primjer, poseban brzi disk za bazu podataka) — sav slobodan prostor se dijeli na sljedeći način: stvara se jedna particija, na koju se postavlja LVM grupacija volumena, u kojoj se stvaraju nekoliko volumena: 2 mala istih dimenzija koja se koriste kao korijenska datotečna sustava (izmjenjuju se naizmjenično tijekom ažuriranja za mogućnost brzog vraćanja, ideja je preuzeta iz distribucije Calculate Linux), još jedan — za swap particiju, preostali slobodni prostor se dijeli na male volumene koji se koriste kao korijenski datotečni sustavi za pune kontejnere, diskove za virtualne strojeve, datotečne sustave za račune u /home (svakom računu — svoj datotečni sustav), datotečne sustave za aplikacijske kontejnere.
Važna napomena: volumeni moraju biti potpuno samodostatni, tj. ne smiju ovisiti jedni o drugima, niti o korijenskom datotečnom sustavu. U slučaju virtualnih strojeva ili kontejnera, ovaj aspekt se automatski poštuje. Ako su to kontejneri aplikacija ili korisnički home direktoriji — treba razmisliti o razdvajanju konfiguracijskih datoteka web poslužitelja i drugih usluga na način da se maksimalno smanje ovisnosti volumena između sebe. Na primjer, svaka web stranica radi pod svojim korisnikom, konfiguracijske datoteke web stranice su u korisničkom home direktoriju, a u postavkama web poslužitelja, konfiguracijske datoteke web stranica se uključuju ne kroz /etc/nginx/conf.d/.conf, već, na primjer, /home//configs/nginx/*.conf
Ako postoji više diskova — može se stvoriti softverski RAID array (i postaviti njegovo keširanje na SSD, ako postoji potreba i mogućnosti), na koji se može postaviti LVM prema pravilima predloženim ranije. Također, u ovom slučaju se može koristiti ZFS ili BtrFS, ali tu se isplati nekoliko puta razmisliti: oba zahtijevaju mnogo ozbiljniji pristup resursima, pored toga ZFS nije uključeno u distribuciju Linux jezgra.
Bez obzira na korištenu shemu, uvijek je dobro unaprijed procijeniti približnu brzinu zapisivanja promjena na diskove, a zatim izračunati veličinu slobodnog prostora koja će biti rezervirana za stvaranje snimaka. Na primjer, ako naš server zapisuje podatke brzinom od 10 megabajta u sekundi, a ukupna veličina skupa podataka iznosi 10 terabajta — vrijeme sinkronizacije može trajati i do jednog dana (22 sata — toliko će trajati prijenos tog volumena preko mreže 1 Gbit/s) — potrebno je rezervirati otprilike 800 GB. U stvarnosti će brojka biti manja, slobodno je podijelite s brojem logičkih volumena.
Uređaj za pohranu rezervnih kopija
Glavna razlika servera za pohranu rezervnih kopija su veliki, jeftini i relativno spori diskovi. Budući da su moderni HDD-ovi već premašili granicu od 10 TB po disku, obavezna je primjena datotečnih sustava ili RAID-a s kontrolnim zbrojevima, jer tijekom rekonstrukcije skupa ili oporavka datotečnog sustava (nekoliko dana!) drugi disk može otkazati uslijed povećanog opterećenja. Na diskovima kapaciteta do 1 TB to nije bilo toliko osjetljivo. Za jednostavnost opisivanja, pretpostavljam da je diskovni prostor podijeljen u dva otprilike jednake veličine dijela (opet, na primjer, pomoću LVM):
- volumeni koji odgovaraju serverima, a koriste se za pohranu korisničkih podataka (na njima će se odvijati posljednja napravljena rezervna kopija za provjeru);
- volumeni koji se koriste kao repozitoriji BorgBackup (ovdje će neposredno dolaziti podaci za rezervne kopije).
Princip rada je da se stvaraju odvojeni volumeni za svaki server pod repozitorije BorgBackup, gdje će dolaziti podaci s produkcijskih servera. Repozitoriji rade u režimu samo dodavanja, što isključuje mogućnost namjernog brisanja podataka, a zahvaljujući deduplici i povremenom čišćenju repozitorija od starih rezervnih kopija (ostaju godišnje kopije, mjesečne za posljednju godinu, tjedne za posljednji mjesec, dnevne za posljednji tjedan, moguće — u posebnim slučajevima — svaka sat vremena za posljednji dan: ukupno 24 + 7 + 4 + 12 + godišnje — otprilike 50 kopija za svaki server).
U BorgBackup repozitorijima nije omogućen režim samo za dodavanje; umjesto toga koristi se ForcedCommand u .ssh/authorized_keys otprilike ovakvog oblika:
from="adres poslužitelja",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 navedenom putu nalazi se wrapper skripta koja, osim što pokreće binar s parametrima, dodatno pokreće proces vraćanja rezervne kopije nakon završetka skidanja podataka. Za to wrapper skripta stvara datoteku-oznaku pored odgovarajućeg repozitorija. Posljednja napravljena rezervna kopija automatski se vraća na odgovarajući logički volumen nakon završetka procesa prijenosa podataka.
Ova konstrukcija omogućuje povremeno čišćenje nepotrebnih rezervnih kopija, a također ne omogućuje produkcijskim poslužiteljima brisanje bilo čega na poslužitelju za pohranu rezervnih kopija.
Proces stvaranja rezervne kopije
Inicijator rezervne kopije je sam poslužitelj ili VPS, budući da ovaj način pruža veću kontrolu nad procesom rezervne kopije s te strane. Prvo se snima stanje aktivnog korijenskog datotečnog sustava, koji se montira i prenosi pomoću BorgBackup-a na poslužitelj za pohranu rezervnih kopija. Nakon završetka skidanja podataka, snimak se demontira i briše.
U slučaju malih baza podataka (do 1 GB za svaku web stranicu) pravi se dump baze podataka koji se pohranjuje u odgovarajući logički volumen, onamo gdje su smješteni svi ostali podaci te iste stranice, ali tako da dump nije dostupan putem web poslužitelja. Ako su baze velike — treba postaviti 'vruće' skidanje podataka, npr. pomoću xtrabackup za MySQL ili koristiti WAL s archive_command u PostgreSQL. U tom slučaju, baza podataka će se vraćati odvojeno od podataka web stranica.
Ako se koriste kontejneri ili virtualne mašine — treba postaviti qemu-guest-agent, CRIU ili druge potrebne tehnologije. U ostalim slučajevima dodatna podešavanja obično neće biti potrebna — jednostavno se kreiraju snimci logičkih volumena koji se zatim obrađuju slično kao snimak stanja korijenskog datotečnog sustava. Nakon skidanja podataka, snimci se brišu.
Daljnji rad odvija se na poslužitelju za pohranu rezervnih kopija:
- provjera posljednje napravljenih sigurnosnih kopija u svakom repozitoriju,
- provjera prisutnosti datoteke-oznake koja označava da je proces povlačenja podataka završen,
- izvršava se obnavljanje podataka na odgovarajući lokalni volumen,
- briše se datoteka-oznake
Proces oporavka funkcionalnosti servera
Ako glavni server padne, pokreće se sličan dodijeljeni server koji se pokreće s određenog standardnog imidža. Vjerojatno će se pokretanje odvijati putem mreže, no tehničar DC-a koji podesi server može odmah kopirati taj standardni imidž na jedan od diskova. Pokretanje se odvija u operativnoj memoriji, nakon čega započinje proces oporavka:
- izvršava se zahtjev za pridruživanje blokovnom uređaju putem iscsinbd ili sličnog protokola logičkog volumena koji sadrži korijenski datotečni sustav srušenog servera; budući da korijenski datotečni sustav mora biti mali — ova faza bi trebala biti završena za nekoliko minuta. Također se obavlja obnova pokretača;
- obnavlja se struktura lokalnih logičkih volumena, pridružuju se logički volumeni s servera za sigurnosno kopiranje pomoću modula jezgre dm_clone: počinje obnova podataka, a promjene se odmah zapisuje na lokalne diskove
- pokreće se kontejner sa svim dostupnim fizičkim diskovima — potpuno se obnavlja funkcionalnost servera, ali s smanjenom učinkovitošću;
- nakon završetka sinkronizacije podataka, logički volumeni s servera za sigurnosno kopiranje se odspajaju, kontejner se isključuje, server se ponovo pokreće;
Nakon ponovnog pokretanja, server će imati sve podatke koji su postojali u trenutku stvaranja sigurnosne kopije, te će sadržavati sve promjene koje su napravljene tijekom procesa oporavka.
Ostali članci iz serije
Backup, dio 7: Zaključci
Pozivam vas da raspravite predloženu opciju u komentarima, zahvaljujem na pažnji!
Izvor: habr.com
