Varukoopia 7. osa: Järeldused

Varukoopia 7. osa: Järeldused

See märkus lõpetab varundamise tsükli. See käsitleb spetsiaalse serveri (või VPS-i) loogilist ülesehitust, mis on mugav varundamiseks, ja pakub ka võimalust katastroofi korral serveri kiireks varukoopiast taastamiseks ilma suurema seisakuta.

Toorandmed

Spetsiaalsel serveril on enamasti vähemalt kaks kõvaketast, mida kasutatakse esimese taseme RAID-massiivi (peegli) korraldamiseks. See on vajalik serveri töö jätkamiseks, kui üks ketas ebaõnnestub. Kui see on tavaline spetsiaalne server, võib SSD-l olla eraldi riistvaraline RAID-kontroller koos aktiivse vahemällu salvestamise tehnoloogiaga, nii et lisaks tavalistele kõvaketastele saab ühendada ühe või mitu SSD-d. Mõnikord pakutakse spetsiaalseid servereid, mille kohalikud kettad sisaldavad ainult SATADOM-i (väikesed kettad, struktuurselt SATA-porti ühendatud välkmälu) või isegi tavalist väikest (8-16 GB) välkmälu, mis on ühendatud spetsiaalse sisemise pordiga ja andmed võetakse salvestussüsteemist, mis on ühendatud spetsiaalse salvestusvõrgu kaudu (Ethernet 10G, FC jne) ja seal on spetsiaalsed serverid, mis laaditakse otse salvestussüsteemist. Ma ei kaalu selliseid võimalusi, kuna sellistel juhtudel läheb serveri varundamise ülesanne sujuvalt üle salvestussüsteemi hooldavale spetsialistile; tavaliselt on hetktõmmiste loomiseks, sisseehitatud dubleerimiseks ja muudeks süsteemiadministraatori rõõmudeks mitmesuguseid patenteeritud tehnoloogiaid. , mida käsitleti selle sarja eelmistes osades. Spetsiaalse serveri kettamassiivi maht võib ulatuda mitmekümne terabaidini, olenevalt serveriga ühendatud ketaste arvust ja suurusest. VPS-i puhul on mahud tagasihoidlikumad: tavaliselt mitte rohkem kui 100GB (aga on ka rohkem) ja sellise VPS-i tariifid võivad vabalt olla kallimad kui sama hosti odavaimatel pühendatud serveritel. VPS-il on enamasti üks ketas, kuna selle all on salvestussüsteem (või midagi hüperkonvergeeritud). Mõnikord on VPS-il mitu erinevate omadustega ketast erinevatel eesmärkidel:

  • väike süsteem - operatsioonisüsteemi installimiseks;
  • suur - kasutajaandmete salvestamine.

Kui installite süsteemi uuesti juhtpaneeli abil, ei kirjutata kasutajaandmetega ketast üle, vaid süsteemiketas täidetakse täielikult. VPS-i puhul võib hoster pakkuda ka nuppu, mis teeb hetkepildi VPS-i (või ketta) olekust, kuid kui installite oma operatsioonisüsteemi või unustate VPS-i sees soovitud teenuse aktiveerida, andmed võivad siiski kaduda. Lisaks nupule pakutakse tavaliselt andmesalvestusteenust, enamasti väga piiratud. Tavaliselt on see konto, millel on juurdepääs FTP või SFTP kaudu, mõnikord koos SSH-ga, eemaldatud kestaga (nt rbash) või käskude käitamise piiranguga läbi authorised_keys (ForcedCommandi kaudu).

Spetsiaalne server on võrguga ühendatud kahe pordiga kiirusega 1 Gbps, mõnikord võivad need olla kaardid kiirusega 10 Gbps. VPS-il on enamasti üks võrguliides. Kõige sagedamini ei piira andmekeskused andmekeskuses võrgu kiirust, vaid piiravad Interneti-juurdepääsu kiirust.

Sellise spetsiaalse serveri või VPS-i tüüpiline koormus on veebiserver, andmebaas ja rakendusserver. Mõnikord võidakse installida mitmesuguseid lisateenuseid, sh veebiserveri või andmebaasi jaoks: otsingumootor, meilisüsteem jne.

Varukoopiate hoidmise ruumina toimib spetsiaalselt ettevalmistatud server, millest kirjutame hiljem täpsemalt.

Kettasüsteemi loogiline korraldus

Kui teil on RAID-kontroller või ühe kettaga VPS ja ketta alamsüsteemi tööks pole erilisi eelistusi (näiteks eraldi kiirketas andmebaasi jaoks), jagatakse kogu vaba ruum järgmiselt: üks partitsioon luuakse ja selle peale luuakse LVM-i köiterühm , sinna luuakse mitu köidet: 2 sama suurusega väikest, mida kasutatakse juurfailisüsteemina (värskenduste ajal ükshaaval muudetud kiire tagasipööramise võimaluseks, idee korjati üles Arvuta Linuxi distributsioonist), teine ​​on vahetuspartitsiooni jaoks, ülejäänud vaba ruum on jagatud väikesteks mahtudeks , kasutatakse täieõiguslike konteinerite juurfailisüsteemina, virtuaalmasinate kettad, fail süsteemid kontode jaoks /home (igal kontol on oma failisüsteem), failisüsteemid rakenduste konteinerite jaoks.

Oluline märkus: mahud peavad olema täiesti iseseisvad, s.t. ei tohiks sõltuda üksteisest ega juurfailisüsteemist. Virtuaalsete masinate või konteinerite puhul jälgitakse seda punkti automaatselt. Kui need on rakenduskonteinerid või kodukataloogid, tuleks mõelda veebiserveri ja muude teenuste konfiguratsioonifailide eraldamisele nii, et köidetevahelised sõltuvused jääksid võimalikult suureks. Näiteks töötab iga sait oma kasutajalt, saidi konfiguratsioonifailid on kasutaja kodukataloogis, veebiserveri seadetes ei sisaldu saidi konfiguratsioonifailid /etc/nginx/conf.d/ kaudu..conf ja näiteks /home//configs/nginx/*.conf

Kui kettaid on mitu, saate luua tarkvara RAID-massiivi (ja vajaduse ja võimaluse korral konfigureerida selle vahemällu SSD-le), mille peale saate ehitada LVM-i vastavalt ülaltoodud reeglitele. Ka sel juhul saate kasutada ZFS-i või BtrFS-i, kuid selle üle peaksite mõtlema: mõlemad nõuavad palju tõsisemat lähenemist ressurssidele ja pealegi pole ZFS-i Linuxi tuumaga kaasas.

Olenemata kasutatavast skeemist tasub alati eelnevalt hinnata muudatuste ketastele kirjutamise ligikaudset kiirust ja seejärel arvutada, kui palju vaba ruumi hetktõmmiste tegemiseks reserveeritakse. Näiteks kui meie server kirjutab andmeid kiirusega 10 megabaiti sekundis ja kogu andmemassiivi suurus on 10 terabaiti - võib sünkroonimisaeg ulatuda päevani (22 tundi - nii palju sellist mahtu edastatakse üle võrgu 1 Gbps) - tasub reserveerida umbes 800 GB . Tegelikkuses on see arv väiksem, võite selle julgelt jagada loogiliste mahtude arvuga.

Varundussalvestusserveri seade

Peamine erinevus varukoopiate salvestamise serveri vahel on selle suured, odavad ja suhteliselt aeglased kettad. Kuna tänapäevased kõvakettad on juba ületanud ühel kettal 10TB lati, siis on vaja kasutada failisüsteeme ehk RAID-i kontrollsummadega, sest massiivi ümberehitamise või failisüsteemi taastamise käigus (mitu päeva!) võib teine ​​ketas tõrkuda. suurenenud koormusele. Kuni 1TB mahuga ketaste puhul ei olnud see nii tundlik. Kirjelduse lihtsuse huvides eeldan, et kettaruum on jagatud kaheks ligikaudu võrdse suurusega osaks (jällegi näiteks LVM-i abil):

  • kasutajaandmete salvestamiseks kasutatavatele serveritele vastavad mahud (neile juurutatakse kontrollimiseks viimane tehtud varukoopia);
  • BorgBackupi hoidlatena kasutatavad mahud (varukoopiate andmed lähevad otse siia).

Tööpõhimõte seisneb selles, et BorgBackup hoidlate jaoks luuakse iga serveri jaoks eraldi köited, kuhu lähevad lahinguserverite andmed. Hoidlad töötavad ainult lisamise režiimis, mis välistab andmete tahtliku kustutamise võimaluse ning dubleerimise ja hoidlate perioodilise puhastamise tõttu vanadest varukoopiatest (säilivad iga-aastased koopiad, igakuiselt viimase aasta kohta, iganädalaselt viimase kuu kohta, iga päev eelmisel nädalal, võimalik, et erijuhtudel - iga tunni järel viimasel päeval: kokku 24 + 7 + 4 + 12 + aastas - umbes 50 eksemplari iga serveri kohta).
BorgBackupi hoidlad ei luba ainult lisamisrežiimi; selle asemel kasutatakse failis .ssh/authorized_keys käsku ForcedCommand umbes järgmiselt:

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.......

Määratud tee sisaldab borgi peal ümbrisskripti, mis lisaks parameetritega binaarfaili käivitamisele käivitab pärast andmete eemaldamist ka varukoopia taastamise. Selleks loob ümbrisskript vastava hoidla kõrvale sildifaili. Viimati tehtud varukoopia taastatakse automaatselt pärast andmete täitmise lõppu vastavasse loogilisse mahtu.

See disain võimaldab teil perioodiliselt puhastada mittevajalikke varukoopiaid ja takistab ka võitlusserveritel midagi varukoopiate salvestusserverist kustutamast.

Varundusprotsess

Varundamise algataja on spetsiaalne server või VPS ise, kuna see skeem annab selle serveri varundusprotsessi üle suurema kontrolli. Kõigepealt tehakse aktiivse juurfailisüsteemi olekust hetktõmmis, mis ühendatakse ja laaditakse BorgBackupi abil üles varukoopiate salvestusserverisse. Pärast andmete kogumise lõpetamist eemaldatakse hetktõmmis ja see kustutatakse.

Kui on väike andmebaas (kuni 1 GB iga saidi kohta), tehakse andmebaasi dump, mis salvestatakse vastavasse loogilisse mahusse, kus asuvad ülejäänud sama saidi andmed, kuid nii, et väljavõte oleks pole veebiserveri kaudu ligipääsetav. Kui andmebaasid on suured, peaksite konfigureerima "kuuma" andmete eemaldamise, näiteks kasutades MySQL-i jaoks xtrabackupi või töötama WAL-iga koos PostgreSQL-i käsuga archive_command. Sel juhul taastatakse andmebaas saidi andmetest eraldi.

Kui kasutatakse konteinereid või virtuaalmasinaid, peaksite konfigureerima qemu-guest-agent, CRIU või muud vajalikud tehnoloogiad. Muudel juhtudel pole lisaseadeid enamasti vaja – loome lihtsalt loogilistest köidetest hetktõmmised, mida seejärel töödeldakse samamoodi nagu juurfailisüsteemi oleku hetktõmmist. Pärast andmete salvestamist pildid kustutatakse.

Varundusmäluserveris tehakse täiendavat tööd:

  • kontrollitakse igas hoidlas viimast varukoopiat,
  • kontrollitakse märgifaili olemasolu, mis näitab, et andmete kogumise protsess on lõpule viidud,
  • andmed laiendatakse vastavale kohalikule mahule,
  • sildifail kustutatakse

Serveri taastamise protsess

Kui põhiserver sureb välja, käivitatakse sarnane spetsiaalne server, mis käivitub mõnest standardpildist. Tõenäoliselt toimub allalaadimine üle võrgu, kuid serverit seadistav andmekeskuse tehnik saab selle standardpildi kohe ühele kettale kopeerida. Allalaadimine toimub RAM-i, mille järel algab taasteprotsess:

  • esitatakse taotlus lisada iscsinbd või muu sarnase protokolli kaudu plokkseade surnud serveri juurfailisüsteemi sisaldavale loogilisele köitele; Kuna juurfailisüsteem peab olema väike, peaks see samm mõne minutiga lõpule jõudma. Samuti taastatakse alglaadur;
  • kohalike loogikaköidete struktuur luuakse uuesti, loogikaköiteid manustatakse varuserverist kerneli mooduli dm_clone abil: algab andmete taastamine ja muudatused kirjutatakse kohe kohalikele ketastele
  • konteiner käivitatakse kõigi saadaolevate füüsiliste ketastega - serveri funktsionaalsus on täielikult taastatud, kuid vähenenud jõudlusega;
  • pärast andmete sünkroonimise lõpetamist katkestatakse varuserveri loogiliste köite ühendus, konteiner lülitatakse välja ja server taaskäivitatakse;

Pärast taaskäivitamist on serveril kõik andmed, mis olid seal varukoopia loomise ajal, ning sisaldab ka kõiki taastamisprotsessi käigus tehtud muudatusi.

Sarja teised artiklid

Varundamine, 1. osa: Miks on vaja varundada, ülevaade meetoditest, tehnoloogiatest
Varundamine 2. osa: rsynci-põhiste varundustööriistade ülevaatamine ja testimine
Varukoopia 3. osa: kahepalgelisuse ülevaatus ja testimine, duplikaadid
Varundamine 4. osa: zbackup, restic, borgbackup ülevaatamine ja testimine
Varukoopia 5. osa: Bacula ja Veeam Backupi testimine Linuxi jaoks
Varundamine: osa lugejate soovil: AMANDA, UrBackup, BackupPC ülevaade
Varundamine 6. osa: varundustööriistade võrdlemine
Varukoopia 7. osa: Järeldused

Kutsun teid kommentaarides pakutud võimalust arutama, tänan tähelepanu eest!

Allikas: www.habr.com

Lisa kommentaar