Tier-ul de Capacitate (sau cum îi spunem noi intern — captir) a apărut încă din vremurile Veeam Backup and Replication 9.5 Update 4 sub numele de Archive Tier. Ideea din spatele acestuia este de a permite mutarea backup-urilor care au ieșit din așa-numitul fereastră de restaurare operațională, pe stocări obiectuale. Acest lucru a ajutat la eliberarea spațiului pe disc pentru utilizatorii care aveau limita de stocare. Această opțiune se numește Mod de Mutare.

Pentru a realiza această acțiune simplă (așa cum pare) erau suficiente două condiții: toate punctele din backup-ul mutat trebuie să fie în afara ferestrei de restaurare operațională menționate anterior, care este definită explicit în UI. Și a doua: lanțul trebuie să fie în așa-numitul ‚format sigilat’ (sealed backup chain sau Inactive Backup Chain). Aceasta înseamnă că, în timp, în acest lanț nu se produc modificări.

Dar în VBR v10, conceptul a fost completat cu noi funcționalități — a apărut Mod de Copiere, Mod Sigilat și o opțiune cu un nume greu de pronunțat — Imutabilitate.

Astăzi ne vom axa asupra acestor lucruri fascinante. Mai întâi vom discuta despre cum funcționa în VBR9.5u4, iar apoi despre schimbările din versiunea zece.

Și, vă rog să mă iertați, apărătorii limbii curate, dar prea mulți termeni sunt imposibil de tradus.
Așa că aici vor fi mulți anglicisme.
Și multe GIF-uri.
Și poze.

Fără niciun regret. Autorul articolului.

Cum a fost

Așadar, să începem cu analiza ferestrei de restaurare operațională și a backup-ului sigilat (sau cum sunt acestea numite în documentație Inactive Backup Chain). Fără înțelegerea lor, nu putem continua explicațiile.

După cum vedem în imagine, avem un anumit lanț de backup cu blocuri de date, care este situat în repositoriul Performance tier SOBR, la care este conectat Tier-ul de Capacitate. Fereastra noastră de backup operațional este de trei zile.

Prin urmare, backup-ul .vbk creat luni sigilează lanțul anterior, al cărui fereastră este stabilită pe trei zile. Așadar, putem începe să mutăm în Capacity Tier tot ce este mai vechi de aceste trei zile.

Dar ce înseamnă exact lanțul sigilat și ce putea fi trimis în Capacity Tier în update 4?

Pentru Forward Incremental, semnul sigilării lanțului este crearea unei noi backup-uri complete. Indiferent de modul în care este obținută această backup completă: sunt considerate atât backup-urile sintetice complete, cât și cele active.

În cazul Reverse, toate fișierele care nu se încadrează în fereastra operațională sunt incluse.

În cazul Forward increment cu rollbacks, toate rollback-urile și .vbk sunt păstrate, dacă există un alt .vbk pe extinderea de performanță.

Acum să analizăm varianta de lucru cu lanțurile de Backup Copy. Aici au fost luate în considerare doar cele incluse în retenția GFS. Pentru că tot ceea ce se află în lanțurile mai recente de backup copy poate fi modificat în diverse moduri.

Acum să aruncăm o privire sub capotă. Acolo are loc un proces numit dehidratare — lăsarea fișierelor de backup goale pe extindere și mutarea blocurilor din aceste fișiere în tirul de capacitate. Pentru a optimiza acest proces, se folosește așa-numitul index de dehidratare, care permite evitarea copierii blocurilor care au fost deja copiate în tirul de capacitate.

Să vedem cum arată acest lucru pe un exemplu: să presupunem că avem un .vbk care a ieșit din fereastra operațională și aparține unui lanț sigilat. Asta înseamnă că avem dreptul complet să-l mutăm în tirul de capacitate. În momentul mutării, se creează un fișier de metadate în tirul de capacitate și blocurile fișierului mutat. În fișierul de metadate, la nivel de referințe, este descris din ce blocuri este format fișierul nostru. În cazul din imagine, primul nostru fișier constă din blocurile a, b, c, iar în metadate sunt plasate referințele către aceste blocuri. Când avem un al doilea fișier .vbk, pregătit pentru mutare și format din blocurile a, b și d, analizând indexul de dehidratare, înțelegem că trebuie să mutăm doar blocul d. Fișierul său de metadate va conține referințe către cele două blocuri anterioare și unul nou.

Prin urmare, procesul de umplere inversă a acestor locașuri goale cu date se numește rehidratare. Aici se folosește deja propriul index de rehidratare, bazat pe cel mai vechi fișier .vbk de pe extinderea de performanță locală. Deci, dacă utilizatorul dorește să restituie un fișier din tirul de capacitate, mai întâi creăm indexul blocurilor celui mai vechi backup complet și mutăm din tirul de capacitate doar blocurile lipsă. În cazul prezentat în imagine, pentru a rehidrata FullBackup1.vbk conform indexului de rehidratare, ne lipsește doar blocul C, pe care îl luăm din tirul de capacitate. Dacă tirul de capacitate este un obiect de stocare în cloud, acest lucru permite economisirea unor sume considerabile de bani.

Aici poate părea că această tehnologie este similară cu cea utilizată în Acelerații WAN, dar aceasta este doar o impresie. În acceleratoare, deduplicarea este globală, în timp ce aici se folosește deduplicarea locală în cadrul fiecărui fișier, pe un anumit offset. Acest lucru se datorează diferenței de sarcini rezolvate: trebuie să copiem fișiere mari de backup complet și, conform cercetărilor noastre, chiar dacă între acestea trece o perioadă mare de timp, un astfel de algoritm de deduplicare oferă cele mai bune rezultate.

Dar mai multe indexuri lui Dumnezeu indexuri! Există și un index pentru recuperarea datelor! Când lansăm recuperarea unei mașini situate în capacitatea tir, vom citi doar blocurile unice de date, care nu se află în tirul de performanță.

Așa a devenit

Acesta a fost tot cu introducerea. Este destul de detaliată, dar, așa cum s-a spus mai sus, fără aceste detalii nu se poate explica cum funcționează noile funcții. Așadar, fără alte introduceri, trecem la prima.

Modul de copiere

Se bazează în mare parte pe tehnologiile existente, dar aduce o logică complet diferită de utilizare.

Scopul acestui mod este de a garanta că toate datele aflate pe extensia locală au o copie în capacitatea tir.

Dacă comparăm brutal modurile Move și Copy, va fi așa:

Se pot muta doar lanțuri sigilate. În cazul modului Copy, se transportă absolut tot, indiferent de ceea ce se întâmplă în jobul de backup.
Mutarea se activează atunci când fișierele ies din fereastra de operare a backupului, iar copierea se activează imediat ce apare fișierul de backup.
Monitorizarea noilor date pentru copiere se face constant, iar pentru mutare se activa odată la 4 ore.

În examinarea noului mod, propunem să trecem de la exemple simple la cele complexe.

În cel mai banal caz, avem pur și simplu fișiere noi cu incremente, și le copiem pur și simplu în tirul de capacitate. Indiferent de modul utilizat în jobul de backup, indiferent dacă aparține părții sigilate a lanțului sau nu, indiferent dacă fereastra noastră operațională a expirat. Pur și simplu le-am luat și le-am copiat.

Procesul din spate rămâne tot dehidrarea, așa cum a fost descris mai sus. În modul copia, de asemenea, se asigură că nu copiem blocuri care sunt deja în stocarea noastră. Singura diferență este că, în modul mutare, am înlocuit fișierele reale cu fișiere golite, iar aici nu le atingem și lăsăm totul așa cum este. În rest, este exact același index de dehidrare, care se străduiește să economisească banii și timpul dumneavoastră.

Se pune întrebarea — dacă ne uităm în UI, există opțiunea de a alege ambele opțiuni simultan. Cum va funcționa acest mod combinat?

Să analizăm.

Începutul este standard: se creează un fișier de backup și se copiază imediat. Se creează un increment și, de asemenea, se copiază. Acest lucru se întâmplă până în momentul în care înțelegem că fișierele au ieșit din fereastra noastră operațională și a apărut un lanț sigilat. În acest moment, efectuăm operația de dehidrare și înlocuim aceste fișiere cu altele goale. Bineînțeles, nu mai copiem nimic din nou pe capacitatea tir.

Toată această logică interesantă este responsabilă doar o bifă în interfață: Copy backups to object storage as soon as they are created.

Dar de ce avem acest mod Copy?

Este chiar mai bine să reformulăm întrebarea astfel — de la ce riscuri ne protejăm cu ajutorul său? Ce problemă ne ajută să rezolvăm?

Răspunsul este evident: desigur, este vorba despre recuperarea datelor. Dacă avem pe stocarea obiectelor o copie completă a datelor locale, atunci nu contează ce se întâmplă cu producția noastră, putem oricând să recuperăm datele din fișierele aflate în Amazonul nostru ipotetic.

Așa că haideți să discutăm despre posibilele scenarii, de la cel mai simplu la cel mai complex.

Cea mai simplă problemă care poate cădea asupra capului nostru este inadmisibilitatea unuia dintre fișierele din lanțul de backup.

O poveste și mai tristă — ne-a fost stricat unul dintre extensiile depozitului nostru SOBR.

Și devine și mai rău atunci când întregul depozit SOBR devine inaccesibil, dar funcționează capacitatea tir.
Și totul devine cu adevărat grav — atunci când serverul de backup moare și prima ta dorință este să încerci să ajungi la granița canadiană în zece minute.

Acum să analizăm fiecare situație în parte.

Când am pierdut un (chiar dacă mai multe) fișiere de backup, va fi suficient să lansăm procesul de re-scanare a repository-ului, iar fișierul pierdut va fi înlocuit cu un fișier gol. Iar prin procesul de rehidratare (despre care am vorbit la începutul articolului), utilizatorul va putea descărca datele din capacity tier în stocarea locală.

Acum situația devine mai complicată. Să presupunem că SOBR-ul nostru constă din două extenturi, funcționând în modul Performance, ceea ce înseamnă că fișierele noastre .vbk și .vib sunt distribuite pe acestea într-un mod destul de inegal. Și la un moment dat, unul dintre extenturi devine inaccesibil, iar utilizatorul trebuie să recupereze urgent mașina, o parte din datele căreia se află tocmai pe acest extent.

Utilizatorul inițiază wizard-ul de recuperare, selectează punctul la care dorește să recupereze, iar wizard-ul, pe parcursul procesului, își dă seama că nu are toate datele necesare pentru recuperare local și, prin urmare, trebuie să le descarce din capacity tier. În acest timp, blocurile care au rămas în stocarea locală nu vor fi descărcate din cloud. Slavă indexului de restaurare (da, a fost menționat și acesta la începutul articolului).

O variantă a acestui caz este că întreg repository-ul SOBR a devenit inaccesibil. În acest caz, nu avem nimic de copiat din stocările locale, iar toate blocurile sunt descărcate din cloud.

Și cea mai interesantă situație — serverul de backup a murit. Aici sunt două variante: administratorul e deștept și a realizat backup-uri ale configurației, sau administratorul este un răufăcător care nu a realizat niciun backup de configurație.

În primul caz, va fi suficient să implementeze undeva o instalare curată a VBR-ului și să-și restaureze baza din backup prin metode standard. La finalul acestui proces, totul va reveni la normal. Sau va fi restaurat conform unuia dintre scenariile de mai sus.

Dar dacă administratorul este inamicul său sau dacă copia de rezervă a configurației a avut parte de eșecuri legendare, chiar și aici nu-l vom lăsa pe mila sorții. Pentru acest caz, am introdus o nouă procedură numită Import Object Storage. Aceasta permite să sărim peste procesul de recreare manuală a repositoarelor SOBR și de atașare a capacității acestora cu un nou scan, adăugând pur și simplu storage-ul de obiecte în interfața vima și lansând procedura Import Storage Repository. Singurul lucru care poate sta în calea ta și a copiilor tale de rezervă este o solicitare de a introduce parola, în cazul în care copierea ta de rezervă a fost criptată.

Aici se finalizează discuția despre Modului Copy, iar acum trecem la

Mod închis

Conceptul de bază este că nu pot apărea copii de rezervă noi pe extensia selectată a repositoarelor SOBR. Până la v10, aveam doar Modul de întreținere, când era complet interzisă orice activitate cu repositoarele. Acesta era un mod sever de oprire a stocării din funcțiune, în care era disponibil doar butonul Evacuate, care muta temporar copiile de rezervă pe o altă extensie.

Modul închis reprezintă o variantă „moale”: interzicem crearea de copii de rezervă noi și eliminăm treptat copiile vechi conform retenției selectate, dar în acest proces nu pierdem capacitatea de a ne restaura din punctele de stocare existente. Este o caracteristică foarte utilă atunci când se apropie termenul de viață al echipamentului și trebuie să fie înlocuit, sau trebuie pur și simplu să eliberăm spațiu pentru ceva mai important, dar nu avem unde să transferăm totul deodată. Sau nu se poate șterge.

Prin urmare, principiul de funcționare este destul de simplu: trebuie să interzicem toate operațiile de scriere (apariția de date noi), lăsând operațiile de citire (restaurări) și ștergete (retenție).

Ambele moduri pot fi utilizate simultan, dar trebuie să țineți cont că Modul de întreținere are prioritate mai mare.

Ca exemplu, să luăm în considerare un SOBR compus din două extensii. Să presupunem că, în primele patru zile, copiile de rezervă au fost create în modul Forward Forever Incremental, iar apoi sigilăm extensia. Aceasta duce la inițierea creării unui nou activ full pe a doua extensie disponibilă. Dacă retenția noastră este de patru, atunci când întreaga chaină situată pe extensia sigilată depășește această limită, aceasta poate fi ștearsă fără probleme.

Există situații în care ștergerea are loc mai devreme. De exemplu, este cazul Forward incremental cu copii complete periodice. Dacă în primele două zile s-au creat copii complete, iar joi decidem să pecetluim depozitul, atunci vinerea, când se va crea o nouă copie completă, fișierul de luni va fi șters deoarece până la acest punct nu există dependențe. Și acest punct nu depinde de nimeni. După aceea, așteptăm să fie create patru puncte pe extinderea disponibilă și ștergem cele trei rămase, care nu pot fi șterse independent una de cealaltă.

Lucrurile stau mai simplu cu Reverse Incremental. Aici, cele mai vechi puncte nu depind de nimeni și pot fi șterse fără probleme. Așadar, de îndată ce se creează un nou .vbk pe o nouă extindere, vechile .vrb vor fi șterse treptat.

Apropo, de ce creăm de fiecare dată un nou .vbk: dacă nu l-am crea și am continua vechea serie de incrementaluri, vechiul .vbk s-ar bloca pe o perioadă nedefinită în orice mod, împiedicând ștergerea sa. Așadar, s-a decis că de îndată ce extinderea este pecetluită, creăm o copie completă pe o extindere liberă.

Lucrurile sunt mai complicate cu capacitatea tier.

Mai întâi, să luăm în considerare modul copy. Să presupunem că am avut patru zile în care s-au creat activ copii de rezervă, iar apoi capacitatea tier a fost pecetluită. Nu ștergem nimic, ci așteptăm calm perioada de retenție, după care ștergem datele din capacitatea tier.

Aproape același lucru se întâmplă în modul move — așteptăm perioada de retenție, ștergem vechile date din stocarea locală, ștergem ce se află în obiect storage.

Un exemplu interesant cu Forever forward incremental. Stabilim o retenție de trei puncte și începem cu luni să facem copii de rezervă, care se copiază corect în cloud. După pecetluirea stocării, copiile de rezervă continuă să fie create, menținând cele trei puncte, dar datele stocate în capacitatea tier rămân dependente și nu pot fi șterse. Așadar, așteptăm joi, când .vbk-ul nostru depășește perioada de retenție, și abia atunci ștergem cu liniște întreaga serie de date salvate.

Și o mică precizare: toate exemplele de aici sunt prezentate cu o singură mașină. Dacă aveți mai multe în backup, atunci perioada de retenție va diferi în funcție de faptul că a fost efectuat un Active Full sau nu.

Asta ar fi tot. Așadar, să trecem la cea mai hardcore funcție —

Imutabilitate

Ca și în punctele anterioare, primul lucru despre care vorbim este problema pe care o rezolvă această funcție. Atunci când exportăm undeva backup-urile noastre pentru stocare, apare o dorință acută de a garanta păstrarea acestora, adică de a interzice fizic ștergerea și orice modificare pe durata retenției stabilite. Inclusiv de către administratori, inclusiv sub conturile lor de root. Acest lucru protejează backup-urile de deteriorarea accidentală sau intenționată. Cei care lucrează cu AWS ar putea întâlni o astfel de funcție sub numele de Object Lock.

Acum să discutăm modul în termeni generali, apoi ne vom aprofunda în detalii. În exemplul nostru, Immutability va fi activat pentru capacitatea noastră cu o retenție de patru zile. Iar în backup este activat modul Copy.

Immutability nu interacționează deloc cu retenția generală. De exemplu, nu adaugă puncte suplimentare sau ceva asemănător. Pur și simplu, în decurs de patru zile, o persoană nu poate șterge fișierele backup-urilor. Dacă în ziua de luni se face un backup, atunci fișierul său poate fi șters doar vineri.

Toate conceptele explicate anterior despre dehidratare, indecși și metadate continuă să funcționeze exact la fel. Dar cu o condiție — blocul este stabilit nu doar pentru date, ci și pentru metadate. Acest lucru este făcut pentru cazul în care un atacator viclean decide să șteargă baza noastră de metadate, astfel încât blocurile de date să nu devină o masă binară inutilă.

Și acum a sosit momentul excelent pentru a explica tehnologia noastră de generare a blocurilor. Sau block generation. Pentru aceasta, să analizăm situația care a dus la apariția acesteia.

Să luăm o scară temporală de șase zile și vom marca în partea de jos timpul estimat al expirării immutabilității. Creăm, în prima zi, un fișier format din blocul a și metadatele sale. Dacă immutabilitatea este setată la trei zile, este logic să presupunem că în a patra zi datele vor fi deblocate și șterse. În a doua zi, adăugăm un nou fișier file2, format din blocul b cu aceleași setări. Blocul a ar trebui să fie în continuare șters în a patra zi. Dar în a treia zi se întâmplă ceva groaznic — se creează fișierul File3, format dintr-un nou bloc d și referința la vechiul bloc a. Asta înseamnă că pentru blocul a, steagul de immutabilitate ar trebui resetat la un nou termen, care se mută în a șasea zi. Și aici apare problema — în backup-urile reale ale acestor blocuri, se produce un număr imens. Și pentru a extinde perioada de immutabilitate, trebuie să facem constant un număr foarte mare de cereri. Și, de fapt, acest proces va fi aproape nesfârșit zilnic, deoarece este foarte probabil ca la fiecare copiere să găsim grămezi mari de blocuri deduplicat. Și ce înseamnă un număr mare de cereri pentru furnizorii de stocare de obiecte? Exact! O factură enormă la sfârșitul lunii.

Și pentru a nu expune clienții noștri dragi la costuri considerabile fără motiv, a fost inventat mecanismul de generare a blocurilor. Acesta este un interval suplimentar pe care îl adăugăm la perioada stabilită de immutabilitate. În exemplul de mai jos, această perioadă este de două zile. Dar aceasta este doar pentru exemplificare. În realitate, o formulă proprie este utilizată, care oferă aproximativ zece zile suplimentare pentru un blocaj lunar.

Să continuăm să discutăm aceeași situație, dar deja cu generarea de blocuri. Creăm în prima zi file1 din blocul a și metadatele. Adunăm perioada de generație și imutabilitate – înseamnă că posibilitatea de a șterge fișierul va fi în a șasea zi. Dacă în a doua zi creăm File2, compus din bloc b și un link la blocul a, atunci data estimată a ștergerii nu se schimbă. Rămâne la a șasea zi, exact ca la început. Încercăm astfel să economisim bani pe numărul de solicitări. Singura situație în care termenul poate fi mutat este dacă perioada de generație a expirat. Așadar, dacă în a treia zi noul File3 va conține un link către blocul a, atunci se va adăuga generația 2 deoarece Gen1 a expirat deja. Data estimată a ștergerii blocului a se va muta în a opta zi. Aceasta ne permite să reducem dramatic numărul de solicitări pentru prelungirea timpului de viață al blocurilor deduplicated, ceea ce economisește o sumă considerabilă de bani clienților.

Tehnologia în sine este disponibilă utilizatorilor S3 și hardware-ului compatibil S3, ale căror producători garantează că implementarea lor nu diferă de cea amazoniană. De aici răspunsul la întrebarea legitimă de ce nu este susținut Azure – au o caracteristică similară, dar aceasta funcționează la nivelul containerelor, nu al obiectelor individuale. Apropo, în Amazonul însuși, Object Lock există în două moduri: compliance și governance. În al doilea caz, rămâne posibilitatea ca cel mai mare administrator dintre administratori, și root-ul între root-uri, în ciuda Object Lock, totuși să șteargă datele. În cazul compliance, totul este bătut în cuie, iar backup-urile nu pot fi șterse de nimeni. Chiar și de către administratorii Amazon (conform declarațiilor lor oficiale). Noi susținem exact acest mod.