Sikkerhetskopiere containeren eller filene i den? Velg etter gjenopprettingens form

Du kan sikkerhetskopiere en kryptert container som ett objekt, eller montere den og sikkerhetskopiere filene inni. Begge krysser VPN uten problemer, og der slutter likheten. De gjenoppretter ulike ting, avhenger av ulike nøkler, koster ulike mengder plass, og de feiler på ulike måter når noen trenger dataene tilbake. Velg gjenopprettingsobjektet først, deretter transporten, deretter krypteringen av den lagrede kopien. Sjekklisten nedenfor følger den rekkefølgen, fordi nesten hver sikkerhetskopitvist egentlig er uenighet om hvilken av de tre beslutningene som ble tatt først.

To objekter, to former for gjenoppretting

En avbildningsbasert sikkerhetskopi gjenoppretter en container: du får den krypterte volumnen tilbake og trenger fortsatt gjenopprettingsmaterialet for å åpne den. En filbasert sikkerhetskopi gjenoppretter filer og katalogtrær, og krypteringen som beskytter dem er en egenskap ved sikkerhetskopilageret og ikke ved den opprinnelige containeren. En vanlig kopi til en ekstern mappe er et tredje tilfelle, og den arver den beskyttelsen som mappen tilfeldigvis har.

Den midterste raden er den folk leser feil. Den kan være en helt god løsning: sikkerhetskopiprogrammet leser klartekst lokalt og skriver et kryptert, autentisert lager. Sikkerheten hviler da på det programmet og dets påloggingsinformasjon, ikke på passordet til den opprinnelige containeren, og de to bør ikke beskrives som om de var samme kontroll.

Sjekk 1: hva må gjenopprettingen gjenoppbygge?

Still spørsmålet i form av en gjenoppretting, ikke en sikkerhetskopi. Hvis kravet er «få denne tjenesten tilbake på en annen vert», er et avtrykk med gjenopprettingsmaterialet et sammenhengende svar. Hvis kravet er «få regnearket med økonomi tilbake fra mars», er det dyrt å gjenopprette et avtrykk på flere gigabyte bare for å hente ut én fil. Begge er legitime gjenopprettinger, og de er ikke utskiftbare budsjetter. En plan som bare nevner én av dem, vil før eller siden bli testet av den andre.

Skriv gjenopprettingsmålet inn i planen: hele volumnen, et katalogtre eller enkeltfiler. Noter deretter hvilke metadata som må reise med dem, fordi eierskap, rettigheter, utvidede attributter og tidsstempler er en del av en filbasert gjenoppretting og går ofte tapt i kopibaserte arbeidsflyter som virket tilstrekkelige under testing.

Bestem også hvem som utfører gjenopprettingen. Et filbasert lager som enhver operatør kan montere, er en annen tilgangsmodell enn et avtrykk som krever at nøkkelinnehaveren er til stede, og ingen av dem er automatisk bedre. Det viktige er at valget er bevisst og skrevet ned.

Sjekk 2: hva beskytter den lagrede kopien?

VPN beskytter et transportavsnitt. Det sier ingenting om den lagrede kopien når overføringen er ferdig, og «det gikk gjennom tunnelen» er ikke en påstand om sikkerhetskopioperatørens evne til å lese dataene dine. Hvis fjernsiden drives av noen andre, er spørsmålet hva de kan lese, ikke om forbindelsen var kryptert.

For et avtrykk betyr det å beskytte containerens nøkkelmateriale atskilt fra selve avtrykket. Mister du hodet, mister du volumnen, så ta sikkerhetskopi av hodet et sted der avtrykket ikke er:

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

For et filbasert lager, kontroller at verktøyet krypterer og autentiserer innhold og metadata før de forlater verten, og finn ut hvem som har nøklene. Restics designdokumentasjon er tydelig på at den forutsetter en klarert kildevert og at kryptering ikke hindrer noen med lagringstilgang i å slette sikkerhetskopier. Begge forbeholdene er viktige: et lager kan være fortrolig og likevel bli ødelagt.

Sjekk 3: er kopien konsistent?

En sikkerhetskopi som fanger et filsystem i endring, er en kopi, ikke et gjenopprettingspunkt. For et avtrykk, bruk volumverktøyets støttede metode for et stabilt øyeblikksbilde, som vanligvis betyr en øyeblikksbildeoperasjon eller en avmontering i stedet for å lese en stor fil mens den endres:

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

For monterte filer, bruk applikasjonens støttede konsistensprosedyre for aktive databaser og andre koordinerte data. En kopi på filsystemnivå og et applikasjonskonsistent gjenopprettingspunkt er ulike beskrivelser, og forskjellen blir først synlig når du prøver å starte applikasjonen fra den gjenopprettede kopien.

Hold gjenopprettingsmaterialet på en uavhengig beskyttet rute. Å miste den opprinnelige maskinen skal aldri også miste den eneste påloggingsinformasjonen som åpner sikkerhetskopien, og det er nettopp det som skjer når nøkkelfilen bor på volumnen som sikkerhetskopieres. Test den adskillelsen bevisst: gjenopprett på en vert som aldri har sett originalen, med bare det planen sier er tilgjengelig.

Sjekk 4: gjelder endringsdeteksjon for dette objektet?

En kryptert container ser ut som én stor ugjennomsiktig fil for de fleste overføringsverktøy, så en liten klartekstendring kan føre til en stor ny lesing eller en full ny opplasting avhengig av verktøyet og formatet. Oppdeling i blokker med variabel størrelse og deduplisering, som restic dokumenterer, kan redusere det, men det er en egenskap ved det verktøyet og ikke ved krypterte containere generelt.

Mål i stedet for å anta. Sammenlign en første kjøring med en andre etter en liten, uskadelig endring, og noter overførte byte samt medgått tid. Bevar en kjent god sikkerhetskopi mens du eksperimenterer, slik at en test ikke bruker opp det eneste gjenopprettingspunktet ditt.

Avslutt deretter sjekklisten med den eneste testen som teller: gjenoppretting uten den opprinnelige maskinen. Åpne en gjenopprettet container, eller gjenopprett utvalgte filer med metadataene deres, og bekreft at applikasjonen eller brukeren kan bruke resultatet. En rask, godt kryptert overføring som ikke kan svare på den testen, er en kopi av dataene dine, ikke en sikkerhetskopi av dem.