De ce trebuie să faceți copii de rezervă? La urma urmei, echipamentul este foarte, foarte fiabil și, în plus, există „nori” care sunt mai fiabile decât serverele fizice: cu o configurație adecvată, un server „cloud” poate supraviețui cu ușurință eșecului unui server fizic de infrastructură și de la din punctul de vedere al utilizatorilor de servicii, va exista un mic salt abia vizibil în serviciul de timp. În plus, duplicarea informațiilor necesită adesea plata pentru timp „extra” de procesor, încărcare pe disc și trafic de rețea.
Un program ideal rulează rapid, nu pierde memorie, nu are găuri și nu există.
-Necunoscut
Deoarece programele sunt încă scrise de dezvoltatori de proteine și adesea nu există un proces de testare, plus că programele sunt rareori livrate folosind „cele mai bune practici” (care sunt, de asemenea, programe și, prin urmare, imperfecte), administratorii de sistem trebuie să rezolve cel mai adesea probleme care sună pe scurt, dar succint: „întoarceți-vă la cum a fost”, „aduceți baza la funcționarea normală”, „funcționează încet - întoarceți-vă”, și, de asemenea, preferatul meu „nu știu ce, dar reparați-o”.
Pe lângă erorile logice care apar ca urmare a muncii neglijente a dezvoltatorilor sau a unei combinații de circumstanțe, precum și a cunoștințelor incomplete sau a neînțelegerii micilor caracteristici ale programelor de construcție - inclusiv cele de conectare și de sistem, inclusiv sisteme de operare, drivere și firmware - mai sunt si alte erori. De exemplu, majoritatea dezvoltatorilor se bazează pe runtime, uitând complet de legile fizice, care sunt încă imposibil de ocolit folosind programe. Aceasta include fiabilitatea infinită a subsistemului de disc și, în general, a oricărui subsistem de stocare a datelor (inclusiv RAM și memoria cache a procesorului!), și timp de procesare zero pe procesor și absența erorilor în timpul transmiterii prin rețea și în timpul procesării pe procesor și latența rețelei, care este egală cu 0. Nu ar trebui să neglijați termenul limită notoriu, deoarece dacă nu îl respectați la timp, vor apărea probleme mai grave decât nuanțele funcționării rețelei și a discului.
Ce să faci cu problemele care se ridică în plină forță și atârnă peste date valoroase? Nu există nimic care să înlocuiască dezvoltatorii vii și nu este un fapt că va fi posibil în viitorul apropiat. Pe de altă parte, doar câteva proiecte au reușit să demonstreze pe deplin că programul va funcționa conform intenției și nu va fi neapărat posibil să se preia și să se aplice dovezile altor proiecte similare. De asemenea, astfel de dovezi necesită mult timp și necesită abilități și cunoștințe speciale, iar acest lucru minimizează practic posibilitatea utilizării lor ținând cont de termenele limită. În plus, nu știm încă să folosim tehnologie ultra-rapidă, ieftină și infinit de fiabilă pentru stocarea, procesarea și transmiterea informațiilor. Astfel de tehnologii, dacă există, sunt sub formă de concepte sau – cel mai adesea – doar în cărți și filme științifico-fantastice.
Artiștii buni copiază, artiștii mari fură.
-Pablo Picasso.
Cele mai de succes soluții și lucruri surprinzător de simple se întâmplă de obicei acolo unde se întâlnesc concepte, tehnologii, cunoștințe și domenii ale științei care sunt absolut incompatibile la prima vedere.
De exemplu, păsările și avioanele au aripi, dar în ciuda similitudinii funcționale - principiul de funcționare în unele moduri este același, iar problemele tehnice sunt rezolvate într-un mod similar: oase goale, utilizarea materialelor puternice și ușoare etc. - rezultatele sunt complet diferite, deși foarte asemănătoare. Cele mai bune exemple pe care le vedem în tehnologia noastră sunt, de asemenea, în mare măsură împrumutate din natură: compartimentele presurizate ale navelor și submarinelor sunt o analogie directă cu anelidele; construirea de matrice raid și verificarea integrității datelor - duplicarea lanțului ADN; precum și organele pereche, independența activității diferitelor organe față de sistemul nervos central (automatizarea inimii) și reflexe - sisteme autonome pe Internet. Desigur, luarea și aplicarea soluțiilor gata făcute „front-on” este plină de probleme, dar cine știe, poate că nu există alte soluții.
Dacă aș fi știut unde vei cădea, aș fi întins paie!
— proverb popular din Belarus
Aceasta înseamnă că copiile de rezervă sunt vitale pentru cei care doresc:
- Fiți capabil să restabiliți funcționarea sistemelor dvs. cu un timp de nefuncționare minim, sau chiar fără acesta
- Acționați cu îndrăzneală, pentru că în caz de eroare există întotdeauna posibilitatea unei rollback
- Reduceți la minimum consecințele coruperii intenționate a datelor
Iată o mică teorie
Orice clasificare este arbitrară. Natura nu clasifică. Clasificăm pentru că ne este mai convenabil. Și clasificăm în funcție de date pe care și le luăm în mod arbitrar.
— Jean Bruler
Indiferent de metoda de stocare fizică, stocarea logică a datelor poate fi împărțită în două moduri de accesare a acestor date: bloc și fișier. Această diviziune a fost recent foarte neclară, deoarece stocarea logică pur bloc, precum și pur fișier, nu există. Cu toate acestea, pentru simplitate, vom presupune că ele există.
Stocarea datelor bloc implică faptul că există un dispozitiv fizic în care datele sunt scrise în anumite porțiuni fixe, blocuri. Blocurile sunt accesate la o anumită adresă, fiecare bloc are propria sa adresă în cadrul dispozitivului.
O copie de rezervă se face de obicei prin copierea blocurilor de date. Pentru a asigura integritatea datelor, înregistrarea blocurilor noi, precum și modificările celor existente, sunt suspendate în momentul copierii. Dacă luăm o analogie din lumea obișnuită, cel mai apropiat lucru este un dulap cu celule numerotate identice.
Stocarea datelor de fișiere bazată pe principiul dispozitivului logic este aproape de stocarea blocată și este adesea organizată în partea de sus. Diferențele importante sunt prezența unei ierarhii de stocare și a numelor care pot fi citite de om. O abstractizare este alocată sub forma unui fișier - o zonă de date numită, precum și un director - un fișier special în care sunt stocate descrierile și accesul la alte fișiere. Fișierele pot fi furnizate cu metadate suplimentare: timpul de creare, steaguri de acces etc. Backup-urile se fac de obicei în acest fel: caută fișiere modificate, apoi le copiază într-un alt spațiu de stocare a fișierelor cu aceeași structură. Integritatea datelor este de obicei implementată prin absența fișierelor în care sunt scrise. Se face backup pentru metadatele fișierului în același mod. Cea mai apropiată analogie este o bibliotecă, care are secțiuni cu diferite cărți și are, de asemenea, un catalog cu nume ale cărților care pot fi citite de om.
Recent, este descrisă uneori o altă opțiune, de la care, în principiu, a început stocarea datelor fișierelor și care are aceleași caracteristici arhaice: stocarea datelor obiect.
Diferă de stocarea fișierelor prin faptul că nu are mai mult de o imbricare (schemă plată), iar numele fișierelor, deși pot fi citite de om, sunt totuși mai potrivite pentru procesarea de către mașini. Când se efectuează copii de siguranță, stocarea obiectelor este tratată cel mai adesea în mod similar cu stocarea fișierelor, dar ocazional există și alte opțiuni.
— Există două tipuri de administratori de sistem, cei care nu fac copii de rezervă și cei care DEJA o fac.
- De fapt, există trei tipuri: există și cei care verifică dacă backup-urile pot fi restaurate.-Necunoscut
De asemenea, merită să înțelegeți că procesul de backup al datelor în sine este efectuat de programe, deci are toate aceleași dezavantaje ca orice alt program. Pentru a elimina (nu a elimina!) dependența de factorul uman, precum și caracteristicile - care individual nu au un efect puternic, dar împreună pot da un efect vizibil - așa-numita regula 3-2-1. Există multe opțiuni pentru cum să o descifrez, dar îmi place mai mult următoarea interpretare: trebuie stocate 3 seturi din aceleași date, 2 seturi trebuie stocate în formate diferite și 1 set trebuie stocat într-o stocare la distanță geografică.
Formatul de stocare trebuie înțeles după cum urmează:
- Dacă există o dependență de metoda de stocare fizică, schimbăm metoda fizică.
- Dacă există o dependență de metoda de stocare logică, schimbăm metoda logică.
Pentru a obține efectul maxim al regulii 3-2-1, se recomandă schimbarea formatului de stocare în ambele moduri.
Din punctul de vedere al pregătirii unei copii de rezervă pentru scopul propus - restabilirea funcționalității - se face o distincție între copiile de rezervă „fierbinte” și „reci”. Cele calde se deosebesc de cele reci într-un singur lucru: sunt imediat gata de utilizare, în timp ce cele reci necesită niște pași suplimentari pentru recuperare: decriptare, extragere din arhivă etc.
Nu confundați copiile la cald și la rece cu copiile online și offline, care presupun izolarea fizică a datelor și, de fapt, sunt un alt semn al clasificării metodelor de backup. Deci, o copie offline - care nu este conectată direct la sistemul unde trebuie restaurată - poate fi fie caldă, fie rece (în ceea ce privește pregătirea pentru recuperare). O copie online poate fi disponibilă direct acolo unde trebuie restaurată și de cele mai multe ori este caldă, dar există și altele reci.
În plus, nu uitați că procesul de creare a copiilor de rezervă în sine nu se termină de obicei cu crearea unei copii de rezervă și poate exista un număr destul de mare de copii. Prin urmare, este necesar să se facă distincția între backup-urile complete, de exemplu. cele care pot fi restaurate independent de alte copii de siguranță, precum și copii diferențiale (incrementale, diferențiale, decrementale etc.) - cele care nu pot fi restaurate independent și necesită restaurarea prealabilă a uneia sau mai multor alte copii de siguranță.
Backup-urile incrementale diferențiale sunt o încercare de a economisi spațiu de stocare de rezervă. Astfel, doar datele modificate din copia de rezervă anterioară sunt scrise în copia de rezervă.
Cele decrementare diferențiale sunt create în același scop, dar într-un mod ușor diferit: se realizează o copie de rezervă completă, dar se stochează efectiv doar diferența dintre copia proaspătă și cea anterioară.
Separat, merită luat în considerare procesul de backup peste stocare, care acceptă absența stocării duplicatelor. Astfel, dacă scrieți copii de siguranță complete deasupra acestuia, se vor scrie efectiv doar diferențele dintre copii de siguranță, dar procesul de restaurare a copiilor de siguranță va fi similar cu restaurarea dintr-o copie completă și complet transparent.
Puneți în custodie ipsos?
(Cine îi va păzi pe paznicii înșiși? - lat.)
Este foarte neplăcut când nu există copii de rezervă, dar este mult mai rău dacă pare să fi fost făcută o copie de rezervă, dar la restaurare se dovedește că nu poate fi restaurată deoarece:
- Integritatea datelor sursă a fost compromisă.
- Spațiul de stocare de rezervă este deteriorat.
- Restaurarea funcționează foarte lent; nu puteți utiliza datele care au fost parțial recuperate.
Un proces de backup construit corect trebuie să țină cont de astfel de comentarii, în special de primele două.
Integritatea datelor sursă poate fi garantată în mai multe moduri. Cele mai frecvent utilizate sunt următoarele: a) crearea de instantanee ale sistemului de fișiere la nivel de bloc, b) „înghețarea” stării sistemului de fișiere, c) un dispozitiv bloc special cu stocare versiuni, d) înregistrarea secvențială a fișierelor sau blocuri. De asemenea, se aplică sume de verificare pentru a se asigura că datele sunt verificate în timpul recuperării.
Coruperea stocării poate fi detectată și folosind sumele de verificare. O metodă suplimentară este utilizarea dispozitivelor specializate sau a sistemelor de fișiere în care datele deja înregistrate nu pot fi modificate, dar pot fi adăugate altele noi.
Pentru a accelera recuperarea, recuperarea datelor este utilizată cu mai multe procese de recuperare - cu condiția să nu existe blocaj sub forma unei rețele lente sau a unui sistem de disc lent. Pentru a ocoli situația cu date parțial recuperate, puteți împărți procesul de backup în subsarcini relativ mici, fiecare dintre acestea fiind efectuată separat. Astfel, devine posibilă restabilirea consecventă a performanței în timp ce se prevede timpul de recuperare. Această problemă se află cel mai adesea în planul organizațional (SLA), așa că nu ne vom opri asupra acestui lucru în detaliu.
Un expert în condimente nu este cel care le adaugă la fiecare fel de mâncare, ci cel care nu adaugă niciodată nimic în plus.
-ÎN. Sinyavsky
Practicile referitoare la software-ul folosit de administratorii de sistem pot varia, dar principiile generale sunt tot, într-un fel sau altul, aceleași, în special:
- Este recomandat să folosiți soluții gata preparate.
- Programele ar trebui să funcționeze previzibil, de ex. Nu ar trebui să existe caracteristici nedocumentate sau blocaje.
- Configurarea fiecărui program ar trebui să fie atât de simplă încât nu trebuie să citiți manualul sau foaia de cheat de fiecare dată.
- Dacă este posibil, soluția ar trebui să fie universală, pentru că serverele pot varia foarte mult în ceea ce privește caracteristicile hardware.
Există următoarele programe comune pentru a face copii de rezervă de pe dispozitivele blocate:
- dd, familiar veteranilor din administrarea sistemului, aceasta include și programe similare (același dd_rescue, de exemplu).
- Utilități încorporate în unele sisteme de fișiere care creează un dump al sistemului de fișiere.
- Utilități omnivore; de exemplu partclone.
- Deciziile proprii, adesea proprietare; de exemplu, NortonGhost și mai târziu.
Pentru sistemele de fișiere, problema de backup este parțial rezolvată folosind metode aplicabile pentru dispozitivele bloc, dar problema poate fi rezolvată mai eficient folosind, de exemplu:
- Rsync, un program și un protocol de uz general pentru sincronizarea stării sistemelor de fișiere.
- Instrumente de arhivare încorporate (ZFS).
- Instrumente de arhivare de la terți; cel mai popular reprezentant este gudronul. Există și altele, de exemplu, dar - un înlocuitor al gudronului destinat sistemelor moderne.
Merită menționat separat despre instrumentele software pentru asigurarea coerenței datelor la crearea copiilor de rezervă. Opțiunile cele mai frecvent utilizate sunt:
- Montarea sistemului de fișiere în modul doar citire (ReadOnly) sau înghețarea sistemului de fișiere (înghețare) - metoda are aplicabilitate limitată.
- Crearea de instantanee ale stării sistemelor de fișiere sau a dispozitivelor bloc (LVM, ZFS).
- Utilizarea instrumentelor terțe pentru organizarea afișărilor, chiar și în cazurile în care punctele anterioare nu pot fi furnizate din anumite motive (programe precum hotcopy).
- Tehnica copy-on-change (CopyOnWrite), cu toate acestea, este cel mai adesea legată de sistemul de fișiere utilizat (BTRFS, ZFS).
Deci, pentru un server mic, trebuie să furnizați o schemă de rezervă care să îndeplinească următoarele cerințe:
- Ușor de utilizat - nu sunt necesari pași suplimentari speciali în timpul funcționării, pași minimi pentru crearea și restaurarea copiilor.
- Universal - funcționează atât pe servere mari, cât și pe cele mici; acest lucru este important atunci când creșteți numărul de servere sau scalați.
- Instalat de un manager de pachete sau în una sau două comenzi precum „descărcați și despachetați”.
- Stabil - se folosește un format de stocare standard sau de lungă durată.
- Rapid în muncă.
Solicitanți dintre cei care îndeplinesc mai mult sau mai puțin cerințele:
- rdiff-backup
- rsnapshot
- ragait
- duplicare
- duplicitate
- lasa dup
- da
- zbackup
- liniștit
- borgbackup
O mașină virtuală (bazată pe XenServer) cu următoarele caracteristici va fi utilizată ca banc de testare:
- 4 nuclee 2.5 GHz,
- 16 GB RAM,
- Stocare hibridă de 50 GB (sistem de stocare cu cache pe SSD 20% din dimensiunea discului virtual) sub forma unui disc virtual separat, fără partiționare,
- Canal de internet de 200 Mbps.
Aproape aceeași mașină va fi folosită ca server de rezervă de receptor, doar cu un hard disk de 500 GB.
Sistem de operare - Centos 7 x64: partiție standard, partiția suplimentară va fi folosită ca sursă de date.
Ca date inițiale, să luăm un site WordPress cu 40 GB de fișiere media și o bază de date mysql. Deoarece serverele virtuale variază foarte mult ca caracteristici și, de asemenea, pentru o mai bună reproductibilitate, iată
rezultatele testării serverului folosind sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (folosind pachetul LuaJIT 2.1.0-beta3)
Rularea testului cu următoarele opțiuni:
Număr de fire: 4
Inițializarea generatorului de numere aleatoare din ora curentă
Limita numerelor prime: 20000
Se inițializează firele de lucru…
Subiectele au început!
Viteza procesorului:
evenimente pe secundă: 836.69
Randament:
evenimente/e (eps): 836.6908
timp scurs: 30.0039s
numărul total de evenimente: 25104
Latență (ms):
min: 2.38
medie: 4.78
maxim: 22.39
Percentila 95: 10.46
suma: 119923.64
Corectitudinea firelor:
evenimente (avg/stddev): 6276.0000/13.91
timp de execuție (avg/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=citește rularea memoriei
sysbench 1.1.0-18a9f86 (folosind pachetul LuaJIT 2.1.0-beta3)
Rularea testului cu următoarele opțiuni:
Număr de fire: 4
Inițializarea generatorului de numere aleatoare din ora curentă
Rularea testului de viteză a memoriei cu următoarele opțiuni:
dimensiunea blocului: 1 KiB
dimensiune totală: 102400 MiB
operațiune: citiți
domeniul de aplicare: global
Se inițializează firele de lucru…
Subiectele au început!
Total operațiuni: 50900446 (1696677.10 pe secundă)
49707.47 MiB transferați (1656.91 MiB/sec)
Randament:
evenimente/e (eps): 1696677.1017
timp scurs: 30.0001s
numărul total de evenimente: 50900446
Latență (ms):
min: 0.00
medie: 0.00
maxim: 24.01
Percentila 95: 0.00
suma: 39106.74
Corectitudinea firelor:
evenimente (avg/stddev): 12725111.5000/137775.15
timp de execuție (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=scriere-execuție memorie
sysbench 1.1.0-18a9f86 (folosind pachetul LuaJIT 2.1.0-beta3)
Rularea testului cu următoarele opțiuni:
Număr de fire: 4
Inițializarea generatorului de numere aleatoare din ora curentă
Rularea testului de viteză a memoriei cu următoarele opțiuni:
dimensiunea blocului: 1 KiB
dimensiune totală: 102400 MiB
operatie: scrie
domeniul de aplicare: global
Se inițializează firele de lucru…
Subiectele au început!
Total operațiuni: 35910413 (1197008.62 pe secundă)
35068.76 MiB transferați (1168.95 MiB/sec)
Randament:
evenimente/e (eps): 1197008.6179
timp scurs: 30.0001s
numărul total de evenimente: 35910413
Latență (ms):
min: 0.00
medie: 0.00
maxim: 16.90
Percentila 95: 0.00
suma: 43604.83
Corectitudinea firelor:
evenimente (avg/stddev): 8977603.2500/233905.84
timp de execuție (avg/stddev): 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 pachetul LuaJIT 2.1.0-beta3)
Rularea testului cu următoarele opțiuni:
Număr de fire: 4
Inițializarea generatorului de numere aleatoare din ora curentă
Indicatori de deschidere a fișierelor suplimentare: (niciunul)
128 de fișiere, 8 MiB fiecare
Dimensiunea totală a fișierului de 1 GiB
Dimensiunea blocului 4 KiB
Număr de solicitări IO: 0
Raport de citire/scriere pentru testul IO aleator combinat: 1.50
FSYNC periodic activat, apelând fsync() la fiecare 100 de solicitări.
Apelarea fsync() la sfârșitul testului, activată.
Utilizarea modului I/O sincron
Efectuarea unui test aleator r/w
Se inițializează firele de lucru…
Subiectele au început!
Randament:
citiți: 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
Latență (ms):
min: 0.00
medie: 0.27
maxim: 18.01
Percentila 95: 1.08
suma: 238469.45
Această notă începe mare
serie de articole despre backup
- Backup, partea 1: De ce este nevoie de backup, revizuirea metodelor, tehnologiilor
- Backup, partea 2: Revizuirea și testarea instrumentelor de backup bazate pe rsync
- Backup Partea 3: Revizuire și testare duplicitate, duplicat, deja dup
- Backup Partea 4: Zbackup, restic, revizuire și testare borgbackup
- Backup, partea 5: Testarea bacula și veeam backup pentru Linux
- Backup Partea 6: Comparația instrumentelor de backup
- Backup Partea 7: Concluzii
Sursa: www.habr.com