Foarte important – Checkpoint-ul sau Snapshot-ul nu echivaleaza cu un backup. Nu il folositi ca atare. Un checkpoint sau un snapshot nu este bine sa fie lasat mai mult de cateva zile. Este folosit doar ca o metoda de a reveni la o anumita stare anterioara intr-un timp foarte scurt si controlat. NU inlocuieste niciodata backup-ul!

Exista si software care actioneaza asupra sistemului de operare si cere automat crearea de checkpoint-uri. In cele mai multe cazuri, soft-urile de backup care lucreaza la nivel de hypervizor vor cere automat crearea de checkpoint-uri inainte de inceperea operatiunii de backup si stergerea checkpoint-ului la sfarsitul operatiunii.

In cazul administrarii neglijente sau a unor erori din partea soft-ului de virtualizare sau a soft-ului de backup este posibil sa avem mai multe checkpoint-uri uitate ce pot duce la scaderea performantei, scaderea spatiului disponibil pe disk-ul Hyper-V-ului cat si blocaje de functionare sau imposibilitatea de a restaura functionarea in starea respectiva.

Exemplu de astfel de situatie:

In acest caz se observa ca aceasta masina virtuala are 7 checkpoint-uri. La fel este posibil sa gasim o masina virtuala cu 30-40 de checkpoint-uri. Se poate observa din disk-urile de diferentiere faptul ca a fost modificata o cantitate substantiala de date intre fiecare checkpoint:

Putem observa ca fiecarui checkpoint ii corespunde cate un fisier AVHDX cu diferentele scrise pe disk in perioadele respective.

In majoritatea cazurilor, ca cel de mai sus, este de ajuns sa eliberam spatiu pe disk-ul Hyper-V-ului si masina va putea reporni fara nicio problema. Dar sa presupunem ca ne aflam in cel mai nefericit caz in care masina virtuala este corupta ca si configuratie si Disk-urile de diferentiere nu mai cunosc ordinea in care se afla. (Nu mai exista relatia Copil-Parinte intre ele). Aceasta relatie este definita doar in cadrul disk-ului copil. Parintele nu cunoaste relatia respectiva. Cea mai simpla varianta de a vedea aceasta relatie intre 2 disk-uri este de a selecta disk-ul copil si rulam comanda de Inspect Disk din Hyper-V

Observam in acest caz ca relatia copil parinte pentru acest disk de diferentiere este stabilita

Este totusi posibil ca unul sau mai multe din disk-urile de diferentiere sa nu isi mai recunoasca parintele si sa dea eroare:

In astfel de cazuri, putem considera ca avem o problema grava ce trebuie rezolvata pentru restaurarea accesului la datele importante clientului. Masina virtuala nu va porni in acest moment si sunt sanse mari de pierdere de date.

Primul lucru care trebuie sa il facem este sa facem nu una, ci 2 copii ale disk-urilor masinii (si parinte si disk-uri de diferentiere).

Backup1 pentru disk-uri va fi pastrat doar pentru a avea o imagine curata a disk-urilor asa cum erau inainte de modificare.

Backup2 va fi folosit pentru modificarile si testele necesare pentru a restaura accesul la date. Vom folosi 2 indicatoare pentru a ne usura munca.

1. Ne vom folosi de datele de ultima modificare a fisierelor AVHDX pentru a incerca sa stabilim o ordine de creare a snapshot-urilor.

In mod normal, daca nu au fost erori de data si ora pe server, ordinea respectiva este indicativa cu ordinea in care AVHDX-urile au fost create si astfel incepand de la cel mai nou fisier catre cel mai vechi putem stabili o relatie copil parinte. Astfel, in imaginea de mai sus, fisierul care incepe cu indicatorul 3D3EA867 poate fi considerat copil pentru parintele cu indicatorul B83B9D3F. La fel fisierul cu indicatorul B83B9D3F poate fi considerat copil pentru parintele cu indicatorul 164FD0CC si asa mai departe.

Vom nota intr-un tabel ordinea pe care o putem stabili conform datei ca o posibila ordine “corecta”.

Daca, de exemplu, un soft sau un administrator va incerca sa faca unirea a 2 fisere pentru a rezolva probelma si nu o va face in ordinea 100% corecta, este posibil ca DATA si ORA sa fie interpretate gresit. Situatie: daca avem Parinte <- C1 <- C2 <- C3 <- C4 <- C5 <- C6, unde “<-“ semnifica relatia copil parinte intre 2 fisiere. C1 este copil pentru “Parinte”. C2 este copil pentru C1, etc.

Daca, de exemplu, cineva ruleaza operatiunea de Merge (unire) intre C3 si C2, atunci relatia corecta ar fi Parinte <- C1 <- C2New <- C4 <- C5 <-C6. De notat, ca la rularea operatiei de “merge” intre 2 astfel de fisere va rezulta un singur fisier cu numele fisierului identic cu al parintelui. Al 2-lea lucru FOARTE IMPORTANT de notat este ca C2New va avea data de modificare mai noua decat C6. Din acest motiv, trebuie sa avem foarte mare grija. Ordinea data de datele de modificare ale fisierelor este posibil sa nu fie ordinea definitiva. Demonstram asta cu fisierele din exemplul de mai sus:

In varianta de mai sus observam ca lipseste unul din AVHDX-uri si fisierul cu indicativul 648DF4EA are capacitate mai mare cat si faptul ca este cel mai nou fisier modificat din acest folder. In mod normal nu vom avea toate informatiile din acest exemplu si va trebui sa ne descurcam fara toate aceste informatii. Astfel, vom nota POSIBILA ordine conform datelor de modificare, dar nu o consideram 100% corecta :

Parinte <- B13DF883 <- 8CDD76F7 <- 164FD0CC <- B83B9D3F <- 3D3EA86F <- 648DF4EA

Observati diferentele fata de relatia corecta:

Parinte <- B13DF883 <- 8CDD76F7 <- 648DF4EA <- 164FD0CC <- B83B9D3F <- 3D3EA86F

Daca am rula in acest moment operatiunea de “Merge” in functie de data, este clar ca masina virtuala se va defecta. Astfel, va trebui sa incercam sa aflam un al 2-lea indicativ pentru a putea crea o ordine corecta.

2. Ne folosim de relatiile copil – parinte care sunt in continuare definite pe fiecare dintre AVHDX-uri.

Putem folosi functia de Inspect-Disk din Hyper-V cum am facut mai sus, sau putem folosi comanda Get-VHD din powershell. De exemplu, ruland comanda Get-VHD pe fisierul cu indicativul 648DF4EA vom avea urmatorul rezultat:

PS C:\Backup\BKPDrives2\Virtual Hard Disks> Get-VHD “C:\Backup\BKPDrives2\Virtual Hard Disks\Cel mai important server_648DF4EA-F7A9-4CEC-8BC2-60F5EA653688.avhdx”

Observam ca aici relatia este corecta. Putem trage concluzia ca “<- 8CDD76F7 <- 648DF4EA” ar putea sa fie corect.

Ruland aceasta comanda pe fiecare dintre avhdx-uri vom avea urmatorul rezultat:

Parinte <- B13DF883 <- 8CDD76F7 <- 648DF4EA

A4CD7621 <- 164FD0CC <- B83B9D3F <- 3D3EA86F

Observati ca avem 2 seturi de relatii de inlantuire. Vom defini cele 2 seturi ca Lant1 si Lant2. Motivul pentru care avem 2 lanturi este ca A4CD7621 nu mai exista.

Observam ca primul lant contine parintele. Astfel putem trage concluzia ca Lant1 este primul lant si acesta il are ca si copil pe Lant2. Este foarte posibil sa nu avem aceasta posibilitate in cazuri in care avem mai multe rupturi de lant. Este posibil sa avem Lant 1, Lant 2, Lant 3 si Lant 4. In astfel de cazuri, vom avea mai multe posibiltati de inlantuire:

Lant 1 <- Lant 2 <- Lant 3 <- Lant 4

Lant 1 <- Lant 2 <- Lant 4 <- Lant 3

Lant 1 <- Lant 3 <- Lant 4 <- Lant 2

Lant 1 <- Lant 3 <- Lant 2 <- Lant 4

Lant 1 <- Lant 4 <- Lant 2 <- Lant 3

Lant 1 <- Lant 4 <- Lant 3 <- Lant 4

Incercati sa determinati ordinea lanturilor folosind datele de modificare a membrilor din lant. Este foarte posibil ca aceste 2 indicatoare folosite impreuna sa va ofere ordinea corecta.

Cum testam / ne asiguram?

Dupa ce am ales o varianta de a crea lantul pe care dorim sa o testam, trebuie sa o si aplicam.

Primul pas este cel de a reface legatura intre cele 2 lant-uri. Astfel, va trebui sa inlocuim in lantul 2 fisierul cu indicativul A4CD7621 cu fisierul cu indicativul 648DF4EA.

Pentru aceasta, putem folosi comanda Set-VHD astfel:

PS C:\Backup\BKPDrives2\Virtual Hard Disks> Set-VHD -path “C:\Backup\BKPDrives2\Virtual Hard Disks\Cel mai important server_164FD0CC-9965-4185-B6D4-226CCEE9FDF1.avhdx” -ParentPath “C:\Backup\BKPDrives2\Virtual Hard Disks\Cel mai important server_648DF4EA-F7A9-4CEC-8BC2-60F5EA653688.avhdx”

Este posibil sa dea eroare ca ID-ul nu este compatibil. In acest caz vom folosi paramentrul : “-IgnoreIdMismatch”. Folositi cu foarte mare grija acest parametru, deoarece poate duce la corupere de date daca ordinea nu este corecta si deschidem, permitem sistemului sa faca modificari asupra disk-ului nou.

Set-VHD –path “calea-catre-avhdx-copil” –parentpath “calea-catre-parinte” –IgnoreIdMismatch

Dupa ce rulam comenzile necesare pentru a uni lantul vom folosi comanda de Inspect-Disk pe ultimul copil si vom da click pe Inspect Parent pana cand ajungem la fisierul parinte. Daca am ajuns la fisierul parinte inseamna ca avem un lant complet.

In momentul in care avem un lant complet exista tentatia de a folosi comanda de Merge pentru a uni toti copii cu parintii si a ramane cu un singur disk sau de a porni masina virtuala ca sa accesam datele cat mai repede.

NU SE RECOMANDA ACEASTA OPERATIUNE.

Daca sistemul de fisere din aceasta masina virtuala este un sistem de fisiere ce poate fi citit si inteles de catre sistem de operare Microsoft (NTFS, FAT, FAT32, EXFAT, etc) atunci deschidem consola de Disk Management. Din consola de Disk Management, din meniul Action vom da click pe Attach VHD:

Foarte important : Bifati “Read-Only”

Selectati ultimul avhdx din chain si dati click pe OK:

Daca legatura intre lanturi a fost facuta corect, atunci sistemul de fisere ar trebui sa fie inteles de catre sistemul de operare si partitiile sa fie montate:

In acest moment este incurajat sa intram in partitia montata si sa verificam fisiere modificate din ultima perioada cat si din trecut pentru a ne asigura ca am configurat corect tot ce este nevoie:

Daca totul este OK, se recomanda un backup al tuturor fisierelor de pe aceste partitii. In momentul in care facem backup putem observa si daca avem erori pe fisiere. In caz de fisiere corupte este foarte posibil sa nu avem lantul construit corect.

In acest moment, demontam disk-ul atasat din Disk Managemnt cu click dreapta pe Disk-ul atasat si Detach VHD:

Daca totul a fost OK, atunci putem modifica masina virtuala existenta sa foloseasca disk-ul sau sa folosim disk-ul pentru a crea o masina virtuala noua.

In cazul in care sistemul de fisiere nu va fi recunoscut de Microsoft Windows, (ex: sisteme de fisiere Linux), se poate instala o masina virtuala cu sistem de operare compatibil la care sa atasam disk-ul avhdx pentru citire date. In acest caz, daca lantul nu este facut corect, exista risc foarte ridicat de corupere de date. Inclusiv daca din sistemul de operare setam ca mod de montare Read-Only. In acest caz, daca determinam ca lantul nu este corect, atunci va fiu nevoie sa inlocuim ultimul copil din Backup2 cu o copie FRESH din Backup1 si sa reconstruim lantul cu o alta varianta din cele mentionate mai sus:

Lant 1 <- Lant 2 <- Lant 3 <- Lant 4

Lant 1 <- Lant 2 <- Lant 4 <- Lant 3

Lant 1 <- Lant 3 <- Lant 4 <- Lant 2

Lant 1 <- Lant 3 <- Lant 2 <- Lant 4

Lant 1 <- Lant 4 <- Lant 2 <- Lant 3

Lant 1 <- Lant 4 <- Lant 3 <- Lant 4

Dupa accesarea datelor in orice fel, se recomanda crearea unui backup cat mai urgent a tuturor datelor importante. Daca tot sistemul de fisere este intreg, atunci se poate folosi in continuare. Daca nu, se recomanda crearea unui disk virtual nou si transferarea datelor acolo.

In cazul in care una din componentele lantului lipseste complet (cineva a sters un fisier avhdx) exista totusi posibilitatea recuperarii a unei parti din date atat timp cat parintele principal nu a fost sters sau afectat:

Exemplul : Lant 1 <- Lant 2 <- AVHDX_LIPSA <- Lant 4 <- Lant 5

In acest caz, se creaza prima oara Lant1 <- Lant 2 si se monteaza disk-ul Read-Only pana la Lant 2 inclusiv. Se extrag toate datele pana in acest moment. Dupa aceasta se creaza lantul urmator :

Lant 1<-  Lant 2 <- Lant 4 <- Lant 5

Se monteaza Read-Only ultimul copil din Lant5 si asupra lui se ruleaza software de recuperare date. Fiserele noi create in cadrul Lant 4 si Lant 5 au sanse foarte mari de a fi recuperate complete. La fel, daca intre timp a avut loc vreo defragmentare exista sanse mari sa recuperam inclusiv o parte din fiserele din AVHDX_Lipsa.