Rezervni dio 7: Zaključci

Rezervni dio 7: Zaključci

Ova bilješka dovršava ciklus o sigurnosnom kopiranju. Raspravljat će se o logičnoj organizaciji namjenskog poslužitelja (ili VPS-a), pogodnog za sigurnosno kopiranje, a također će ponuditi opciju za brzo vraćanje poslužitelja iz sigurnosne kopije bez puno zastoja u slučaju katastrofe.

Početni podaci

Namjenski poslužitelj najčešće ima najmanje dva tvrda diska koji služe za organiziranje RAID polja prve razine (mirror). Ovo je neophodno kako bi se mogao nastaviti s radom poslužitelja ako jedan disk zakaže. Ako se radi o običnom namjenskom poslužitelju, može postojati zaseban hardverski RAID kontroler s tehnologijom aktivnog predmemoriranja na SSD-u, tako da se uz obične tvrde diskove može spojiti jedan ili više SSD-ova. Ponekad se nude namjenski poslužitelji u kojima su jedini lokalni diskovi SATADOM (mali diskovi, strukturno flash pogon spojen na SATA priključak), ili čak obični mali (8-16 GB) flash pogon spojen na poseban unutarnji priključak, a podaci se preuzimaju iz sustava za pohranu podataka, povezani su putem namjenske mreže za pohranu (Ethernet 10G, FC itd.), a postoje i namjenski poslužitelji koji se učitavaju izravno iz sustava za pohranu. Neću razmatrati takve opcije, jer u takvim slučajevima zadatak sigurnosne kopije poslužitelja glatko prelazi na stručnjaka koji održava sustav za pohranu; obično postoje razne vlasničke tehnologije za stvaranje snimaka, ugrađenu deduplikaciju i druge radosti administratora sustava , o kojima se raspravljalo u prethodnim dijelovima ove serije. Volumen diskovnog polja namjenskog poslužitelja može doseći nekoliko desetaka terabajta, ovisno o broju i veličini diskova spojenih na poslužitelj. U slučaju VPS-a, količine su skromnije: obično ne više od 100 GB (ali ima ih i više), a tarife za takav VPS lako mogu biti skuplje od najjeftinijih namjenskih poslužitelja istog hostera. VPS najčešće ima jedan disk, jer će ispod njega biti sustav za pohranu (ili nešto hiperkonvergirano). Ponekad VPS ima nekoliko diskova različitih karakteristika, za različite namjene:

  • mali sustav - za instalaciju operativnog sustava;
  • veliki - pohranjivanje korisničkih podataka.

Kada ponovno instalirate sustav pomoću upravljačke ploče, disk s korisničkim podacima se ne prepisuje, ali se sistemski disk potpuno ponovno puni. Također, u slučaju VPS-a, hoster može ponuditi gumb koji snima snimku stanja VPS-a (ili diska), no ako instalirate vlastiti operativni sustav ili zaboravite aktivirati željenu uslugu unutar VPS-a, neki podataka još uvijek može biti izgubljeno. Uz gumb obično se nudi usluga pohrane podataka, najčešće vrlo ograničena. Obično je to račun s pristupom putem FTP-a ili SFTP-a, ponekad zajedno sa SSH-om, sa skraćenom ljuskom (na primjer, rbash) ili ograničenjem pokretanja naredbi putem authorized_keys (putem ForcedCommand).

Dedicirani poslužitelj povezan je s mrežom s dva porta brzine 1 Gbps, ponekad to mogu biti kartice brzine 10 Gbps. VPS najčešće ima jedno mrežno sučelje. Podatkovni centri najčešće ne ograničavaju brzinu mreže unutar podatkovnog centra, ali ograničavaju brzinu pristupa Internetu.

Tipično opterećenje takvog namjenskog poslužitelja ili VPS-a je web poslužitelj, baza podataka i aplikacijski poslužitelj. Ponekad se mogu instalirati razne dodatne pomoćne usluge, uključujući za web poslužitelj ili bazu podataka: tražilica, sustav pošte itd.

Kao prostor za pohranjivanje rezervnih kopija služi posebno pripremljen poslužitelj, o čemu ćemo detaljnije pisati kasnije.

Logička organizacija diskovnog sustava

Ako imate RAID kontroler, ili VPS s jednim diskom, a nema posebnih postavki za rad diskovnog podsustava (npr. zaseban brzi disk za bazu podataka), sav slobodni prostor dijeli se na sljedeći način: jedna particija kreira se, a na njemu se stvara LVM grupa volumena, u njemu se stvara nekoliko volumena: 2 mala iste veličine, koja se koriste kao korijenski datotečni sustav (mijenjaju se jedan po jedan tijekom ažuriranja radi mogućnosti brzog vraćanja, ideja je preuzeta iz distribucije Calculate Linux), druga je za swap particiju, ostatak slobodnog prostora podijeljen je u male volumene, koji se koriste kao korijenski datotečni sustav za pune spremnike, diskove za virtualne strojeve, datoteke sustavi za račune u /home (svaki račun ima svoj vlastiti datotečni sustav), datotečni sustavi za spremnike aplikacija.

Važna napomena: volumeni moraju biti potpuno samostalni, tj. ne bi trebali ovisiti jedan o drugome ili o korijenskom datotečnom sustavu. U slučaju virtualnih strojeva ili spremnika, ova se točka promatra automatski. Ako su to spremnici aplikacija ili kućni direktoriji, trebali biste razmisliti o odvajanju konfiguracijskih datoteka web poslužitelja i drugih usluga na takav način da eliminirate ovisnosti između volumena što je više moguće. Na primjer, svako web mjesto pokreće vlastiti korisnik, konfiguracijske datoteke web mjesta nalaze se u početnom direktoriju korisnika, u postavkama web poslužitelja, konfiguracijske datoteke web mjesta nisu uključene putem /etc/nginx/conf.d/.conf i, na primjer, /home//configs/nginx/*.conf

Ako postoji nekoliko diskova, možete stvoriti softverski RAID niz (i konfigurirati njegovo predmemoriranje 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 dobro razmislite o ovome: oba zahtijevaju puno ozbiljniji pristup resursima, a osim toga, ZFS nije uključen u Linux kernel.

Bez obzira na shemu koja se koristi, uvijek je vrijedno unaprijed procijeniti približnu brzinu zapisivanja promjena na diskove, a zatim izračunati količinu slobodnog prostora koji će biti rezerviran za stvaranje snimki. Na primjer, ako naš poslužitelj zapisuje podatke brzinom od 10 megabajta u sekundi, a veličina čitavog niza podataka je 10 terabajta - vrijeme sinkronizacije može doseći dan (22 sata - toliko će se takav volumen prenijeti preko mreže 1 Gbps) - vrijedi rezervirati oko 800 GB. U stvarnosti će brojka biti manja; možete je sigurno podijeliti s brojem logičkih volumena.

Uređaj poslužitelja za sigurnosnu pohranu

Glavna razlika između poslužitelja za pohranu sigurnosnih kopija su veliki, jeftini i relativno spori diskovi. Budući da su moderni HDD-ovi već prešli granicu od 10TB na jednom disku, potrebno je koristiti datotečne sustave ili RAID s kontrolnim zbrojevima, jer tijekom ponovne izgradnje niza ili vraćanja datotečnog sustava (nekoliko dana!) drugi disk može otkazati zbog na povećano opterećenje. 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, npr. pomoću LVM-a):

  • volumeni koji odgovaraju poslužiteljima koji se koriste za pohranjivanje korisničkih podataka (zadnja napravljena sigurnosna kopija bit će raspoređena na njima radi provjere);
  • volumeni koji se koriste kao BorgBackup spremišta (podaci za sigurnosne kopije ići će izravno ovdje).

Načelo rada je da se za svaki poslužitelj kreiraju zasebni volumeni za BorgBackup repozitorije, gdje će ići podaci s borbenih poslužitelja. Repozitoriji rade u načinu samo dodavanja, čime se eliminira mogućnost namjernog brisanja podataka, a zbog deduplikacije i periodičnog čišćenja repozitorija od starih sigurnosnih kopija (ostaju godišnje kopije, mjesečne za prošlu godinu, tjedne za zadnji mjesec, dnevne za prošli tjedan, eventualno u posebnim slučajevima - po satu za zadnji dan: ukupno 24 + 7 + 4 + 12 + godišnje - približno 50 kopija za svaki poslužitelj).
BorgBackup repozitoriji ne omogućuju način samo za dodavanje; umjesto toga, ForcedCommand u .ssh/authorized_keys koristi se 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 staza sadrži wrapper skriptu na vrhu borga, koja osim pokretanja binarne datoteke s parametrima, dodatno pokreće proces vraćanja sigurnosne kopije nakon uklanjanja podataka. Da biste to učinili, omotna skripta stvara datoteku oznake pored odgovarajućeg repozitorija. Posljednja napravljena sigurnosna kopija automatski se vraća na odgovarajući logički volumen nakon dovršetka procesa popunjavanja podataka.

Ovaj dizajn vam omogućuje povremeno čišćenje nepotrebnih sigurnosnih kopija, a također sprječava borbene poslužitelje da izbrišu bilo što na poslužitelju za pohranu rezervnih kopija.

Proces izrade sigurnosne kopije

Inicijator sigurnosne kopije je sam namjenski poslužitelj ili VPS, budući da ova shema daje veću kontrolu nad procesom sigurnosne kopije od strane ovog poslužitelja. Prvo se snima snimka stanja aktivnog korijenskog datotečnog sustava, koji se montira i učitava pomoću BorgBackup-a na poslužitelj za pohranu pričuvnih kopija. Nakon dovršetka snimanja podataka, snimka se demontira i briše.

Ako postoji mala baza podataka (do 1 GB za svako mjesto), radi se dump baze podataka koji se sprema u odgovarajući logički volumen, gdje se nalaze i ostali podaci za isto mjesto, ali tako da se dump nije dostupan putem web poslužitelja. Ako su baze podataka velike, trebali biste konfigurirati "vruće" uklanjanje podataka, na primjer, koristeći xtrabackup za MySQL ili raditi s WAL-om s archive_command u PostgreSQL-u. U tom će se slučaju baza podataka obnoviti odvojeno od podataka o web-mjestu.

Ako se koriste spremnici ili virtualni strojevi, trebali biste konfigurirati qemu-guest-agent, CRIU ili druge potrebne tehnologije. U drugim slučajevima dodatne postavke najčešće nisu potrebne - jednostavno stvaramo snimke logičkih jedinica, koje se zatim obrađuju na isti način kao i snimka stanja korijenskog datotečnog sustava. Nakon snimanja podataka, slike se brišu.

Daljnji rad se provodi na poslužitelju za sigurnosnu pohranu:

  • provjerava se zadnja sigurnosna kopija napravljena u svakom repozitoriju,
  • provjerava se prisutnost oznake oznake, što pokazuje da je proces prikupljanja podataka završen,
  • podaci se proširuju na odgovarajući lokalni volumen,
  • datoteka oznake se briše

Proces oporavka poslužitelja

Ako glavni poslužitelj umre, tada se pokreće sličan namjenski poslužitelj, koji se diže s neke standardne slike. Najvjerojatnije će se preuzimanje odvijati preko mreže, ali tehničar podatkovnog centra koji postavlja poslužitelj može odmah kopirati ovu standardnu ​​sliku na jedan od diskova. Preuzimanje se odvija u RAM, nakon čega počinje proces oporavka:

  • postavljen je zahtjev za pripajanje blok uređaja putem iscsinbd ili drugog sličnog protokola na logički volumen koji sadrži korijenski datotečni sustav preminulog poslužitelja; Budući da korijenski datotečni sustav mora biti mali, ovaj bi korak trebao biti dovršen za nekoliko minuta. Bootloader je također vraćen;
  • ponovno se stvara struktura lokalnih logičkih volumena, logički volumeni se priključuju sa backup poslužitelja pomoću dm_clone kernel modula: počinje oporavak podataka, a promjene se odmah zapisuju na lokalne diskove
  • spremnik se pokreće sa svim dostupnim fizičkim diskovima - funkcionalnost poslužitelja je u potpunosti vraćena, ali sa smanjenom izvedbom;
  • nakon dovršetka sinkronizacije podataka, logički volumeni s rezervnog poslužitelja se odspajaju, spremnik se isključuje i poslužitelj se ponovno pokreće;

Nakon ponovnog pokretanja, poslužitelj će imati sve podatke koji su bili tamo u trenutku stvaranja sigurnosne kopije, a također će uključivati ​​sve promjene koje su napravljene tijekom procesa vraćanja.

Ostali članci u seriji

Backup, 1. dio: Zašto je backup potreban, pregled metoda, tehnologija
Sigurnosno kopiranje, 2. dio: Pregled i testiranje alata za sigurnosno kopiranje temeljenih na rsync
Sigurnosna kopija 3. dio: Pregled i testiranje dvostrukosti, duplicati
Sigurnosna kopija 4. dio: Pregled i testiranje zbackup, restic, borgbackup
Backup Dio 5: Testiranje Bacula i Veeam Backup za Linux
Sigurnosna kopija: dio na zahtjev čitatelja: recenzija AMANDA, UrBackup, BackupPC
Sigurnosno kopiranje, 6. dio: Usporedba alata za sigurnosno kopiranje
Rezervni dio 7: Zaključci

Pozivam vas da raspravite predloženu opciju u komentarima, hvala na pažnji!

Izvor: www.habr.com

Dodajte komentar