Sikkerheitskopiere containeren eller filene i han? Vel etter forma på gjenopprettinga

Du kan sikkerheitskopiere ein kryptert container som eitt objekt, eller montere han og sikkerheitskopiere filene inni. Begge kryssar VPN utan problem, og der sluttar likskapen. Dei gjenopprettar ulike ting, er avhengige av ulike nøklar, kostar ulike mengder plass, og dei feilar på ulike måtar når nokon treng dataa tilbake. Vel gjenopprettingsobjektet først, deretter transporten, deretter krypteringa av den lagra kopien. Sjekklista nedanfor følgjer den rekkjefølgja, fordi nesten kvar sikkerheitskopitvist eigentleg er usemje om kva av dei tre avgjerdene som vart teken først.

To objekt, to former for gjenoppretting

Ein avbildningsbasert sikkerheitskopi gjenopprettar ein container: du får den krypterte volumnen tilbake og treng framleis gjenopprettingsmaterialet for å opne han. Ein filbasert sikkerheitskopi gjenopprettar filer og katalogtre, og krypteringa som vernar dei er ein eigenskap ved sikkerheitskopilageret og ikkje ved den opphavlege containeren. Ein vanleg kopi til ei ekstern mappe er eit tredje tilfelle, og han arvar den vernen som mappa tilfeldigvis har.

Den midtre rada er den folk les feil. Han kan vere ei heilt god løysing: sikkerheitskopiprogrammet les klartekst lokalt og skriv eit kryptert, autentisert lager. Tryggleiken kviler då på det programmet og påloggingsinformasjonen hans, ikkje på passordet til den opphavlege containeren, og dei to bør ikkje skildrast som om dei var same kontroll.

Sjekk 1: kva må gjenopprettinga byggje opp att?

Still spørsmålet i form av ei gjenoppretting, ikkje ein sikkerheitskopi. Viss kravet er «få denne tenesta tilbake på ein annan vert», er eit avtrykk med gjenopprettingsmaterialet eit samanhengande svar. Viss kravet er «få reknearket med økonomi tilbake frå mars», er det dyrt å gjenopprette eit avtrykk på fleire gigabyte berre for å hente ut éi fil. Begge er legitime gjenopprettingar, og dei er ikkje utskiftbare budsjett. Ein plan som berre nemner éin av dei, vil før eller seinare bli testa av den andre.

Skriv gjenopprettingsmålet inn i planen: heile volumnen, eit katalogtre eller enkeltfiler. Noter deretter kva metadata som må reise med dei, fordi eigarskap, rettar, utvida attributt og tidsstempel er ein del av ei filbasert gjenoppretting og går ofte tapt i kopibaserte arbeidsflytar som verka tilstrekkelege under testing.

Avgjer òg kven som utfører gjenopprettinga. Eit filbasert lager som kvar operatør kan montere, er ein annan tilgangsmodell enn eit avtrykk som krev at nøkkelinnehavaren er til stades, og ingen av dei er automatisk betre. Det viktige er at valet er medvite og skrive ned.

Sjekk 2: kva vernar den lagra kopien?

VPN vernar eit transportavsnitt. Det seier ingenting om den lagra kopien når overføringa er ferdig, og «det gjekk gjennom tunnelen» er ikkje ein påstand om sikkerheitskopioperatøren si evne til å lese dataa dine. Viss fjernsida blir driven av nokon andre, er spørsmålet kva dei kan lese, ikkje om sambandet var kryptert.

For eit avtrykk tyder det å verne nøkkelmaterialet til containeren skilt frå sjølve avtrykket. Mister du hovudet, mister du volumnen, så ta sikkerheitskopi av hovudet på ein stad der avtrykket ikkje er:

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

For eit filbasert lager, kontroller at verktøyet krypterer og autentiserer innhald og metadata før dei forlèt verten, og finn ut kven som har nøklane. Restics designdokumentasjon er tydeleg på at den føreset ein klarert kjeldevert og at kryptering ikkje hindrar nokon med lagringstilgang i å slette sikkerheitskopiar. Begge atterhalda er viktige: eit lager kan vere fortruleg og likevel bli øydelagt.

Sjekk 3: er kopien konsistent?

Ein sikkerheitskopi som fangar eit filsystem i endring, er ein kopi, ikkje eit gjenopprettingspunkt. For eit avtrykk, bruk den støtta metoden til volumverktøyet for eit stabilt augneblinksbilete, som vanlegvis tyder ein augneblinksbileteoperasjon eller ein avmontering i staden for å lese ei stor fil medan ho endrar seg:

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

For monterte filer, bruk den støtta konsistensprosedyren til applikasjonen for aktive databasar og andre koordinerte data. Ein kopi på filsystemnivå og eit applikasjonskonsistent gjenopprettingspunkt er ulike skildringar, og skilnaden blir først synleg når du prøver å starte applikasjonen frå den gjenoppretta kopien.

Hald gjenopprettingsmaterialet på ei uavhengig verna rute. Å miste den opphavlege maskinen skal aldri òg miste den einaste påloggingsinformasjonen som opnar sikkerheitskopien, og det er nettopp det som skjer når nøkkelfila bur på volumnen som blir sikkerheitskopiert. Test den skiljinga medvite: gjenopprett på ein vert som aldri har sett originalen, med berre det planen seier er tilgjengeleg.

Sjekk 4: gjeld endringsdeteksjon for dette objektet?

Ein kryptert container ser ut som éi stor ugjennomsiktig fil for dei fleste overføringsverktøy, så ei lita klartekstendring kan føre til ei stor ny lesing eller ei full ny opplasting avhengig av verktøyet og formatet. Oppdeling i blokker med variabel storleik og deduplisering, som restic dokumenterer, kan redusere det, men det er ein eigenskap ved det verktøyet og ikkje ved krypterte containarar generelt.

Mål i staden for å gå ut frå. Samanlikn ein første køyring med ein andre etter ei lita, uskadeleg endring, og noter overførte byte samt medgått tid. Ta vare på ein kjend god sikkerheitskopi medan du eksperimenterer, slik at ein test ikkje brukar opp det einaste gjenopprettingspunktet ditt.

Avslutt deretter sjekklista med den einaste testen som tel: gjenoppretting utan den opphavlege maskinen. Opne ein gjenoppretta container, eller gjenopprett utvalde filer med metadataa deira, og stadfest at applikasjonen eller brukaren kan bruke resultatet. Ei rask, godt kryptert overføring som ikkje kan svare på den testen, er ein kopi av dataa dine, ikkje ein sikkerheitskopi av dei.