Această notă completează ciclul despre backup. Se va discuta despre organizarea logică a unui server dedicat (sau VPS), convenabil pentru backup și va oferi, de asemenea, o opțiune pentru restaurarea rapidă a unui server dintr-o copie de rezervă, fără mult timp de nefuncționare în cazul unui dezastru.
Datele brute
Un server dedicat are cel mai adesea cel puțin două hard disk-uri care servesc la organizarea unei matrice RAID de prim nivel (oglindă). Acest lucru este necesar pentru a putea continua operarea serverului în cazul în care un disc eșuează. Dacă acesta este un server dedicat obișnuit, este posibil să existe un controler hardware RAID separat cu tehnologie de cache activă pe SSD, astfel încât, pe lângă hard disk-urile obișnuite, să poată fi conectate unul sau mai multe SSD-uri. Uneori sunt oferite servere dedicate, în care singurele discuri locale sunt SATADOM (discuri mici, structural o unitate flash conectată la un port SATA), sau chiar o unitate flash obișnuită mică (8-16 GB) conectată la un port intern special și datele sunt preluate din sistemul de stocare, conectat printr-o rețea de stocare dedicată (Ethernet 10G, FC, etc.), și există servere dedicate care sunt încărcate direct din sistemul de stocare. Nu voi lua în considerare astfel de opțiuni, deoarece în astfel de cazuri sarcina de a face backup la server trece fără probleme specialistului care întreține sistemul de stocare; de obicei, există diverse tehnologii proprietare pentru crearea de instantanee, deduplicare încorporată și alte bucurii ale administratorului de sistem. , discutat în părțile anterioare ale acestei serii. Volumul matricei de discuri a unui server dedicat poate atinge câteva zeci de teraocteți, în funcție de numărul și dimensiunea discurilor conectate la server. În cazul VPS-urilor, volumele sunt mai modeste: de obicei nu mai mult de 100 GB (dar sunt și mai multe), iar tarifele pentru un astfel de VPS pot fi cu ușurință mai scumpe decât cele mai ieftine servere dedicate de la același hoster. Un VPS are cel mai adesea un singur disc, pentru că va exista un sistem de stocare (sau ceva hiperconvergent) sub el. Uneori, un VPS are mai multe discuri cu caracteristici diferite, în scopuri diferite:
- sistem mic - pentru instalarea sistemului de operare;
- mare - stocarea datelor utilizatorului.
Când reinstalați sistemul utilizând panoul de control, discul cu datele utilizatorului nu este suprascris, dar discul de sistem este complet reumplut. De asemenea, în cazul unui VPS, hosterul poate oferi un buton care face un instantaneu al stării VPS-ului (sau discului), dar dacă vă instalați propriul sistem de operare sau uitați să activați serviciul dorit în interiorul VPS-ului, unele din datele se pot pierde în continuare. Pe lângă buton, de obicei este oferit un serviciu de stocare a datelor, cel mai adesea foarte limitat. Acesta este de obicei un cont cu acces prin FTP sau SFTP, uneori împreună cu SSH, cu un shell redus (de exemplu, rbash) sau o restricție privind rularea comenzilor prin authorized_keys (prin ForcedCommand).
Un server dedicat este conectat la rețea prin două porturi cu o viteză de 1 Gbps, uneori acestea pot fi carduri cu o viteză de 10 Gbps. VPS are cel mai adesea o singură interfață de rețea. Cel mai adesea, centrele de date nu limitează viteza rețelei în cadrul centrului de date, ci limitează viteza de acces la Internet.
Sarcina tipică a unui astfel de server dedicat sau VPS este un server web, o bază de date și un server de aplicații. Uneori pot fi instalate diverse servicii auxiliare suplimentare, inclusiv pentru un server web sau bază de date: motor de căutare, sistem de e-mail etc.
Un server special pregătit acționează ca un spațiu pentru stocarea copiilor de rezervă; despre el vom scrie mai detaliat mai târziu.
Organizarea logică a sistemului de discuri
Dacă aveți un controler RAID sau un VPS cu un singur disc și nu există preferințe speciale pentru funcționarea subsistemului de disc (de exemplu, un disc rapid separat pentru o bază de date), tot spațiul liber este împărțit după cum urmează: o partiție este creat și deasupra acestuia este creat un grup de volume LVM, în el sunt create mai multe volume: 2 mici de aceeași dimensiune, utilizate ca sistem de fișiere rădăcină (schimbate unul câte unul în timpul actualizărilor pentru posibilitatea de rollback rapid, ideea a fost preluată din distribuția Calculate Linux), o alta este pentru partiția de swap, restul spațiului liber este împărțit în volume mici, folosit ca sistem de fișiere rădăcină pentru containere cu drepturi depline, discuri pentru mașini virtuale, fișiere sisteme pentru conturi în /home (fiecare cont are propriul său sistem de fișiere), sisteme de fișiere pentru containerele de aplicații.
Notă importantă: volumele trebuie să fie complet autonome, de ex. nu ar trebui să depindă unul de celălalt sau de sistemul de fișiere rădăcină. În cazul mașinilor sau containerelor virtuale, acest punct este respectat automat. Dacă acestea sunt containere de aplicații sau directoare de acasă, ar trebui să vă gândiți să separați fișierele de configurare ale serverului web și ale altor servicii, astfel încât să eliminați pe cât posibil dependențele dintre volume. De exemplu, fiecare site rulează de la propriul utilizator, fișierele de configurare a site-ului sunt în directorul principal al utilizatorului, în setările serverului web, fișierele de configurare a site-ului nu sunt incluse prin /etc/nginx/conf.d/.conf și, de exemplu, /home//configs/nginx/*.conf
Dacă există mai multe discuri, puteți crea o matrice RAID software (și configura cache-ul acesteia pe un SSD, dacă este nevoie și oportunitate), pe deasupra căreia puteți construi LVM conform regulilor propuse mai sus. Tot în acest caz, puteți folosi ZFS sau BtrFS, dar ar trebui să vă gândiți de două ori la asta: ambele necesită o abordare mult mai serioasă a resurselor și, în plus, ZFS nu este inclus cu nucleul Linux.
Indiferent de schema utilizată, merită întotdeauna estimarea în avans a vitezei aproximative de scriere a modificărilor pe discuri și apoi calcularea cantității de spațiu liber care va fi rezervat pentru crearea de instantanee. De exemplu, dacă serverul nostru scrie date cu o viteză de 10 megaocteți pe secundă, iar dimensiunea întregii matrice de date este de 10 teraocteți - timpul de sincronizare poate ajunge la o zi (22 de ore - acesta este cât de mult va fi transferat un astfel de volum prin rețea 1 Gbps) - merită rezervat aproximativ 800 GB . În realitate, cifra va fi mai mică; o puteți împărți în siguranță la numărul de volume logice.
Dispozitiv server de stocare de rezervă
Principala diferență între un server pentru stocarea copiilor de rezervă este discurile sale mari, ieftine și relativ lente. Deoarece HDD-urile moderne au depășit deja bara de 10 TB într-un singur disc, este necesar să se utilizeze sisteme de fișiere sau RAID cu sume de control, deoarece în timpul reconstrucției matricei sau restabilirii sistemului de fișiere (câteva zile!) al doilea disc poate eșua din cauza la sarcina crescuta. Pe discurile cu o capacitate de până la 1TB, acest lucru nu era atât de sensibil. Pentru simplitatea descrierii, presupun că spațiul pe disc este împărțit în două părți de dimensiuni aproximativ egale (din nou, de exemplu, folosind LVM):
- volume corespunzătoare serverelor utilizate pentru stocarea datelor utilizatorului (ultima copie de rezervă efectuată va fi implementată pe acestea pentru verificare);
- volume utilizate ca depozite BorgBackup (datele pentru copii de rezervă vor merge direct aici).
Principiul de funcționare este că sunt create volume separate pentru fiecare server pentru depozitele BorgBackup, unde vor merge datele de la serverele de luptă. Arhivele funcționează în modul de doar anexare, ceea ce elimină posibilitatea ștergerii intenționate a datelor și datorită deduplicării și curățării periodice a depozitelor din backup-urile vechi (răman copii anuale, lunar pentru ultimul an, săptămânal pentru ultima lună, zilnic pentru saptamana trecuta, eventual in cazuri speciale - orar pentru ultima zi: total 24 + 7 + 4 + 12 + anual - aproximativ 50 de exemplare pentru fiecare server).
Arhivele BorgBackup nu activează modul numai pentru adăugare; în schimb, un ForcedCommand în .ssh/authorized_keys este folosit cam așa:
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.......Calea specificată conține un script wrapper deasupra lui borg, care, pe lângă lansarea binarului cu parametri, începe suplimentar procesul de restaurare a copiei de rezervă după ce datele sunt eliminate. Pentru a face acest lucru, scriptul wrapper creează un fișier de etichetă lângă depozitul corespunzător. Ultima copie de rezervă realizată este restaurată automat la volumul logic corespunzător după finalizarea procesului de completare a datelor.
Acest design vă permite să curățați periodic backup-urile inutile și, de asemenea, împiedică serverele de luptă să ștergă orice de pe serverul de stocare de rezervă.
Procesul de backup
Inițiatorul backup-ului este serverul dedicat sau VPS-ul însuși, deoarece această schemă oferă mai mult control asupra procesului de backup din partea acestui server. Mai întâi, este luată un instantaneu al stării sistemului de fișiere rădăcină activ, care este montat și încărcat folosind BorgBackup pe serverul de stocare de rezervă. După finalizarea captării datelor, instantaneul este demontat și șters.
Dacă există o bază de date mică (până la 1 GB pentru fiecare site), se face un dump al bazei de date, care este salvat în volumul logic corespunzător, unde se află restul datelor pentru același site, dar astfel încât dump-ul să fie nu este accesibil prin serverul web. Dacă bazele de date sunt mari, ar trebui să configurați eliminarea „fierbinte” a datelor, de exemplu, folosind xtrabackup pentru MySQL sau să lucrați cu WAL cu archive_command în PostgreSQL. În acest caz, baza de date va fi restaurată separat de datele site-ului.
Dacă se folosesc containere sau mașini virtuale, ar trebui să configurați qemu-guest-agent, CRIU sau alte tehnologii necesare. În alte cazuri, cel mai adesea nu sunt necesare setări suplimentare - pur și simplu creăm instantanee ale volumelor logice, care sunt apoi procesate în același mod ca un instantaneu al stării sistemului de fișiere rădăcină. După preluarea datelor, fotografiile sunt șterse.
Se efectuează lucrări suplimentare pe serverul de stocare de rezervă:
- se verifică ultima copie de rezervă realizată în fiecare depozit,
- se verifică prezența unui fișier de marcare, indicând că procesul de colectare a datelor este finalizat,
- datele sunt extinse la volumul local corespunzător,
- fișierul de etichetă este șters
Procesul de recuperare a serverului
Dacă serverul principal moare, atunci este lansat un server dedicat similar, care pornește de la o imagine standard. Cel mai probabil, descărcarea va avea loc prin rețea, dar tehnicianul centrului de date care instalează serverul poate copia imediat această imagine standard pe unul dintre discuri. Descărcarea are loc în RAM, după care începe procesul de recuperare:
- se face o cerere de atașare a unui dispozitiv bloc prin iscsinbd sau alt protocol similar la un volum logic care conține sistemul de fișiere rădăcină al serverului decedat; Deoarece sistemul de fișiere rădăcină trebuie să fie mic, acest pas ar trebui finalizat în câteva minute. De asemenea, bootloader-ul este restaurat;
- structura volumelor logice locale este recreată, volumele logice sunt atașate de la serverul de rezervă folosind modulul kernel dm_clone: începe recuperarea datelor, iar modificările sunt scrise imediat pe discurile locale
- se lansează un container cu toate discurile fizice disponibile - funcționalitatea serverului este complet restaurată, dar cu performanțe reduse;
- după ce sincronizarea datelor este finalizată, volumele logice de la serverul de rezervă sunt deconectate, containerul este oprit și serverul este repornit;
După o repornire, serverul va avea toate datele care erau acolo la momentul creării copiei de rezervă și va include, de asemenea, toate modificările care au fost făcute în timpul procesului de restaurare.
Alte articole din serie
Backup Partea 7: Concluzii
Vă invit să discutați varianta propusă în comentarii, vă mulțumesc pentru atenție!
Sursa: www.habr.com