Ovom napomenom se završava ciklus oko sigurnosnog kopiranja. Razgovaraće se o logičkoj organizaciji namenskog servera (ili VPS-a), pogodnog za pravljenje rezervnih kopija, a takođe će se ponuditi opcija za brzo vraćanje servera iz rezervne kopije bez mnogo zastoja u slučaju katastrofe.
Sirovi podaci
Namenski server najčešće ima najmanje dva čvrsta diska koji služe za organizovanje RAID niza (ogledalo) prvog nivoa. Ovo je neophodno za nastavak rada servera ako jedan disk pokvari. Ako se radi o običnom namenskom serveru, može postojati poseban hardverski RAID kontroler sa aktivnom tehnologijom keširanja na SSD-u, tako da se pored običnih čvrstih diskova može povezati jedan ili više SSD-ova. Ponekad se nude namjenski serveri u kojima su jedini lokalni diskovi SATADOM (mali diskovi, strukturno fleš disk spojen na SATA port), ili čak običan mali (8-16GB) fleš disk povezan na poseban interni port, a podaci se preuzimaju iz sistema za skladištenje podataka, povezani preko namenske mreže za skladištenje podataka (Ethernet 10G, FC, itd.), a postoje namenski serveri koji se učitavaju direktno iz sistema za skladištenje podataka. Neću razmatrati takve opcije, jer u takvim slučajevima zadatak sigurnosne kopije servera glatko prelazi na stručnjaka koji održava sistem za pohranu; obično postoje različite vlasničke tehnologije za kreiranje snimaka, ugrađenu deduplikaciju i druge radosti administratora sistema , o kojoj se govorilo u prethodnim dijelovima ove serije. Volumen diskovnog niza namenskog servera može doseći nekoliko desetina terabajta, u zavisnosti od broja i veličine diskova povezanih sa serverom. U slučaju VPS-a, količine su skromnije: obično ne više od 100GB (ali ima ih i više), a tarife za takav VPS lako mogu biti skuplje od najjeftinijih namjenskih servera sa istog hostera. VPS najčešće ima jedan disk, jer će se ispod njega nalaziti sistem za skladištenje podataka (ili nešto hiperkonvergirano). Ponekad VPS ima nekoliko diskova različitih karakteristika, za različite svrhe:
- mali sistem - za instaliranje operativnog sistema;
- veliki - pohranjivanje korisničkih podataka.
Kada ponovo instalirate sistem pomoću kontrolne table, disk sa korisničkim podacima se ne prepisuje, već se sistemski disk potpuno ponovo puni. Takođe, u slučaju VPS-a, hoster može ponuditi dugme koje pravi snimak stanja VPS-a (ili diska), ali ako instalirate sopstveni operativni sistem ili zaboravite da aktivirate željenu uslugu unutar VPS-a, neki podataka se i dalje može izgubiti. Uz dugme, obično se nudi i usluga skladištenja podataka, najčešće vrlo ograničena. Obično je ovo nalog s pristupom preko FTP-a ili SFTP-a, ponekad zajedno sa SSH-om, sa smanjenom ljuskom (na primjer, rbash) ili ograničenjem pokretanja komandi preko authorized_keys (preko ForcedCommand).
Namjenski server je povezan na mrežu preko dva porta brzinom od 1 Gbps, ponekad to mogu biti kartice brzine od 10 Gbps. VPS najčešće ima jedno mrežno sučelje. Data centri najčešće ne ograničavaju brzinu mreže unutar data centra, ali ograničavaju brzinu pristupa Internetu.
Tipično opterećenje takvog namenskog servera ili VPS-a je veb server, baza podataka i server aplikacija. Ponekad se mogu instalirati razne dodatne pomoćne usluge, uključujući web server ili bazu podataka: pretraživač, sistem pošte itd.
Posebno pripremljen server služi kao prostor za pohranjivanje rezervnih kopija, o čemu ćemo detaljnije pisati kasnije.
Logička organizacija disk sistema
Ako imate RAID kontroler ili VPS sa jednim diskom, a nema posebnih preferencija za rad podsistema diska (na primjer, odvojeni brzi disk za bazu podataka), sav slobodni prostor se dijeli na sljedeći način: jedna particija se kreira, a na vrhu se kreira LVM grupa volumena, u njoj se kreira nekoliko volumena: 2 mala iste veličine, koji se koriste kao korijenski sistem datoteka (promijenjeni jedan po jedan tokom ažuriranja radi mogućnosti brzog vraćanja, ideja je preuzeta iz Calculate Linux distribucije), druga je za swap particiju, ostatak slobodnog prostora je podijeljen na male volumene, koristi se kao root datotečni sistem za punopravne kontejnere, diskove za virtuelne mašine, fajl sistemi za naloge u /home (svaki nalog ima svoj sistem datoteka), sistem datoteka za kontejnere aplikacija.
Važna napomena: sveske moraju biti potpuno samostalne, tj. ne bi trebali ovisiti jedno o drugom ili o korijenskom sistemu datoteka. U slučaju virtuelnih mašina ili kontejnera, ova tačka se posmatra automatski. Ako su to kontejneri aplikacija ili kućni direktoriji, trebali biste razmisliti o odvajanju konfiguracijskih datoteka web servera i drugih usluga na takav način da eliminišete ovisnosti između volumena što je više moguće. Na primjer, svaka stranica se pokreće od svog korisnika, konfiguracijske datoteke stranice su u korisničkom početnom direktoriju, u postavkama web servera, konfiguracijske datoteke stranice nisu uključene putem /etc/nginx/conf.d/.conf i, na primjer, /home//configs/nginx/*.conf
Ako postoji nekoliko diskova, možete kreirati softverski RAID niz (i konfigurirati njegovo keširanje na SSD-u, ako postoji potreba i prilika), na vrhu kojeg možete izgraditi LVM prema gore predloženim pravilima. I u ovom slučaju možete koristiti ZFS ili BtrFS, ali treba dvaput razmisliti o tome: oba zahtijevaju mnogo ozbiljniji pristup resursima, a osim toga, ZFS nije uključen u Linux kernel.
Bez obzira na korištenu shemu, uvijek je vrijedno unaprijed procijeniti približnu brzinu upisivanja promjena na diskove, a zatim izračunati količinu slobodnog prostora koji će biti rezerviran za kreiranje snimaka. Na primjer, ako naš server piše podatke brzinom od 10 megabajta u sekundi, a veličina cijelog niza podataka je 10 terabajta - vrijeme sinhronizacije može doseći dan (22 sata - ovo je koliko će se takav volumen prenijeti preko mreže 1 Gbps) - vrijedi rezervirati oko 800 GB . U stvarnosti, brojka će biti manja; možete je sigurno podijeliti brojem logičkih volumena.
Serverski uređaj za pohranu rezervnih kopija
Glavna razlika između servera za pohranjivanje rezervnih kopija su njegovi veliki, jeftini i relativno spori diskovi. Budući da su moderni HDD-ovi već prešli granicu od 10TB na jednom disku, neophodno je koristiti sisteme datoteka ili RAID sa kontrolnim sumovima, jer tokom rekonstrukcije niza ili restauracije sistema datoteka (nekoliko dana!) može doći do kvara drugog diska zbog kvara. do povećanog opterećenja. Na diskovima kapaciteta do 1TB to nije bilo tako osjetljivo. Radi jednostavnosti opisa, pretpostavljam da je prostor na disku podijeljen na dva dijela približno jednake veličine (opet, na primjer, koristeći LVM):
- volumeni koji odgovaraju serverima koji se koriste za pohranjivanje korisničkih podataka (posljednja napravljena sigurnosna kopija će biti raspoređena na njima radi provjere);
- volumeni koji se koriste kao BorgBackup spremišta (podaci za sigurnosne kopije će ići direktno ovdje).
Princip rada je da se za svaki server kreiraju zasebni volumeni za BorgBackup repozitorije, gdje će ići podaci sa borbenih servera. Spremišta rade u načinu samo dodavanja, što eliminiše mogućnost namjernog brisanja podataka, a zbog deduplikacije i periodičnog čišćenja spremišta iz starih rezervnih kopija (ostaju godišnje kopije, mjesečno za prošlu godinu, sedmično za zadnji mjesec, dnevno za prošle sedmice, moguće u posebnim slučajevima - svaki sat za zadnji dan: ukupno 24 + 7 + 4 + 12 + godišnji - otprilike 50 kopija za svaki server).
BorgBackup spremišta ne omogućavaju način rada samo za dodavanje; umjesto toga, ForcedCommand u .ssh/authorized_keys se koristi otprilike ovako:
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 putanja sadrži skriptu omotača na vrhu borga, koja pored pokretanja binarne datoteke sa parametrima dodatno pokreće proces vraćanja rezervne kopije nakon uklanjanja podataka. Da bi to uradila, skripta omotača kreira datoteku oznake pored odgovarajućeg spremišta. Posljednja napravljena sigurnosna kopija se automatski vraća na odgovarajući logički volumen nakon završetka procesa popunjavanja podataka.
Ovaj dizajn vam omogućava da povremeno čistite nepotrebne sigurnosne kopije, a također sprječava borbene servere da izbrišu bilo šta na serveru za pohranu rezervnih kopija.
Backup Proces
Inicijator izrade rezervne kopije je namenski server ili sam VPS, jer ova šema daje veću kontrolu nad procesom pravljenja rezervne kopije od strane ovog servera. Prvo se pravi snimak stanja aktivnog korijenskog sistema datoteka, koji se montira i postavlja pomoću BorgBackupa na server za pohranu rezervnih kopija. Nakon što je snimanje podataka završeno, snimak se demontira i briše.
Ako postoji mala baza podataka (do 1 GB za svaku lokaciju), pravi se dump baze podataka koji se pohranjuje u odgovarajući logički volumen, gdje se nalazi i ostatak podataka za istu lokaciju, ali tako da je dump nije dostupno preko web servera. Ako su baze podataka velike, trebali biste konfigurirati „hot“ uklanjanje podataka, na primjer, koristeći xtrabackup za MySQL, ili raditi sa WAL-om sa archive_command u PostgreSQL-u. U tom slučaju, baza podataka će biti vraćena odvojeno od podataka o lokaciji.
Ako se koriste kontejneri ili virtuelne mašine, trebalo bi da konfigurišete qemu-guest-agent, CRIU ili druge potrebne tehnologije. U drugim slučajevima dodatna podešavanja najčešće nisu potrebna - jednostavno kreiramo snimke logičkih volumena, koje se zatim obrađuju na isti način kao i snimak stanja korijenskog sistema datoteka. Nakon snimanja podataka, slike se brišu.
Dalji rad se obavlja na serveru za pohranu rezervnih kopija:
- provjerava se zadnja sigurnosna kopija napravljena u svakom spremištu,
- provjerava se prisustvo datoteke sa oznakama, što ukazuje da je proces prikupljanja podataka završen,
- podaci se proširuju na odgovarajući lokalni volumen,
- tag datoteka je izbrisana
Proces oporavka servera
Ako glavni server umre, onda se pokreće sličan namenski server koji se pokreće sa neke standardne slike. Najvjerovatnije će se preuzimanje odvijati preko mreže, ali tehničar podatkovnog centra koji postavlja server može odmah kopirati ovu standardnu sliku na jedan od diskova. Preuzimanje se događa u RAM, nakon čega počinje proces oporavka:
- podnosi se zahtjev za priključivanje blok uređaja putem iscsinbd ili drugog sličnog protokola na logički volumen koji sadrži korijenski sistem datoteka preminulog servera; Budući da korijenski sistem datoteka mora biti mali, ovaj korak bi trebao biti završen za nekoliko minuta. Bootloader je također vraćen;
- struktura lokalnih logičkih volumena je ponovo kreirana, logički volumeni su pridruženi sa backup servera pomoću modula kernela dm_clone: oporavak podataka počinje, a promjene se odmah upisuju na lokalne diskove
- pokreće se kontejner sa svim dostupnim fizičkim diskovima - funkcionalnost servera je potpuno vraćena, ali sa smanjenim performansama;
- nakon što je sinhronizacija podataka završena, logički volumeni sa backup servera se prekidaju, kontejner se isključuje i server se ponovo pokreće;
Nakon ponovnog pokretanja, server će imati sve podatke koji su bili tamo u vrijeme kreiranja sigurnosne kopije, a uključit će i sve promjene koje su napravljene tokom procesa vraćanja.
Ostali članci u seriji
Rezervni dio 7: Zaključci
Pozivam vas da razgovarate o predloženoj opciji u komentarima, hvala na pažnji!
izvor: www.habr.com