Ta opomba zaključuje cikel o varnostnem kopiranju. Obravnaval bo logično organizacijo namenskega strežnika (ali VPS), primernega za varnostno kopiranje, ponudil pa bo tudi možnost hitre obnovitve strežnika iz varnostne kopije brez večjih izpadov v primeru katastrofe.
Surovi podatki
Namenski strežnik ima najpogosteje vsaj dva trda diska, ki služita za organizacijo prvonivojskega polja RAID (mirror). To je potrebno za nadaljnje delovanje strežnika, če en disk odpove. Če je to običajni namenski strežnik, je lahko na SSD ločen strojni krmilnik RAID s tehnologijo aktivnega predpomnjenja, tako da je poleg običajnih trdih diskov mogoče povezati enega ali več SSD diskov. Včasih so na voljo namenski strežniki, v katerih so edini lokalni diski SATADOM (majhni diski, strukturno bliskovni pogon, priključen na vrata SATA), ali celo navaden majhen (8-16 GB) bliskovni pogon, priključen na posebna notranja vrata, in podatki so vzeti iz sistema za shranjevanje, povezani preko namenskega omrežja za shranjevanje (Ethernet 10G, FC itd.), obstajajo pa tudi namenski strežniki, ki se nalagajo neposredno iz sistema za shranjevanje. Takšnih možnosti ne bom upošteval, saj v takih primerih naloga varnostnega kopiranja strežnika gladko preide na strokovnjaka, ki vzdržuje sistem za shranjevanje; običajno obstajajo različne lastniške tehnologije za ustvarjanje posnetkov, vgrajeno deduplikacijo in druge radosti sistemskega skrbnika. , o katerih smo razpravljali v prejšnjih delih te serije. Prostornina diskovnega polja namenskega strežnika lahko doseže več deset terabajtov, odvisno od števila in velikosti diskov, povezanih s strežnikom. Pri VPS so količine skromnejše: običajno ne presegajo 100 GB (so pa tudi več), tarife za tak VPS pa so zlahka dražje od najcenejših namenskih strežnikov istega gostitelja. VPS ima največkrat en disk, ker bo pod njim sistem za shranjevanje (ali nekaj hiperkonvergentnega). Včasih ima VPS več diskov z različnimi lastnostmi, za različne namene:
- majhen sistem - za namestitev operacijskega sistema;
- velika - shranjevanje uporabniških podatkov.
Pri ponovni namestitvi sistema s pomočjo nadzorne plošče se disk z uporabniškimi podatki ne prepiše, ampak se sistemski disk popolnoma napolni. Tudi v primeru VPS lahko gostitelj ponudi gumb, ki naredi posnetek stanja VPS (ali diska), vendar če namestite svoj operacijski sistem ali pozabite aktivirati želeno storitev znotraj VPS, nekateri podatkov se lahko še vedno izgubi. Poleg gumba je običajno na voljo storitev shranjevanja podatkov, največkrat zelo omejena. Običajno je to račun z dostopom prek FTP ali SFTP, včasih skupaj s SSH, s skrajšano lupino (na primer rbash) ali omejitvijo izvajanja ukazov prek authorized_keys (prek ForcedCommand).
Namenski strežnik je v omrežje povezan z dvema priključkoma s hitrostjo 1 Gbps, včasih so to lahko kartice s hitrostjo 10 Gbps. VPS ima največkrat en omrežni vmesnik. Najpogosteje podatkovni centri ne omejujejo hitrosti omrežja znotraj podatkovnega centra, omejujejo pa hitrost dostopa do interneta.
Tipična obremenitev takšnega namenskega strežnika ali VPS je spletni strežnik, baza podatkov in aplikacijski strežnik. Včasih so lahko nameščene različne dodatne pomožne storitve, tudi za spletni strežnik ali bazo podatkov: iskalnik, poštni sistem itd.
Kot prostor za shranjevanje varnostnih kopij deluje posebej pripravljen strežnik, o katerem bomo podrobneje pisali kasneje.
Logična organizacija diskovnega sistema
Če imate krmilnik RAID ali VPS z enim diskom in ni posebnih nastavitev za delovanje diskovnega podsistema (na primer ločen hitri disk za bazo), se ves prosti prostor razdeli na naslednji način: ena particija je ustvarjen, na vrhu pa je ustvarjena skupina nosilcev LVM, v njej je ustvarjenih več nosilcev: 2 majhna enake velikosti, ki se uporabljata kot korenski datotečni sistem (spremenjena enega za drugim med posodobitvami zaradi možnosti hitrega povrnitve nazaj, ideja je bila povzeta iz distribucije Calculate Linux), druga je za izmenjalno particijo, preostali prosti prostor je razdeljen na majhne količine, ki se uporabljajo kot korenski datotečni sistem za polne vsebnike, diske za virtualne stroje, datoteke sistemi za račune v /home (vsak račun ima svoj datotečni sistem), datotečni sistemi za vsebnike aplikacij.
Pomembna opomba: zvezki morajo biti popolnoma samostojni, tj. ne smejo biti odvisni drug od drugega ali od korenskega datotečnega sistema. V primeru virtualnih strojev ali vsebnikov se ta točka samodejno opazuje. Če so to vsebniki aplikacij ali domači imeniki, razmislite o ločevanju konfiguracijskih datotek spletnega strežnika in drugih storitev na način, da čim bolj odpravite odvisnosti med nosilci. Na primer, vsako spletno mesto zažene svoj uporabnik, konfiguracijske datoteke spletnega mesta so v uporabnikovem domačem imeniku, v nastavitvah spletnega strežnika, konfiguracijske datoteke spletnega mesta niso vključene prek /etc/nginx/conf.d/.conf in na primer /home//configs/nginx/*.conf
Če obstaja več diskov, lahko ustvarite programsko polje RAID (in konfigurirate njegovo predpomnjenje na SSD, če obstaja potreba in priložnost), na vrhu katerega lahko zgradite LVM v skladu z zgoraj predlaganimi pravili. Tudi v tem primeru lahko uporabite ZFS ali BtrFS, vendar morate dvakrat premisliti o tem: oba zahtevata veliko resnejši pristop do virov, poleg tega pa ZFS ni vključen v jedro Linuxa.
Ne glede na uporabljeno shemo je vedno vredno vnaprej oceniti približno hitrost zapisovanja sprememb na diske in nato izračunati količino prostega prostora, ki bo rezerviran za ustvarjanje posnetkov. Na primer, če naš strežnik zapisuje podatke s hitrostjo 10 megabajtov na sekundo in je velikost celotnega podatkovnega niza 10 terabajtov - lahko čas sinhronizacije doseže en dan (22 ur - toliko se bo prenesla taka količina). prek omrežja 1 Gbps) - vredno je rezervirati približno 800 GB . V resnici bo številka manjša, lahko jo varno delite s številom logičnih nosilcev.
Strežniška naprava za varnostno shranjevanje
Glavna razlika med strežnikom za shranjevanje varnostnih kopij so veliki, poceni in razmeroma počasni diski. Ker so sodobni trdi diski že presegli mejo 10TB na enem disku, je nujna uporaba datotečnih sistemov ali RAID s kontrolnimi vsotami, saj lahko med obnovo polja ali obnovo datotečnega sistema (več dni!) drugi disk odpove zaradi do povečane obremenitve. Na diskih s kapaciteto do 1TB to ni bilo tako občutljivo. Zaradi enostavnosti opisa predvidevam, da je prostor na disku razdeljen na dva dela približno enake velikosti (spet na primer z uporabo LVM):
- nosilci, ki ustrezajo strežnikom, ki se uporabljajo za shranjevanje uporabniških podatkov (zadnja narejena varnostna kopija bo na njih nameščena za preverjanje);
- nosilci, ki se uporabljajo kot repozitoriji BorgBackup (podatki za varnostne kopije bodo šli neposredno sem).
Načelo delovanja je, da se za vsak strežnik ustvarijo ločeni nosilci za repozitorije BorgBackup, kamor bodo šli podatki iz bojnih strežnikov. Repozitoriji delujejo v načinu samo dodajanja, kar izniči možnost namernega brisanja podatkov, ter zaradi deduplikacije in periodičnega čiščenja repozitorijev od starih varnostnih kopij (letne kopije ostanejo, mesečno za zadnje leto, tedenske za zadnji mesec, dnevne za zadnji teden, po možnosti v posebnih primerih - vsako uro za zadnji dan: skupaj 24 + 7 + 4 + 12 + letno - približno 50 izvodov za vsak strežnik).
Repozitoriji BorgBackup ne omogočajo načina samo za dodajanje; namesto tega se uporabi ForcedCommand v .ssh/authorized_keys nekaj takega:
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.......Navedena pot vsebuje ovojni skript na vrhu borga, ki poleg zagona binarne datoteke s parametri dodatno zažene postopek obnovitve varnostne kopije po odstranitvi podatkov. Če želite to narediti, ovojni skript ustvari datoteko z oznako poleg ustreznega repozitorija. Zadnja izdelana varnostna kopija se samodejno obnovi na ustrezen logični nosilec, ko je postopek polnjenja podatkov končan.
Ta zasnova vam omogoča občasno čiščenje nepotrebnih varnostnih kopij in tudi preprečuje, da bi bojni strežniki izbrisali kar koli na strežniku za shranjevanje varnostnih kopij.
Postopek varnostnega kopiranja
Pobudnik varnostnega kopiranja je sam namenski strežnik oziroma VPS, saj ta shema omogoča večji nadzor nad procesom varnostnega kopiranja s strani tega strežnika. Najprej se naredi posnetek stanja aktivnega korenskega datotečnega sistema, ki se namesti in naloži s pomočjo BorgBackup na strežnik za shranjevanje varnostnih kopij. Ko je zajem podatkov končan, se posnetek odklopi in izbriše.
Če gre za majhno zbirko podatkov (do 1 GB za vsako mesto), se naredi izpis baze podatkov, ki se shrani v ustrezen logični nosilec, kjer se nahajajo ostali podatki za isto mesto, vendar tako, da je izpis ni dostopen prek spletnega strežnika. Če so zbirke podatkov velike, bi morali konfigurirati "vroče" odstranjevanje podatkov, na primer z uporabo xtrabackup za MySQL ali delati z WAL z archive_command v PostgreSQL. V tem primeru bo baza podatkov obnovljena ločeno od podatkov spletnega mesta.
Če uporabljate vsebnike ali virtualne stroje, morate konfigurirati qemu-guest-agent, CRIU ali druge potrebne tehnologije. V drugih primerih dodatne nastavitve največkrat niso potrebne - preprosto ustvarimo posnetke logičnih nosilcev, ki se nato obdelajo na enak način kot posnetek stanja korenskega datotečnega sistema. Ko so podatki posneti, se slike izbrišejo.
Nadaljnje delo se izvaja na strežniku za shranjevanje rezervnih kopij:
- zadnja varnostna kopija, izdelana v vsakem repozitoriju, se preveri,
- preveri se prisotnost oznake datoteke, kar pomeni, da je postopek zbiranja podatkov zaključen,
- podatki se razširijo na ustrezen lokalni nosilec,
- datoteka z oznako je izbrisana
Postopek obnovitve strežnika
Če glavni strežnik umre, se zažene podoben namenski strežnik, ki se zažene iz neke standardne slike. Najverjetneje bo prenos potekal prek omrežja, vendar lahko tehnik podatkovnega centra, ki postavlja strežnik, takoj kopira to standardno sliko na enega od diskov. Prenos poteka v RAM, po katerem se začne postopek obnovitve:
- podana je zahteva za priključitev blokovne naprave prek iscsinbd ali drugega podobnega protokola na logični nosilec, ki vsebuje korenski datotečni sistem preminulega strežnika; Ker mora biti korenski datotečni sistem majhen, je treba ta korak zaključiti v nekaj minutah. Obnovljen je tudi zagonski nalagalnik;
- struktura lokalnih logičnih nosilcev je ponovno ustvarjena, logični nosilci so priključeni iz rezervnega strežnika z uporabo jedrnega modula dm_clone: začne se obnovitev podatkov in spremembe se takoj zapišejo na lokalne diske
- vsebnik se zažene z vsemi razpoložljivimi fizičnimi diski - funkcionalnost strežnika je v celoti obnovljena, vendar z zmanjšano zmogljivostjo;
- po končani sinhronizaciji podatkov se logični nosilci iz rezervnega strežnika prekinejo, vsebnik se izklopi in strežnik se znova zažene;
Po ponovnem zagonu bo imel strežnik vse podatke, ki so bili tam v času, ko je bila varnostna kopija ustvarjena, in bo vključeval tudi vse spremembe, ki so bile narejene med postopkom obnovitve.
Drugi članki v seriji
Varnostno kopiranje, 7. del: Zaključki
Vabim vas, da v komentarjih razpravljate o predlagani možnosti, hvala za vašo pozornost!
Vir: www.habr.com