Copie de siguranță a containerului sau a fișierelor din el? Decideți după forma restaurării

Puteți face o copie de siguranță a unui container criptat ca un singur obiect sau îl puteți monta și copia fișierele din interior. Ambele trec prin VPN fără probleme, și acolo se termină asemănarea. Restaurează lucruri diferite, depind de chei diferite, costă cantități diferite de spațiu și eșuează în moduri diferite când cineva are nevoie de date înapoi. Alegeți mai întâi obiectul restaurării, apoi transportul, apoi criptarea copiei stocate. Lista de mai jos urmează această ordine, pentru că aproape orice dispută despre copii de siguranță este de fapt o neînțelegere despre care dintre cele trei decizii a fost luată prima.

Două obiecte, două forme de restaurare

O copie la nivel de imagine restaurează un container: recuperați volumul criptat și aveți în continuare nevoie de materialul său de restaurare pentru a-l deschide. O copie la nivel de fișiere restaurează fișiere și arbori de directoare, iar criptarea care le protejează este o proprietate a depozitului de copii, nu a containerului original. O copie simplă într-un director la distanță este un al treilea caz și moștenește protecția pe care acel director o are din întâmplare.

Rândul din mijloc este cel pe care oamenii îl citesc greșit. Poate fi un proiect foarte bun: programul de copiere citește text simplu local și scrie un depozit criptat și autentificat. Atunci securitatea se bazează pe acel program și pe credențialele lui, nu pe parola containerului original, iar cele două nu trebuie descrise ca și cum ar fi același control.

Verificarea 1: ce trebuie să reconstruiască restaurarea?

Puneți întrebarea sub forma unei restaurări, nu a unei copii. Dacă cerința este „readu acest serviciu pe alt host”, o imagine împreună cu materialul ei de restaurare este un răspuns coerent. Dacă cerința este „recuperează foaia de calcul financiară din martie”, restaurarea unei imagini de câțiva gigabaiți doar pentru a extrage un fișier este un răspuns costisitor. Ambele sunt restaurări legitime și nu sunt bugete interschimbabile. Un plan care numește doar una dintre ele va fi testat, mai devreme sau mai târziu, de cealaltă.

Scrieți ținta restaurării în plan: volumul întreg, un arbore de directoare sau fișiere individuale. Apoi notați ce metadate trebuie să călătorească împreună cu ele, pentru că proprietatea, permisiunile, atributele extinse și marcajele de timp fac parte dintr-o restaurare la nivel de fișiere și se pierd adesea în fluxurile de lucru bazate pe copiere care păreau suficiente la testare.

Decideți și cine efectuează restaurarea. Un depozit la nivel de fișiere pe care orice operator îl poate monta este un model de acces diferit de o imagine care cere prezența deținătorului cheii, și niciunul nu este automat mai bun. Important este ca alegerea să fie deliberată și scrisă.

Verificarea 2: ce protejează copia stocată?

VPN-ul protejează un segment de transport. Nu spune nimic despre copia stocată după ce transferul se termină, iar „a trecut prin tunel” nu este o afirmație despre capacitatea operatorului de copii de a vă citi datele. Dacă partea îndepărtată este operată de altcineva, întrebarea este ce pot citi ei, nu dacă legătura era criptată.

Pentru o imagine, asta înseamnă să protejați materialul cheii containerului separat de imaginea în sine. Pierderea antetului înseamnă pierderea volumului, așa că faceți copia antetului într-un loc în care imaginea nu este:

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

Pentru un depozit la nivel de fișiere, verificați dacă instrumentul criptează și autentifică conținutul și metadatele înainte ca acestea să părăsească hostul, și aflați cine deține cheile. documentația de proiectare Restic afirmă explicit că presupune un host sursă de încredere și că criptarea nu împiedică pe cineva cu acces la stocare să șteargă copiile. Ambele avertismente contează: un depozit poate fi confidențial și totuși distrus.

Verificarea 3: copia este consecventă?

O copie care surprinde un sistem de fișiere în schimbare este o copie, nu un punct de restaurare. Pentru o imagine, folosiți metoda acceptată a instrumentului de volume pentru un instantaneu stabil, ceea ce înseamnă de obicei o operațiune de instantaneu sau o demontare, nu citirea unui fișier mare în timp ce se schimbă:

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

Pentru fișiere montate, folosiți procedura de consecvență acceptată de aplicație pentru baze de date active și alte date coordonate. O copie la nivel de sistem de fișiere și un punct de restaurare consecvent cu aplicația sunt descrieri diferite, iar diferența devine vizibilă doar când încercați să porniți aplicația din copia restaurată.

Păstrați materialul de restaurare pe o rută protejată independentă. Pierderea mașinii originale nu trebuie să însemne niciodată și pierderea singurei credențiale care îi deschide copia, și exact asta se întâmplă când fișierul cu cheia locuiește pe volumul care este copiat. Testați această separare în mod deliberat: restaurați pe un host care nu a văzut niciodată originalul, folosind doar ce spune planul că este disponibil.

Verificarea 4: detectarea modificărilor se aplică acestui obiect?

Un container criptat arată pentru majoritatea instrumentelor de transfer ca un singur fișier mare și opac, așa că o mică modificare în text simplu poate provoca o recitire mare sau o reîncărcare completă, în funcție de instrument și format. Împărțirea în blocuri de dimensiune variabilă și deduplicarea, așa cum documentează restic, pot reduce asta, dar este o proprietate a acelui instrument și nu a containerelor criptate în general.

Măsurați în loc să presupuneți. Comparați o primă rulare cu una secundă după o modificare mică și inofensivă și notați octeții transferați, precum și timpul scurs. Păstrați o copie cunoscută ca bună în timp ce experimentați, ca un test să nu vă consume singurul punct de restaurare.

Apoi încheiați lista cu singurul test care contează: restaurarea fără mașina originală. Deschideți un container restaurat sau restaurați fișiere selectate împreună cu metadatele lor și confirmați că aplicația sau utilizatorul poate folosi rezultatul. Un transfer rapid și bine criptat care nu poate răspunde acelui test este o copie a datelor dumneavoastră, nu o copie de siguranță a lor.