De ce este important să facem copie de rezervă? Deși echipamentele sunt foarte fiabile, există și „cloud-uri” care sunt mai fiabile decât serverele fizice: dacă sunt configurate corect, un server „cloud” poate supraviețui cu ușurință unei defecțiuni a infrastructurii unui server fizic, iar din perspectiva utilizatorilor, va exista o mică, aproape imperceptibilă, creștere a timpului de răspuns. În plus, duplicarea informațiilor necesită adesea plata pentru „timpul de procesor suplimentar”, sarcina pe disc și traficul de rețea.
Programul ideal funcționează rapid, nu pierde memorie RAM, nu are bug-uri și nu există.
—Necunoscut
Deoarece programele sunt încă scrise de dezvoltatori, iar procesul de testare adesea lipseste, în plus livrarea programelor se face foarte rar conform „best practices” (care sunt ele însele tot programe și, prin urmare, imperfecte), administratorii de sistem trebuie adesea să rezolve sarcini care sună succint, dar sunt încărcate: „restaurați, ca înainte”, „aduceți baza la funcționare normală”, „funcționează lent — revenim”, precum și preferata mea „nu știu ce, dar repari”.
Pe lângă erorile logice care apar din cauza muncii neglijente a dezvoltatorilor, sau a circumstanțelor, precum și a cunoștințelor incomplete sau a neînțelegerii detaliilor fine ale construirii programelor — inclusiv a legăturilor și sistemelor, inclusiv sistemele de operare, driverele și firmware-ul — mai există și alte tipuri de erori. De exemplu, majoritatea dezvoltatorilor se bazează pe runtime și uită complet de legile fizicii, pe care nu le pot ocoli prin intermediul programelor. Aceasta include fiabilitatea infinită a subsistemului de stocare a discului și a oricărui subsistem de stocare a datelor (inclusiv memorie RAM și cache-ul procesorului!), timpul de procesare zero pe procesor, lipsa erorilor la transmiterea datelor în rețea și la procesare pe procesor și întârzierile din rețea, care sunt egale cu 0. Nu trebuie să neglijăm nici celebra limită de timp, căci dacă nu o respectăm, vor apărea probleme mai grave decât complexitățile funcționării rețelei și discului.
Cum să gestionăm problemele care apar brusc și amenință datele valoroase? Nu putem înlocui dezvoltatorii umani, și nu există nicio garanție că vom putea face acest lucru în curând. Pe de altă parte, până acum doar câteva proiecte au demonstrat pe deplin că programul va funcționa conform planului, și nu este deloc garantat că putem aplica acele dovezi la alte proiecte similare. În plus, astfel de dovezi consumă mult timp și necesită abilități speciale, ceea ce reduce practic la minimum posibilitatea de aplicare, având în vedere termenele limită. De asemenea, încă nu știm să oferim o tehnologie de stocare, procesare și transmitere a informațiilor care să fie extrem de rapidă, ieftină și infinit de fiabilă. Astfel de tehnologii, dacă există, sunt mai degrabă concepte, sau — cel mai frecvent — doar în cărți și filme de science fiction.
Artizanii buni copiază, artizanii mari fură.
—Pablo Picasso.
Cele mai de succes soluții și cele mai surprinzător de simple lucruri apar, de obicei, acolo unde se întâlnesc concepte, tehnologii, cunoștințe și domenii de știință care sunt absolut incompatibile din punct de vedere al aparenței.
De exemplu, păsările și avioanele au aripi, cu toate că, în ciuda asemănării funcționale — principiul de funcționare coincide în anumite condiții și problemele tehnice sunt rezolvate similar: oasele goale, utilizarea de materiale ușoare și durabile etc., — rezultatele sunt complet diferite, deși foarte asemănătoare. Cele mai bune exemple pe care le observăm în tehnica noastră sunt, de asemenea, în mare parte împrumutate din natură: compartimentele etanșe ale navelor și submarinelor — o analogie directă cu viermii în inel; construirea de matrice RAID și verificarea integrității datelor — duplicarea lanțului ADN; precum și organele pereche, independența funcționării diferitelor organe de sistemul nervos central (automatul funcționării inimii) și reflexele — sisteme autonome în rețea. Desigur, a lua și a aplica soluții existente „literal” este plin de probleme, dar cine știe, poate că nu există alte soluții.
Dacă aș fi știut unde voi cădea — aș fi pregătit niște paie!
—Zicătoare populară belarusă
Așadar, copiile de rezervă sunt esențiale pentru cei care doresc:
- Să aibă posibilitatea de a-și restabili funcționarea sistemelor cu timpi de nefuncționare minimi, sau chiar deloc.
- Acționați cu încredere, pentru că, în cazul unei erori, există întotdeauna posibilitatea de a reveni asupra acesteia.
- Minimizați consecințele deteriorării intenționate a datelor.
Aici — un pic de teorie.
Orice clasificare este arbitrară. Natura nu clasifică. Noi clasificăm pentru că este mai convenabil pentru noi. Clasificăm pe baza datelor pe care le luăm, de asemenea, în mod arbitrar.
—Jean Bruhler
Indiferent de metoda fizică de stocare, stocarea logică a datelor poate fi împărțită în două moduri de acces la aceste date: bloc și fișier. Această împărțire este destul de vagă în ultima vreme, deoarece nu există stocări logice pur bloc sau pur fișier. Totuși, pentru simplificare, vom considera că există.
Stocarea de date pe blocuri presupune existența unui dispozitiv fizic în care datele sunt scrise în porții fixe, blocuri. Accesul la blocuri se face pe baza unei anumite adrese, fiecărui bloc corespunzându-i o adresă specifică în cadrul dispozitivului.
Backup-ul este de obicei realizat prin copierea blocurilor de date. Pentru a asigura integritatea datelor în momentul copiei, scrierea de noi blocuri și modificarea celor existente sunt suspendate. Dacă luăm o analogie din lumea obișnuită, cea mai apropiată este un dulap cu celule numerotate identic.
Stocarea de date pe fișiere, prin principiul dispozitivului logic, este aproape de cea pe blocuri și adesea este organizată deasupra. Diferențele importante constau în existența unei ierarhii de stocare și denumiri ușor de înțeles. Se evidențiază o abstracție sub formă de fișier — o zonă denumită de date, precum și un director — un fișier special în care sunt stocate descrierile și accesările altor fișiere. Fișierele pot fi însoțite de metadate suplimentare: data creării, semnele de acces etc. Backup-urile se fac de obicei astfel: se caută fișierele modificate, apoi se copiază în alt stocaj de fișiere de structură similară. Integritatea datelor este de obicei realizată prin absența fișierelor în care se scrie. Metadatele fișierelor sunt rezervate în mod similar. Cea mai apropiată analogie este o bibliotecă care are secțiuni cu diferite cărți și, de asemenea, un catalog cu denumiri ușor de înțeles ale cărților.
Recent discussions often describe another variant from which, in principle, data file storage began, sharing the same archaic features: object storage.
It differs from file storage in that it has no more than one level of nesting (a flat schema), and while the file names are human-readable, they are more suited for machine processing. In backup solutions, object storage is often handled similarly to file systems, although there are occasionally other approaches.
— There are two types of system administrators: those who do not make backups and those who ALREADY do.
— Actually, there are three types: there are also those who verify that backups are restorable.—Necunoscut
It is also important to understand that the backup process itself is carried out by software, thus inheriting all the same drawbacks as any other program. To mitigate (not eliminate!) dependency on human factors, as well as peculiarities that may not individually have a significant impact but can collectively have a noticeable effect, the so-called 3-2-1 rule is applied. There are many interpretations of it, but I prefer the following: you need to store 3 sets of the same data, 2 sets in different formats, and 1 set in a geographically remote location.
By storage format, one should understand the following:
- If there is a dependency on the physical storage method, change the physical method.
- If there is a dependency on the logical storage method, change the logical method.
To achieve the maximum effect of the 3-2-1 rule, it is recommended to change the storage format using both methods.
From the perspective of a backup's readiness for its direct purpose—restoration of functionality—there are two types of backups: 'hot' and 'cold.' The difference is only one: hot backups are immediately ready for use, whereas cold backups require additional actions for restoration, such as decryption, extraction from the archive, etc.
Nu trebuie să confundăm copiile calde și reci cu copiile online și offline, care implică o izolare fizică a datelor și, în esență, reprezintă o altă categorie de clasificare a metodei de backup. Astfel, o copie offline — care nu este conectată direct la sistemul din care trebuie să fie restabilită — poate fi fie caldă, fie rece (în ceea ce privește pregătirea pentru restaurare). O copie online poate fi accesibilă direct acolo unde trebuie restaurată și, cel mai adesea, este caldă, dar pot exista și copie reci.
În plus, nu trebuie să uităm că procesul de creare a backup-urilor de obicei nu se încheie după crearea unei singure copii, iar numărul de copii poate fi destul de mare. Prin urmare, trebuie să facem distincția între backup-urile complete, adică cele care pot fi restaurate independent de alte copii de backup, și copiile diferențiale (incrementale, diferențiale, decremetale etc.) — cele care nu pot fi restaurate singure și necesită restaurarea prealabilă a uneia sau mai multor alte copii de backup.
Copiile diferențiale incremental sunt o încercare de a reduce dimensiunea spațiului de stocare pentru backup-uri. Astfel, în copia de backup sunt scrise doar datele modificate din ultima copie de backup.
Copiile diferențiale decremetale sunt create cu aceeași scop, dar printr-o metodă puțin diferită: se face o copie de backup completă, dar se păstrează de fapt doar diferența între copia proaspătă și cea anterioară.
Separat, merită analizat procesul de backup deasupra unui stocaj care suportă absența stocării de duplicat. Astfel, dacă scriem copii complete de backup deasupra lui, de fapt va fi înregistrată doar diferența între copiile de backup, totuși procesul de restaurare a copiilor de backup va avea loc în mod similar cu restaurarea dintr-o copie completă și va fi complet transparent.
Quis custodiet ipsos custodes?
(Cine va face pază paznicilor? — lat.)
Este foarte neplăcut când nu există backup-uri, dar este mult mai rău dacă backup-ul pare că a fost efectuat, dar la restaurare se constată că nu poate fi restaurat, deoarece:
- Integritatea datelor originale a fost compromisă.
- Stocajul cu backup-uri este deteriorat.
- Recuperarea funcționează destul de lent, nu se pot folosi datele care sunt parțial restaurate.
Un proces de backup bine construit trebuie să ia în considerare astfel de observații, în special primele două.
Integritatea datelor originale poate fi garantată în mai multe moduri. Cele mai utilizate sunt următoarele: a) crearea de copii ale sistemului de fișiere la nivel de bloc, b) "înghețarea" stării sistemului de fișiere, c) un dispozitiv bloc special pentru stocarea versiunilor, d) scrierea secvențială a fișierelor sau blocurilor. De asemenea, se aplică sume de control pentru a asigura verificarea datelor la restaurare.
Deteriorarea stocării poate fi, de asemenea, detectată cu ajutorul sumelor de control. O metodă suplimentară este utilizarea dispozitivelor specializate sau a sistemelor de fișiere în care datele deja scrise nu pot fi modificate, dar se pot adăuga noi.
Pentru a accelera recuperarea, se aplică restaurarea datelor cu mai multe procese de recuperare — cu condiția să nu existe un "gât de sticle" sub forma unei rețele lente sau a unui sistem de discuri nu foarte rapid. Pentru a ocoli situația cu date parțial restaurate, procesul de backup poate fi împărțit în subtask-uri relativ mici, fiecare dintre ele executându-se separat. Astfel, se oferă posibilitatea de a restaura funcționalitatea treptat, previzionând timpul de recuperare. Această problemă se află cel mai adesea în planul organizațional (SLA), astfel încât nu ne vom opri asupra acestui aspect detaliat.
Cine știe să folosească condimentele nu este acela care le adaugă în fiecare mâncare, ci acela care nu va adăuga niciodată nimic în plus.
—V. Siniavski
Practicile din partea software-ului aplicat de administratorii de sistem pot varia, dar principiile generale rămân totuși aceleași, în special:
- Se recomandă cu insistență utilizarea soluțiilor gata făcute.
- Programele trebuie să funcționeze predictibil, adică nu trebuie să existe caracteristici documentate sau puncte slabe.
- Configurația fiecărei programe trebuie să fie suficient de simplă, astfel încât să nu fie necesară citirea manualului sau a fișei de ajutor de fiecare dată.
- Soluția ar trebui să fie universală, deoarece serverele pot diferi semnificativ în funcție de specificațiile hardware.
Pentru crearea copiilor de siguranță de pe dispozitivele bloc, există următoarele programe frecvent utilizate:
- dd, cunoscută veteranilor în administrarea sistemelor, iar aici intră și programe similare (de exemplu, dd_rescue).
- Programe (utilitare) încorporate în unele sisteme de fișiere care creează o copie (dump) a sistemului de fișiere.
- Utilitare versatile; de exemplu, partclone.
- Soluții proprii, adesea personalizate; de exemplu, NortonGhost și versiunile mai recente.
Pentru sistemele de fișiere, problema creării copiilor de siguranță este parțial rezolvată prin metode aplicabile dispozitivelor bloc, dar se poate rezolva și mai eficient, folosind, de exemplu:
- Rsync, o programă și protocol universal pentru sincronizarea stării sistemelor de fișiere.
- Instrumente încorporate pentru arhivare (ZFS).
- Instrumente de arhivare din terță parte; cel mai popular reprezentant este tar. Există și altele, cum ar fi dar - o alternativă la tar orientată spre sistemele moderne.
Este important să menționăm instrumentele software pentru asigurarea consistenței datelor în timpul creării copiilor de siguranță. Cele mai frecvente opțiuni utilizate sunt:
- Montarea sistemului de fișiere în modul doar citire (ReadOnly) sau înghețarea sistemului de fișiere (freeze) - metoda este aplicabilă într-o măsură limitată.
- Crearea copiilor stării sistemului de fișiere sau a dispozitivului bloc (LVM, ZFS).
- Utilizarea de instrumente din terță parte pentru organizarea copiilor, chiar și în cazurile în care punctele anterioare nu pot fi asigurate din diverse motive (programe de tip hotcopy).
- Tehnica de copiere la modificare (CopyOnWrite), însă de obicei este legată de sistemul de fișiere utilizat (BTRFS, ZFS).
Prin urmare, pentru un server mic, este necesar să se asigure un sistem de backup care să îndeplinească următoarele cerințe:
- Simplu de utilizat — nu necesită acțiuni speciale suplimentare în timpul funcționării, acțiuni minime pentru crearea și restaurarea copiilor.
- Universal — funcționează atât pe servere mari, cât și pe cele mici; acest lucru este important pe măsură ce numărul servere sau scalarea crește.
- Se instalează printr-un manager de pachete, sau în una-două comenzi de tip „descărcați și dezarhivați”.
- Stabil — se folosește un format standard sau bine stabilit de stocare.
- Rapid în funcționare.
Candidatul care răspunde oarecum cerințelor:
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
Pentru stația de testare se va folosi o mașină virtuală (bazată pe XenServer) cu următoarele caracteristici:
- 4 nuclee de 2.5 GHz,
- 16 GB de RAM,
- 50 GB de stocare hibridă (SAS cu caching SSD de 20% din dimensiunea discului virtual) sub formă de disc virtual separat fără partiționare,
- Canal de 200 Mbps în internet.
Ca server de primire a copiilor de rezervă se va folosi o mașină practic similară, dar cu un hard disk de 500 GB.
Sistemul de operare — Centos 7 x64: partiționare standard, o partiție suplimentară va fi folosită ca sursă de date.
Ca date de origine vom lua un site pe Wordpress, cu fișiere media de 40 GB și o bază de date pe MySQL. Deoarece servere virtuale variază semnificativ ca specificații, precum și pentru a asigura o mai bună reproducibilitate, aici sunt
rezultatele testării serverului cu ajutorul sysbench.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (folosind LuaJIT 2.1.0-beta3 integrat)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatoare din timpul curent
Limită pentru numere prime: 20000
Inițializarea firelor de lucru…
Firele au fost pornite!
Viteza CPU:
evenimente pe secundă: 836.69
Debitul:
evenimente/s (eps): 836.6908
timpul scurs: 30.0039s
numărul total de evenimente: 25104
Latenta (ms):
min: 2.38
medie: 4.78
max: 22.39
percentila 95: 10.46
suma: 119923.64
Corectitudinea firelor:
evenimente (medie/deviație standard): 6276.0000/13.91
timpul de execuție (medie/deviație standard): 29.9809/0.01
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=read memory run
sysbench 1.1.0-18a9f86 (folosind LuaJIT 2.1.0-beta3 integrat)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatoare din timpul curent
Se rulează testul de viteză a memoriei cu următoarele opțiuni:
dimensiune bloc: 1KiB
dimensiune totală: 102400MiB
operațiune: citire
sferă: global
Inițializarea firelor de lucru…
Firele au fost pornite!
Total operațiuni: 50900446 (1696677.10 pe secundă)
49707.47 MiB transferate (1656.91 MiB/sec)
Debitul:
evenimente/s (eps): 1696677.1017
timpul scurs: 30.0001s
numărul total de evenimente: 50900446
Latenta (ms):
min: 0.00
medie: 0.00
max: 24.01
percentila 95: 0.00
suma: 39106.74
Corectitudinea firelor:
evenimente (medie/deviație standard): 12725111.5000/137775.15
timp de execuție (medie/deviație standard): 9.7767/0.10
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (folosind LuaJIT 2.1.0-beta3 integrat)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatoare din timpul curent
Se rulează testul de viteză a memoriei cu următoarele opțiuni:
dimensiune bloc: 1KiB
dimensiune totală: 102400MiB
operațiune: scriere
sferă: global
Inițializarea firelor de lucru…
Firele au fost pornite!
Total operațiuni: 35910413 (1197008.62 pe secundă)
35068.76 MiB transferate (1168.95 MiB/sec)
Debitul:
evenimente/s (eps): 1197008.6179
timpul scurs: 30.0001s
numărul total de evenimente: 35910413
Latenta (ms):
min: 0.00
medie: 0.00
max: 16.90
percentila 95: 0.00
suma: 43604.83
Corectitudinea firelor:
evenimente (medie/deviație standard): 8977603.2500/233905.84
timp de execuție (medie/deviație standard): 10.9012/0.41
sysbench —threads=4 —file-test-mode=rndrw —time=60 —file-block-size=4K —file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (folosind LuaJIT 2.1.0-beta3 integrat)
Se rulează testul cu următoarele opțiuni:
Numărul de fire: 4
Inițializarea generatorului de numere aleatoare din timpul curent
Flagi suplimentare pentru deschiderea fișierelor: (none)
128 fișiere, câte 8MiB fiecare
1GiB dimensiune totală a fișierelor
Dimensiune bloc 4KiB
Numărul de cereri IO: 0
Rata de citire/scriere pentru testul IO aleatoriu combinat: 1.50
FSYNC periodic activat, apelând fsync() la fiecare 100 de cereri.
Apelând fsync() la sfârșitul testului, activat.
Folosind modul I/O sincron
Executând un test r/w aleator
Inițializarea firelor de lucru…
Firele au fost pornite!
Debitul:
citire: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
scrie: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latenta (ms):
min: 0.00
medie: 0.27
max: 18.01
percentilul 95: 1.08
sumă: 238469.45
Această notă introduce un ciclu amplu
de articole despre backup
- Backup, partea 1: De ce este necesar backup-ul, revizuirea metodelor, tehnologiilor.
- Backup, partea 2: Revizuirea și testarea instrumentelor de backup bazate pe rsync.
- Backup, partea 3: Prezentare generală și testare duplicity, duplicaty, deja dup
- Backup, partea 4: Revizuirea și testarea zbackup, restic, borgbackup
- Backup, partea 5: Testarea bacula și veeam backup pentru linux.
- Backup, partea 6: Comparația uneltelor de backup
- Backup, partea 7: Concluzii
Sursa: habr.com
