Aceasta notă finalizează ciclul despre backup. Se va discuta despre organizarea logică a serverului dedicat (sau VPS), convenabilă pentru backup, precum și o opțiune pentru recuperarea rapidă a serverului dintr-o copie de siguranță, fără întârzieri semnificative în caz de urgență.
Datele originale
Un server dedicat are de obicei cel puțin două hard diskuri, folosite pentru organizarea unui array RAID de tip 1 (oglindire). Acest lucru este necesar pentru a continua funcționarea serverului în cazul în care un disc se defectează. Dacă acesta este un server dedicat obișnuit, poate exista un controler RAID hardware separat, cu tehnologie activă de caching pe SSD, astfel încât, pe lângă hard diskurile comune, poate fi conectat unul sau mai multe SSD-uri. Uneori, se oferă servere dedicate care au doar SATADOM-uri (discuri mici, constructiv - un stick USB conectat la portul SATA), sau chiar un stick USB mic (8-16GB) conectat la un port intern special, iar datele sunt preluate de la un sistem de stocare conectat printr-o rețea dedicată de stocare (Ethernet 10G, FC etc.), și există servere dedicate care se boot-ează direct de pe sistemul de stocare. Aceste opțiuni nu le voi analiza, deoarece în aceste cazuri, responsabilitatea pentru backup-ul serverului trece către specialistul care întreține sistemul de stocare; de obicei, există diferite tehnologii proprietare pentru crearea instantaneelor de stare, deduplicare integrată și alte beneficii pentru administratorii de sistem, discutate în părțile anterioare ale acestui ciclu. Volumul array-ului de discuri al unui server dedicat poate atinge câteva zeci de terabytes, în funcție de numărul și dimensiunea discurilor conectate la server. În cazul VPS, volumele sunt mai mici: de obicei, nu mai mult de 100GB (deși pot fi și mai mari), iar tarifele pentru aceste VPS-uri pot fi chiar mai mari decât cele mai ieftine servere dedicate de la același provider. În mod obișnuit, un VPS are un singur disc, deoarece va fi conectat la un sistem de stocare (sau ceva hipercoperit). Uneori, un VPS poate avea mai multe discuri cu caracteristici diferite, pentru scopuri diferite:
- mic sistem — pentru instalarea sistemului de operare;
- mare — pentru stocarea datelor utilizatorilor.
Când se reinstalează sistemul prin intermediul panoului de control, discul cu datele utilizatorului nu este șters, însă cel de sistem este suprascris complet. De asemenea, în cazul VPS, furnizorul poate oferi un buton care face o captură a stării VPS-ului (sau a discului), însă dacă se instalează un sistem de operare propriu sau se uită să activeze serviciul necesar în VPS, o parte din date poate fi totuși pierdută. În plus față de buton, de obicei, se oferă un serviciu de stocare a datelor, care este de cele mai multe ori foarte limitat. În general, aceasta constă într-un cont cu acces prin protocol FTP sau SFTP, uneori împreună cu SSH, cu un shell restricționat (de exemplu, rbash) sau cu restricții în execuția comenzilor prin authorized_keys (prin ForcedCommand).
Serverul dedicat este conectat la rețea prin două porturi cu o viteză de 1 Gbps, uneori acestea pot fi carduri de 10 Gbps. La VPS, interfața de rețea este, de obicei, una singură. De cele mai multe ori, centrele de date nu limitează viteza rețelei în interiorul centrului de date, dar limitează viteza de acces la internet.
Încărcătura tipică a unui server dedicat sau a unui VPS constă în server web, bază de date, server de aplicații. Uneori, pot fi instalate diferite servicii auxiliare, inclusiv pentru serverul web sau baza de date: motor de căutare, sistem de poștă etc.
Ca spațiu pentru stocarea copiilor de siguranță este utilizat un server special pregătit, despre care se va scrie mai în detaliu mai târziu.
Organizarea logică a sistemului de fișiere
Dacă există un controler RAID sau aceasta este o VPS cu un singur disc și nu există preferințe speciale pentru funcționarea subsistemului de discuri (de exemplu, un disc rapid separat pentru baza de date) — tot spațiul liber se împarte astfel: se creează o partiție, deasupra căreia se creează un grup de volume LVM, în care se creează mai multe volume: 2 mici, de aceeași dimensiune, utilizate ca sistem de fișiere rădăcină (modificate alternativ la actualizări pentru a permite revenirea rapidă, idee inspirată de distribuția Calculate Linux), încă unul — pentru partiția de swap, restul spațiului liber se împarte în volume mici, utilizate ca sistem de fișiere rădăcină pentru containerele complete, discurile pentru mașinile virtuale, sistemele de fișiere pentru conturile din \/home (fiecare cont având propriul sistem de fișiere), sistemele de fișiere pentru containerele de aplicații.
Observație importantă: volumele trebuie să fie complet autonome, adică nu trebuie să depindă unele de altele, nici de sistemul de fișiere rădăcină. În cazul mașinilor virtuale sau containerelor, acest aspect este respectat automat. Dacă este vorba despre containere de aplicații sau directoare home — ar trebui să ne gândim la separarea fișierelor de configurare ale serverului web și altor servicii în așa fel încât să eliminăm maximum dependențele între volume. De exemplu, fiecare site funcționează de la propriul utilizator, fișierele de configurare ale site-ului se află în directorul home al utilizatorului, în setările serverului web, fișierele de configurare ale site-urilor sunt incluse nu prin \/etc\/nginx\/conf.d\/,.conf, ci, de exemplu, \/home\//configs/nginx/*.conf
Dacă sunt mai multe discuri — se poate crea un RAID software (și să-l configurați cu memorie cache pe SSD, dacă este nevoie și se pot face acest lucru), deasupra căruia se poate construi LVM conform regulilor propuse mai sus. De asemenea, în acest caz, se poate utiliza ZFS sau BtrFS, dar aici ar trebui să ne gândim de mai multe ori: ambele necesită o abordare mult mai serioasă față de resurse, mai mult, ZFS nu vine împreună cu kernelul Linux.
Indiferent de schema folosită, este întotdeauna bine să estimăm aproximativ viteza de scriere a modificărilor pe discuri, după care să calculăm dimensiunea spațiului liber care va fi rezervat pentru crearea instantaneelor. De exemplu, dacă serverul nostru va scrie date cu o viteză de 10 megabaiți pe secundă, iar dimensiunea totală a masei de date este de 10 terabaiți — timpul de sincronizare poate ajunge la o zi (22 de ore — atât va dura transmiterea acestui volum pe rețeaua de 1 Gbps) — ar trebui să rezervăm aproximativ 800 GB. În realitate, cifra va fi mai mică, o putem împărți fără probleme la numărul de volume logice.
Dispozitivul serverului de stocare a copiilor de rezervă
Principala diferență a serverului pentru stocarea copiilor de rezervă constă în discuri mari, ieftine și relativ lente. Deoarece HDD-urile moderne au depășit deja pragul de 10TB pe un disc — este esențială aplicarea sistemelor de fișiere sau RAID cu sume de control, deoarece în timpul reconstrucției masei sau restaurării sistemului de fișiere (câteva zile!) ar putea să cedeze al doilea disc din cauza unei sarcini mari. Pe discurile cu capacitate de până la 1TB acest aspect nu a fost atât de sensibil. Pentru simplificarea descrierii, presupun că spațiul pe disc este împărțit în două părți de aproximativ aceeași dimensiune (iarăși, de exemplu, cu ajutorul LVM):
- volumuri, corespunzătoare pe serverele folosite pentru stocarea datelor utilizatorilor (pe acestea va fi desfășurată ultima copie de rezervă realizată pentru verificare);
- volumuri, folosite ca repozitorii BorgBackup (aici vor ajunge direct datele pentru copiile de rezervă).
Principiul de funcționare constă în crearea de volume separate pentru fiecare server sub repozitoriile BorgBackup, unde vor ajunge datele din serverele de producție. Repozițiile funcționează în modul de adăugare exclusivă, ceea ce exclude posibilitatea ștergerii intenționate a datelor, iar prin deduplicare și curățarea periodică a repozitoriilor de copiile vechi de rezervă (rămân copiile anuale, lunare din ultimul an, săptămânale din ultima lună, zilnice din ultima săptămână, posibil — în cazuri speciale — orare din ultima zi: în total 24 + 7 + 4 + 12 + anuale — aproximativ 50 de copii pentru fiecare server).
În repositoarele BorgBackup nu se activează modul de doar adăugare, ci se folosește ForcedCommand în .ssh/authorized_keys de un fel similar:
from="adresa serverului",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.......Pe calea specificată se află un script wrapper deasupra borg, care, pe lângă lansarea binarului cu parametrii, inițiază de asemenea procesul de restaurare a unei copii de rezervă după terminarea captării datelor. Pentru aceasta, scriptul wrapper creează un fișier de semnalizare lângă repository-ul corespunzător. Ultima copie de rezervă realizată este restaurată automat pe volumul logic corespunzător după finalizarea procesului de încărcare a datelor.
Această construcție permite curățarea periodică a copiilor de rezervă inutile și, de asemenea, împiedică serverele de producție să șteargă ceva pe serverul de stocare a copiilor de rezervă.
Procesul de realizare a copiilor de rezervă
Inițiatorul procesului de copiere de rezervă este serverul dedicat sau VPS-ul, deoarece acest sistem oferă mai mult control asupra procesului de copiere de rezervă din partea acestui server. În primul rând, se realizează o captură a stării sistemului de fișiere rădăcină activ, care este montată și încarcată cu ajutorul BorgBackup pe serverul de stocare a copiilor de rezervă. După terminarea captării datelor, captura este demontată și ștearsă.
În cazul în care există o bază de date mică (de până la 1 GB pentru fiecare site), se face un dump al bazei de date, care este salvat pe volumul logic corespunzător, acolo unde se află și celelalte date ale aceluiași site, dar astfel încât dump-ul să nu fie accesibil prin serverul web. Dacă bazele de date sunt mari, ar trebui configurat un proces de captare de date „fierbinte”, de exemplu, folosind xtrabackup pentru MySQL sau funcționarea WAL cu archive_command în PostgreSQL. În acest caz, baza de date va fi restaurată separat de datele site-urilor.
Dacă se folosesc containere sau mașini virtuale, ar trebui configurat qemu-guest-agent, CRIU sau alte tehnologii necesare. În celelalte cazuri, de obicei nu sunt necesare setări suplimentare — pur și simplu creăm capturi ale volumelor logice, care sunt apoi procesate similar capturii stării sistemului de fișiere rădăcină. După captarea datelor, capturile sunt șterse.
Activitatea ulterioară se desfășoară pe serverul de stocare a copiilor de rezervă:
- se verifică ultima copie de rezervă realizată în fiecare depozit
- se verifică existența unui fișier de etichetare care indică faptul că procesul de realizare a copiilor de rezervă s-a finalizat
- se desfășoară desfășurarea datelor pe volumul local corespunzător
- se șterge fișierul de etichetare
Procesul de recuperare a funcționalității serverului
Dacă serverul principal cedează, se activează un server dedicat similar, care se încarcă dintr-o imagine standard. Cel mai probabil, încărcarea se va face prin rețea, însă tehnicianul din centrul de date care configurează serverul poate copia imediat această imagine standard pe unul dintre discuri. Încărcarea are loc în memoria RAM, după care se inițiază procesul de recuperare:
- se efectuează o solicitare pentru conectarea dispozitivului bloc la iscsinbd sau alt protocol similar de volum logic care conține sistemul de fișiere rădăcină al serverului avariat; deoarece sistemul de fișiere rădăcină trebuie să fie mic — această etapă trebuie să se finalizeze în câteva minute. De asemenea, se restaurează bootloader-ul;
- se reconstruieste structura volumelor logice locale, se atașează volumele logice de pe serverul de rezervă utilizând modulul kernel dm_clone: începe recuperarea datelor, iar modificările sunt înregistrate imediat pe discurile locale
- se pornește un container cu toate discurile fizice disponibile — funcționalitatea serverului este restabilită complet, dar cu performanțe reduse;
- după finalizarea sincronizării datelor, volumele logice de pe serverul de rezervă sunt deconectate, containerul este oprit, iar serverul este repornit;
După repornire, serverul va avea toate datele care existau în momentul realizării copiilor de rezervă, precum și toate modificările care au fost efectuate în timpul procesului de recuperare.
Alte articole din ciclu
Backup, partea 7: Concluzii
Vă invit să discutăm despre propunerea prezentată în comentarii, mulțumesc pentru atenție!
Sursa: habr.com
