Säkerhetskopiera containern eller filerna i den? Välj efter återställningens form

Du kan säkerhetskopiera en krypterad container som ett objekt, eller montera den och säkerhetskopiera filerna inuti. Båda passerar VPN utan problem, och där slutar likheten. De återställer olika saker, de bygger på olika nycklar, de kostar olika mycket plats och de misslyckas på olika sätt när någon behöver data tillbaka. Välj återställningsobjektet först, sedan transporten, sedan krypteringen av den lagrade kopian. Checklistan nedan följer den ordningen, eftersom nästan varje säkerhetskopietvist egentligen är oenighet om vilket av de tre besluten som togs först.

Två objekt, två former av återställning

En avbildningsbaserad säkerhetskopia återställer en container: du får tillbaka den krypterade volymen och behöver fortfarande dess återställningsmaterial för att öppna den. En filbaserad säkerhetskopia återställer filer och katalogträd, och den kryptering som skyddar dem är en egenskap hos säkerhetskopielagret och inte hos den ursprungliga containern. En vanlig kopia till en fjärrmapp är ett tredje fall, och den ärver det skydd som mappen råkar ha.

Den mellersta raden är den folk läser fel. Den kan vara en helt bra lösning: säkerhetskopieringsprogrammet läser klartext lokalt och skriver ett krypterat, autentiserat lager. Säkerheten vilar då på det programmet och dess inloggningsuppgifter, inte på den ursprungliga containerns lösenord, och de två bör inte beskrivas som om de vore samma kontroll.

Kontroll 1: vad måste återställningen bygga upp igen?

Ställ frågan i form av en återställning, inte en säkerhetskopia. Om kravet är ”få tillbaka den här tjänsten på en annan värd” är en avbildning med sitt återställningsmaterial ett sammanhängande svar. Om kravet är ”få tillbaka kalkylarket med ekonomi från mars” är det dyrt att återställa en avbildning på flera gigabyte bara för att plocka ut en fil. Båda är legitima återställningar och de är inte utbytbara budgetar. En plan som bara nämner en av dem kommer förr eller senare att prövas av den andra.

Skriv in återställningsmålet i planen: hela volymen, ett katalogträd eller enskilda filer. Notera sedan vilka metadata som måste följa med, eftersom ägarskap, behörigheter, utökade attribut och tidsstämplar är en del av en filbaserad återställning och ofta går förlorade i kopieringsbaserade arbetsflöden som verkade tillräckliga vid test.

Bestäm också vem som utför återställningen. Ett filbaserat lager som vilken operatör som helst kan montera är en annan åtkomstmodell än en avbildning som kräver att nyckelhavaren är närvarande, och inget av dem är automatiskt bättre. Det viktiga är att valet är medvetet och nedskrivet.

Kontroll 2: vad skyddar den lagrade kopian?

VPN skyddar ett transportavsnitt. Det säger ingenting om den lagrade kopian när överföringen är klar, och ”det gick genom tunneln” är inte ett påstående om säkerhetskopieringsoperatörens förmåga att läsa dina data. Om fjärrsidan drivs av någon annan är frågan vad de kan läsa, inte om förbindelsen var krypterad.

För en avbildning betyder det att skydda containerns nyckelmaterial separat från själva avbildningen. Förlorar du huvudet förlorar du volymen, så säkerhetskopiera huvudet någonstans där avbildningen inte finns:

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

För ett filbaserat lager, kontrollera att verktyget krypterar och autentiserar innehåll och metadata innan de lämnar värden, och ta reda på vem som har nycklarna. Restics designdokumentation är tydlig med att den förutsätter en betrodd källvärd och att kryptering inte hindrar någon med lagringsåtkomst från att radera säkerhetskopior. Båda förbehållen spelar roll: ett lager kan vara konfidentiellt och ändå förstöras.

Kontroll 3: är kopian konsistent?

En säkerhetskopia som fångar ett filsystem under förändring är en kopia, inte en återställningspunkt. För en avbildning, använd volymverktygets metod som stöds för en stabil ögonblicksbild, vilket oftast betyder en ögonblicksbildsoperation eller en avmontering i stället för att läsa en stor fil medan den ändras:

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

För monterade filer, använd programmets metod för konsistens som stöds för aktiva databaser och andra koordinerade data. En kopia på filsystemsnivå och en programkonsistent återställningspunkt är olika beskrivningar, och skillnaden blir synlig först när du försöker starta programmet från den återställda kopian.

Håll återställningsmaterialet på en oberoende skyddad väg. Att förlora den ursprungliga maskinen ska aldrig också innebära att den enda inloggningsuppgiften som öppnar dess säkerhetskopia förloras, och det är precis vad som händer när nyckelfilen bor på volymen som säkerhetskopieras. Testa den separationen medvetet: återställ på en värd som aldrig har sett originalet, med bara det som planen anger är tillgängligt.

Kontroll 4: gäller ändringsdetektering för det här objektet?

En krypterad container ser ut som en enda stor ogenomskinlig fil för de flesta överföringsverktyg, så en liten klartextändring kan leda till en stor omläsning eller en fullständig ny uppladdning beroende på verktyget och formatet. Uppdelning i block med variabel storlek och deduplicering, som restic dokumenterar, kan minska det, men det är en egenskap hos det verktyget och inte hos krypterade containrar i allmänhet.

Mät i stället för att anta. Jämför en första körning med en andra efter en liten, ofarlig ändring, och notera överförda byte samt förfluten tid. Behåll en känd bra säkerhetskopia medan du experimenterar, så att ett test inte förbrukar din enda återställningspunkt.

Avsluta sedan checklistan med det enda test som räknas: återställning utan den ursprungliga maskinen. Öppna en återställd container, eller återställ utvalda filer med deras metadata, och bekräfta att programmet eller användaren kan använda resultatet. En snabb, välkrypterad överföring som inte kan svara på det testet är en kopia av dina data, inte en säkerhetskopia av dem.