Sikkerhedskopi af containeren eller dens filer? Vælg efter gendannelsens form

Du kan tage sikkerhedskopi af en krypteret container som ét objekt, eller montere den og kopiere filerne indeni. Begge krydser VPN uden problemer, og det er der, ligheden slutter. De gendanner forskellige ting, de afhænger af forskellige nøgler, de koster forskellige mængder plads, og de fejler på forskellige måder, når nogen får brug for dataene tilbage. Vælg gendannelsesobjektet først, derefter transporten, derefter krypteringen af den lagrede kopi. Tjeklisten nedenfor følger den rækkefølge, fordi næsten enhver backupstrid i virkeligheden er uenighed om, hvilken af de tre beslutninger der blev taget først.

To objekter, to gendannelsesformer

En billedbackup gendanner en container: du får den krypterede volumen tilbage og har stadig brug for dens gendannelsesmateriale for at åbne den. En filbaseret backup gendanner filer og mappetræer, og den kryptering, der beskytter dem, er en egenskab ved backup-lageret frem for ved den oprindelige container. En almindelig kopi til en fjernmappe er et tredje tilfælde, og den arver den beskyttelse, som mappen tilfældigvis har.

Den midterste række er den, folk læser forkert. Det kan være et helt godt design: backup-programmet læser klartekst lokalt og skriver et krypteret, autentificeret lager. Sikkerheden hviler så på programmet og dets legitimationsoplysninger, ikke på den oprindelige containers adgangskode, og de to bør ikke beskrives, som om de var samme kontrol.

Kontrol 1: hvad skal gendannelsen rekonstruere?

Stil spørgsmålet i form af en gendannelse, ikke en backup. Hvis kravet er “bring denne tjeneste tilbage på en anden vært”, er et billede plus dets gendannelsesmateriale et sammenhængende svar. Hvis kravet er “få regnearket med økonomi tilbage fra marts”, er det dyrt at gendanne et billede på flere gigabyte for at udtrække én fil. Begge er legitime gendannelser, og de er ikke udskiftelige budgetter. En plan, der kun nævner én af dem, vil før eller siden blive testet af den anden.

Skriv gendannelsesmålet ind i planen: hele volumen, et mappetræ eller enkelte filer. Notér derefter, hvilke metadata der skal rejse med dem, fordi ejerskab, rettigheder, udvidede attributter og tidsstempler er en del af en filbaseret gendannelse og ofte tabes i kopibaserede arbejdsgange, som så tilstrækkelige ud under test.

Beslut også, hvem der udfører gendannelsen. Et filbaseret lager, som enhver operatør kan montere, er en anden adgangsmodel end et billede, der kræver nøgleindehaverens tilstedeværelse, og ingen af dem er automatisk bedre. Det vigtige er, at valget er bevidst og skrevet ned.

Kontrol 2: hvad beskytter den lagrede kopi?

VPN'en beskytter et transportafsnit. Den siger intet om den lagrede kopi, når overførslen er slut, og “det gik gennem tunnelen” er ikke en udtalelse om backup-operatørens evne til at læse dine data. Hvis fjernsiden drives af en anden, er spørgsmålet, hvad de kan læse, ikke om forbindelsen var krypteret.

For et billede betyder det at beskytte containerens nøglemateriale adskilt fra selve billedet. Mister du headeren, mister du volumen, så tag backup af headeren et sted, hvor billedet ikke er:

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

For et filbaseret lager skal du kontrollere, at værktøjet krypterer og autentificerer indhold og metadata, før de forlader værten, og finde ud af, hvem der har nøglerne. Restics designdokumentation er tydelig om, at den forudsætter en betroet kildevært, og at kryptering ikke forhindrer nogen med lageradgang i at slette backups. Begge forbehold er vigtige: et lager kan være fortroligt og alligevel blive ødelagt.

Kontrol 3: er kopien konsistent?

En backup, der fanger et filsystem under ændring, er en kopi, ikke et gendannelsespunkt. For et billede skal du bruge volumen-værktøjets understøttede metode til et stabilt snapshot, hvilket normalt betyder en snapshot-operation eller en afmontering i stedet for at læse en stor fil, mens den ændrer sig:

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

For monterede filer skal du bruge applikationens understøttede konsistensprocedure til aktive databaser og andre koordinerede data. En kopi på filsystemniveau og et applikationskonsistent gendannelsespunkt er forskellige beskrivelser, og forskellen bliver først synlig, når du forsøger at starte applikationen fra den gendannede kopi.

Hold gendannelsesmaterialet på en uafhængig beskyttet rute. At miste den oprindelige maskine bør aldrig også miste den eneste legitimationsoplysning, der åbner dens backup, og det er præcis, hvad der sker, når nøglefilen ligger på den volumen, der sikkerhedskopieres. Test den adskillelse bevidst: gendan på en vært, der aldrig har set originalen, og brug kun det, planen siger er tilgængeligt.

Kontrol 4: gælder ændringsdetektion for dette objekt?

En krypteret container ligner én stor uigennemsigtig fil for de fleste overførselsværktøjer, så en lille klartekstændring kan føre til en stor genlæsning eller en fuld genoploadning afhængigt af værktøjet og formatet. Opdeling i blokke med variabel størrelse og deduplikering, som restic dokumenterer, kan reducere det, men det er en egenskab ved det værktøj og ikke ved krypterede containere generelt.

Mål i stedet for at antage. Sammenlign en første kørsel med en anden efter en lille, uskadelig ændring, og notér overførte bytes samt forløbet tid. Bevar en kendt god backup, mens du eksperimenterer, så en test ikke bruger dit eneste gendannelsespunkt.

Afslut derefter tjeklisten med den eneste test, der tæller: gendan uden den oprindelige maskine. Åbn en gendannet container eller gendan udvalgte filer med deres metadata, og bekræft, at applikationen eller brugeren kan bruge resultatet. En hurtig, godt krypteret overførsel, der ikke kan svare på den test, er en kopi af dine data, ikke en backup af dem.