Capacity Tier (sau cum îl numim noi în Vim - captir) a apărut în zilele Veeam Backup and Replication 9.5 Update 4 sub numele Archive Tier. Ideea din spatele acestuia este de a face posibilă mutarea copiilor de rezervă care au căzut din așa-numita fereastră de restaurare operațională în stocarea obiectelor. Acest lucru a ajutat la eliberarea spațiului pe disc pentru acei utilizatori care aveau puțin din el. Și această opțiune a fost numită Move Mode.

Pentru a efectua această acțiune simplă (după cum pare), a fost suficient să se îndeplinească două condiții: toate punctele din backup-ul mutat trebuie să fie în afara limitelor ferestrei de restaurare operațională menționată mai sus, care este setată în mod explicit în interfața de utilizare. Și în al doilea rând: lanțul trebuie să fie în așa-numita „formă sigilată” (lanț de rezervă sigilat sau Lanț de rezervă inactiv). Adică, în acest lanț nu apar modificări în timp.

Dar în VBR v10, conceptul a fost suplimentat cu noi funcții - Modul Copiere, Modul Sigilat și a apărut un lucru cu numele greu de pronunțat Immutabilitatea.

Acestea sunt lucrurile fascinante despre care vom vorbi astăzi. În primul rând, despre cum a funcționat în VBR9.5u4 și apoi despre modificările din a zecea versiune.

Și să mă ierte campionii limbajului pur, dar sunt prea mulți termeni care nu pot fi traduși.
Deci vor fi o mulțime de anglicisme aici.
Și multe gif-uri.
Și poze.

• Fără cel mai mic regret. Autorul articolului.

Așa cum a fost

Ei bine, să începem prin a analiza fereastra de restaurare operațională și backup-ul sigilat (sau așa cum sunt numite în documentația Lanțului de backup inactiv). Fără înțelegerea lor, explicații suplimentare nu vor fi posibile.

După cum vedem în imagine, avem un fel de lanț de backup cu blocuri de date, care se află pe nivelul de performanță SOBR al depozitului la care este conectat nivelul de capacitate. Fereastra noastră de rezervă operațională este de trei zile.

În consecință, .vbk creat luni sigilează lanțul anterior, a cărui fereastră este setată la trei zile. Și asta înseamnă că poți începe în siguranță să transporti tot ce este mai vechi decât aceste trei zile la poligon de tragere.

Dar ce s-a înțeles exact prin lanț sigilat și ce ar putea fi trimis la poligonul de tragere cu capacitate în actualizarea 4?

Pentru Forward Incremental, un semn de etanșare a lanțului este crearea unui nou backup complet. Și nu contează cum se obține această copie de rezervă completă: sunt luate în considerare atât copiile de siguranță complete sintetice, cât și cele active complete.

În cazul Reverse, acestea sunt toate fișierele care nu intră în fereastra de operare.

În cazul incrementului Forward cu rollback, acestea sunt toate rollback-uri și .vbk, dacă există un alt .vbk pe măsura performanței

Acum să luăm în considerare opțiunea de a lucra cu lanțuri de copiere de rezervă. Aici au fost transportate doar articolele care se încadrează în reținerea GFS. Pentru că tot ceea ce este stocat în lanțurile de copii de rezervă mai recente poate fi schimbat într-un fel sau altul.

Acum să ne uităm sub capotă. Acolo, are loc un proces numit deshidratare - lăsând fișierele de rezervă goale pe extindere și tragerea blocurilor din aceste fișiere în raza de fotografiere a capacității. Pentru a optimiza acest proces, se folosește așa-numitul indice de deshidratare, care vă permite să evitați copierea blocurilor care au fost deja copiate în raza de tragere la capacitate.

Să vedem cum arată cu un exemplu: Să presupunem că avem un .vbk care a ieșit din fereastra tranzacției și aparține unui lanț sigilat. Aceasta înseamnă că avem tot dreptul să-l mutăm în poligonul de tragere cu capacitate. În momentul mutării, un fișier de metadate este creat în liniuța de capacitate și blocurile fișierului transferat. Fișierul de metadate la nivel de link descrie din ce blocuri constă fișierul nostru. În cazul din imagine, primul nostru fișier este format din blocurile a, b, c, iar metadatele conțin link-uri către aceste blocuri. Când avem un al doilea fișier .vbk, gata de mutat și format din blocurile a, b și d, noi, analizând indicele de deshidratare, înțelegem că trebuie transferat doar blocul d. Și fișierul său de metadate va conține link-uri către două blocuri anterioare și unul nou.

În consecință, procesul de umplere a acestor spații goale înapoi cu date se numește rehidratare. Folosește deja propriul indice de rehidratare, bazat pe cel mai vechi fișier .vbk privind gradul de performanță local. Adică, dacă utilizatorul dorește să returneze un fișier din domeniul de fotografiere de capacitate, mai întâi creăm un index al blocurilor celei mai vechi copii de siguranță completă și transferăm doar blocurile lipsă din galeria de fotografiere de capacitate. In cazul prezentat in poza, pentru a rehidrata FullBackup1.vbk dupa indicele de rehidratare, avem nevoie doar de blocul C, pe care il luam din raza de tragere de capacitate. Dacă un obiect nor de stocare servește ca poligon de tragere cu capacitate, acest lucru vă permite să economisiți sume enorme de bani.

Aici poate părea că această tehnologie este identică cu cea folosită în Acceleratoarele WAN, dar doar așa pare. În acceleratoare, deduplicarea este globală; aici, deduplicarea locală este utilizată în fiecare fișier la un anumit decalaj. Acest lucru se întâmplă din cauza diferenței dintre sarcinile care se rezolvă: aici trebuie să copiem fișiere mari de backup complet, iar conform cercetărilor noastre, chiar dacă între ele trece o perioadă lungă de timp, acest algoritm de deduplicare dă cel mai bun rezultat.

Dar mai multe indici pentru zeul indicilor! Există și un index pentru recuperarea datelor! Când începem să restaurăm o mașină situată în liniuța de capacitate, vom citi doar blocuri de date unice care nu sunt în liniuța de performanță.

Cum a devenit

Asta e tot pentru partea introductivă. Este destul de detaliat, dar după cum am menționat mai sus, fără aceste detalii nu va fi posibil să explicăm cum funcționează noile funcții. Prin urmare, fără alte prelungiri, să trecem la primul.

Mod copiere

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

Scopul acestui mod este de a se asigura că toate datele situate pe extensia locală au o copie în liniuța de capacitate.

Dacă comparați direct modurile Mutare și Copiere, va arăta astfel:

• Numai lanțul etanșat poate fi mutat. În cazul unui mod de copiere, absolut totul este transferat, indiferent de ceea ce se întâmplă în jobul de backup.
• Mutarea este declanșată atunci când fișierele depășesc limitele ferestrei de backup operaționale, iar copierea este declanșată de îndată ce apare fișierul de rezervă.
• Monitorizarea datelor noi pentru copiere are loc constant, iar pentru mutare a fost declanșată o dată la 4 ore.

Considerând noul mod, îmi propun să trecem de la exemple simple la cele complexe.

În cel mai obișnuit caz, pur și simplu avem fișiere noi cu incremente și pur și simplu le copiam în raza de fotografiere de capacitate. Indiferent de ce mod este utilizat în jobul de rezervă, indiferent dacă acesta aparține părții sigilate a lanțului sau nu, indiferent dacă fereastra noastră de operare a expirat. Pur și simplu l-au luat și l-au copiat.

Procesul din spatele acestui lucru este încă deshidratarea, așa cum este descris mai sus. În modul copiere, se asigură, de asemenea, că nu copiem blocurile care sunt deja în stocarea noastră. Singura diferență este că, dacă în modul film am înlocuit fișierele reale cu fișiere false, aici nu le atingem în niciun fel și lăsăm totul așa cum este. În rest, este exact același indice de deshidratare, care încearcă cu grijă să-ți economisească bani și timp.

Apare întrebarea - dacă te uiți la interfața de utilizare, există posibilitatea de a selecta ambele opțiuni în același timp. Cum va funcționa un astfel de mod combinat?

Să ne dăm seama.

Începutul este standard: un fișier de rezervă este creat și copiat imediat. Un increment este creat și copiat. Acest lucru se întâmplă până în momentul în care realizăm că fișierele au părăsit fereastra noastră de operare și a apărut un lanț sigilat. În acest moment, efectuăm o operație de deshidratare și înlocuim aceste fișiere cu fișiere false. Desigur, nu copiem nimic din nou în poligonul de tragere cu capacitate.

Toată această logică fascinantă este responsabilă pentru o singură casetă de selectare din interfață: Copiați copiile de rezervă în stocarea obiectelor de îndată ce sunt create.

De ce avem nevoie de acest mod de copiere?

Este și mai bine să reformulăm întrebarea astfel: de ce riscuri suntem protejați cu ajutorul lui? Ce problemă ne ajută să rezolvăm?

Răspunsul este evident: desigur, aceasta este recuperarea datelor. Dacă avem o copie completă a datelor locale pe stocarea obiectelor, atunci indiferent de ceea ce se întâmplă cu produsul nostru, putem oricând să restabilim datele din fișierele aflate în Amazon condiționat.

Așa că haideți să trecem prin scenariile posibile, de la cele mai simple la cele mai complexe.

Cea mai simplă nenorocire care ne poate cădea în cap este inaccesibilitatea unuia dintre fișierele din lanțul de backup.

O poveste mai tristă este că una dintre extinderile depozitului nostru SOBR s-a rupt.

Devine și mai rău atunci când întregul depozit SOBR a devenit inaccesibil, dar capacitatea de fotografiere funcționează.
Și totul este foarte rău - atunci serverul de rezervă moare și prima ta dorință este să încerci să fugi la granița cu Canada în zece minute.

Acum să ne uităm la fiecare situație separat.

Când am pierdut unul (și chiar mai multe) fișiere de rezervă, atunci tot ce trebuie să facem este să începem procesul de rescanare a depozitului, iar fișierul pierdut va fi înlocuit cu un fișier inactiv. Și folosind procesul de rehidratare (despre care a fost discutat la începutul articolului), utilizatorul va putea să descarce date din raza de tragere cu capacitate în stocarea locală.

Acum situația este mai complicată. Să presupunem că SOBR-ul nostru constă din două extensii care rulează în modul Performanță, ceea ce înseamnă că .vbk și .vib sunt răspândite peste ele într-un strat destul de neuniform. Și la un moment dat, una dintre extinde devine indisponibilă, iar utilizatorul are nevoie urgent să restaureze mașina, o parte din datele căreia se află tocmai pe această măsură.

Utilizatorul lansează vrăjitorul de recuperare, selectează punctul în care dorește să restaureze, iar vrăjitorul, în timp ce lucrează, își dă seama că nu are toate datele necesare pentru recuperare la nivel local și, prin urmare, trebuie să fie descărcat din capacitatea de filmare. Galerie. În același timp, blocurile care rămân pe stocarea locală nu vor fi descărcate din cloud. Slavă indexului de restaurare (da, a fost menționat și la începutul articolului).

Un subtip al acestui caz este că întregul depozit SOBR a devenit inaccesibil. În acest caz, nu avem nimic de copiat din stocarea locală și toate blocurile sunt descărcate din cloud.

Și cea mai interesantă situație este că serverul de rezervă a murit. Există două opțiuni aici: administratorul este grozav și a făcut copii de rezervă ale configurației, iar administratorul este însuși un Pinocchio rău și nu a făcut copii de siguranță ale configurației.

În primul caz, va fi suficient pentru el să implementeze pur și simplu o instalare curată a VBR undeva și să-și restaureze baza de date dintr-o copie de rezervă folosind mijloace standard. La sfârșitul acestui proces, totul va reveni la normal. Sau va fi restaurat conform unuia dintre scenariile de mai sus.

Dar dacă administratorul este fie propriul său dușman, fie backupul de configurare a suferit și un eșec epic, atunci nici aici nu îl vom lăsa în mila destinului. Pentru acest caz, am introdus o nouă procedură numită Import Object Storage. Vă permite să săriți peste procesul de recreare manuală a unui depozit SOBR și să atașați la acesta o zonă de fotografiere cu capacitate, cu rescanarea ulterioară și pur și simplu să adăugați un obiect de stocare la interfața Vim și să rulați procedura Import Storage Repository. Singurul lucru care poate sta în calea între dvs. și copiile de rezervă este o solicitare de a introduce o parolă dacă copiile de rezervă au fost criptate.

Probabil că totul este despre modul Copiere și trecem la

Modul Sigilat

Ideea principală este că noile copii de rezervă nu pot apărea pe extensia SOBR selectată a depozitului. Înainte de v10, aveam doar modul de întreținere, când orice lucru cu depozitul era complet interzis. Un fel de mod hardcore pentru închiderea stocării, în care este disponibil doar butonul Evacuare, care transportă copiile de rezervă într-o altă măsură o singură dată.

Și modul Sealed este un fel de opțiune „soft”: interzicem crearea de noi copii de rezervă și ștergem treptat pe cele vechi în funcție de retenția selectată, dar în acest proces nu pierdem capacitatea de a restaura din punctele stocate. Un lucru foarte util atunci când fie avem o piesă hardware care se apropie de sfârșitul vieții și trebuie să o înlocuim, fie trebuie doar să o eliberăm pentru ceva mai important, dar nu există unde să o luăm și să mutăm totul deodată. Sau nu poate fi șters.

În consecință, principiul de funcționare este destul de simplu: este necesar să se interzică toate operațiunile de scriere (apariția de date noi), lăsând citire (restaurări) și ștergere (reținere).

Ambele moduri pot fi utilizate simultan, dar rețineți că Întreținerea are o prioritate mai mare.

Ca exemplu, luați în considerare un SOBR format din două extent. Să presupunem că în primele patru zile am creat copii de rezervă în modul Forward Forever Incremental, apoi sigilăm măsura, ceea ce duce la faptul că inițiem crearea unui nou full activ pe a doua extensie disponibilă. Dacă retenția noastră este de patru, atunci când întregul lanț situat pe întinderea sigilată depășește limitele sale, acesta este șters cu conștiința curată.

Există situații în care ștergerea are loc mai devreme. De exemplu, acesta este Forward incremental cu completări periodice. Dacă am creat copii de rezervă complete în primele două zile, iar joi decidem să sigilăm depozitul, atunci vineri, când este creată o nouă copie de rezervă, fișierul pentru luni va fi șters deoarece nu există dependențe până în acest punct. Iar punctul în sine nu depinde de nimeni. Apoi așteptăm până când sunt create patru puncte pe măsura disponibilă și ștergem celelalte trei, care nu pot fi șterse independent unele de altele.

Lucrurile sunt mai simple cu Reverse Incremental. În ea, cele mai vechi puncte nu depind de nimic și pot fi șterse în siguranță. Prin urmare, de îndată ce un nou .vbk este creat pe o nouă măsură, vechile .vrbs vor fi șterse unul câte unul.

Apropo, de ce creăm un nou .vbk de fiecare dată: dacă nu l-am creat, dar am continuat vechiul lanț de incremente, atunci vechiul .vbk s-ar bloca infinit de mult în orice mod, prevenind ștergerea lui. Prin urmare, s-a decis ca, de îndată ce extinderea este sigilată, să creăm o copie de rezervă completă a extinderii gratuite.

Lucrurile sunt mai complicate cu capacitatea de tragere.

Să ne uităm mai întâi la modul copiere. Să presupunem că am creat în mod activ copii de rezervă timp de patru zile, iar apoi zona de tragere a capacității a fost sigilată. Nu ștergem nimic, ci suportăm cu umilință reținerea, după care ștergem datele din poligonul de tragere la capacitate.

Aproximativ același lucru se întâmplă în modul mutare - așteptăm retușul, îl ștergem pe cel vechi din stocarea locală și îl ștergem pe cel stocat în stocarea obiectelor.

Un exemplu interesant cu Forever forward incremental. Instalăm retenția în trei puncte și începem să facem copii de rezervă de luni, care sunt copiate în mod regulat în cloud. După sigilarea spațiului de stocare, continuă să fie create copii de rezervă, menținând trei puncte, dar datele stocate în liniuța de capacitate rămân dependente și nu pot fi șterse. Prin urmare, așteptăm până joi, când .vbk-ul nostru depășește reținerea și abia atunci ștergem cu calm întregul lanț salvat.

Și o mică declinare a răspunderii: toate exemplele de aici sunt afișate cu o singură mașină. Dacă aveți mai multe dintre ele în backup, atunci retușarea lor va diferi în funcție de faptul dacă a fost făcută sau nu Active Full.

Asta e practic tot ceea ce este. Deci, să trecem la cea mai hardcore caracteristică -

Imuabilitate

Ca și în cazul punctelor anterioare, primul lucru este ce problemă rezolvă această funcție. De îndată ce încărcăm copiile de rezervă undeva pentru stocare, există o dorință puternică de a garanta siguranța acestora, adică de a interzice fizic ștergerea lor și orice modificare în timpul unei anumite păstrări. Inclusiv administratorii, inclusiv sub conturile lor root. Acest lucru vă permite să le protejați de daune accidentale sau intenționate. Oricine lucrează cu AWS poate să fi întâlnit o caracteristică similară numită Object Lock.

Acum să ne uităm la modul în termeni generali și apoi să ne aprofundăm în detalii. În exemplul nostru, Imutabilitatea va fi activată pentru poligonul nostru de tragere cu o capacitate de păstrare de patru zile. Și modul Copiere este activat în backup.

Imuabilitatea nu interacționează în niciun fel cu retenția generală. De exemplu, nu adaugă puncte suplimentare sau ceva de genul acesta. Doar că o persoană nu poate șterge fișierele de rezervă în termen de patru zile. Dacă faceți o copie de rezervă luni, veți putea șterge fișierul abia vineri.

Toate conceptele explicate anterior despre deshidratare, indici și metadate continuă să funcționeze exact la fel. Dar cu o condiție - blocul este setat nu numai pentru date, ci și pentru metadate. Acest lucru se face în cazul în care un atacator viclean decide să ștergă baza noastră de date cu metadate și să împiedice blocurile de date să se transforme într-un zâmbet binar inutil.

Acum este momentul potrivit pentru a explica tehnologia noastră de generare a blocurilor. Sau generarea blocurilor. Pentru a face acest lucru, luați în considerare situația care a dus la apariția sa.

Să luăm o scală de timp de șase zile și mai jos vom marca momentul expirării așteptate a imuabilității. În prima zi luăm și creăm un fișier format din blocul de date a și metadatele acestuia. Dacă imuabilitatea este setată la trei zile, este logic să presupunem că în a patra zi datele vor fi deblocate și șterse. În a doua zi vom adăuga un nou fișier2, format din blocul b cu aceleași setări. Blocul a mai trebuie eliminat în a patra zi. Dar în a treia zi se întâmplă ceva groaznic - este creat un fișier File3, constând dintr-un bloc nou d și o legătură către blocul vechi a. Aceasta înseamnă că pentru un bloc și indicatorul de imuabilitate al acestuia trebuie resetat la o nouă dată, care este mutată la a șasea zi. Și aici apare o problemă - în backup-urile reale există un număr mare de astfel de blocuri. Și pentru a prelungi perioada de imuabilitate a acestora, trebuie să faceți un număr mare de solicitări de fiecare dată. Și, de fapt, acesta va fi un proces zilnic aproape nesfârșit, deoarece cu un grad ridicat de probabilitate vom găsi stive mari de blocuri deduplicate cu fiecare copie. Ce înseamnă un număr mare de solicitări de la furnizorii de stocare a obiectelor? Dreapta! Factură uriașă la sfârșitul lunii.

Și pentru a nu expune din senin clienții tăi preferați pentru bani substanțiali, a fost inventat mecanismul de generare a blocurilor. Aceasta este o perioadă suplimentară pe care o adăugăm la perioada de imuabilitate stabilită. În exemplul de mai jos, această perioadă este de două zile. Dar acesta este doar un exemplu. În realitate, folosesc propria formulă, care oferă aproximativ zece zile suplimentare în timpul unei blocări lunare.

Să luăm în continuare aceeași situație, dar cu generarea blocurilor. În prima zi creăm fișierul1 din blocul a și metadate. Adunăm perioada de generare și imuabilitatea - asta înseamnă că posibilitatea de a șterge fișierul va fi în a șasea zi. Dacă în a doua zi creăm Fișier2, constând din blocul b și un link către blocul a, atunci nu se întâmplă nimic cu data de ștergere așteptată. A stat la fel ca în ziua a șasea. Și astfel încercăm să economisim bani pe numărul de solicitări. Singura situație în care termenul limită poate fi deplasat este dacă perioada de generare a expirat. Adică, dacă în a treia zi noul File3 conține un link pentru a bloca a, atunci generația 2 va fi adăugată deoarece Gen1 a expirat deja. Și data estimată pentru ștergerea blocului a se va muta în a opta zi. Acest lucru ne permite să reducem dramatic numărul de solicitări pentru a prelungi durata de viață a blocurilor deduplicate, ceea ce economisește clienții o mulțime de bani.

Tehnologia în sine este disponibilă utilizatorilor de hardware compatibil S3 și S3, ai căror producători garantează că implementarea lor nu diferă de cea a Amazon. De aici răspunsul la întrebarea legitimă de ce Azure nu este acceptat - au o caracteristică similară, dar funcționează la nivel de containere, nu de obiecte individuale. Apropo, Amazon în sine are blocarea obiectelor în două moduri: conformitate și guvernare. În al doilea caz, rămâne posibilitatea ca cel mai mare admin de deasupra admins și root deasupra rădăcinilor, în ciuda blocării obiectului, să ștergă în continuare datele. În cazul conformității, totul este bine pus în cuie și nimeni nu poate șterge copiile de rezervă. Chiar și administratorii Amazon (conform declarațiilor lor oficiale). Acesta este modul pe care îl sprijinim.

Și, ca de obicei, câteva link-uri utile:

• despre Generarea blocurilor în fiecare detaliu.
• Toate informatiile despre Veeam Backup & Replication 10 la cel mai bun mod
• О Nivelul de capacitate in detalii

Sursa: www.habr.com