Backup som går att återställa

Alla som har arbetat med backup har sett det: en konsol full av gröna bockar, och sedan dagen då något faktiskt ska återställas och det inte går. Kanske saknas en disk i jobbet. Kanske är databasen inkonsistent. Kanske tar återställningen tolv timmar när verksamheten räknade med en.

En backup är inte målet. Målet är att kunna återställa. Det låter som en ordlek, men det ändrar vad man mäter och vad man testar.

Börja i andra änden: vad ska tillbaka, och hur snabbt?

Innan man pratar om programvara och lagring behöver man två svar per system:

• Hur mycket data får vi förlora? (RPO) En natts data? En timmes? Ingenting?
• Hur länge får systemet vara nere? (RTO) En arbetsdag? En timme?

Svaren kommer inte från IT. De kommer från de som äger systemen och verksamheten. När jag har gjort det här arbetet har det ofta visat sig att en enhetlig standardpolicy skyddar vissa system för mycket och andra för lite. Att sätta sig ner med applikationsägarna och gå igenom systemen ett i taget är tråkigt, men det är där skyddsnivån blir rätt.

Applikationsmedveten backup för det som har tillstånd

En virtuell maskin med en databas kan inte bara fotograferas i farten och förväntas fungera efter återställning. Databasen behöver veta att backupen görs, så att den hamnar i ett konsistent läge och så att loggkedjan hanteras rätt. För SQL Server innebär det applikationsmedveten backup, och i kluster med tillgänglighetsgrupper behöver man också kontrollera att backupen inte bryter loggkedjan för den ordinarie databasbackupen.

Det går att kontrollera. Databasens egen historik visar vilka backuper som gjorts och om de är markerade som kopior. Jag litar inte på att det står rätt i backupkonsolen; jag kontrollerar det i databasen.

Gör backupen oföränderlig

Utpressningsprogram letar efter backuper först. Om en angripare med administratörsbehörighet kan radera dem är de inte värda mycket. Därför bör minst en kopia ligga på lagring där den inte kan ändras eller raderas under en bestämd tid, inte ens av en administratör:

• Ett härdat Linux-repository med oföränderliga filer, utan SSH och med minimal åtkomst.
• Objektlagring med objektlås.
• En kopia utanför platsen, i ett annat datacenter eller hos en annan leverantör.

Den gamla 3-2-1-regeln gäller fortfarande: tre kopior, två olika medier, en utanför platsen. I dag lägger man till en etta och en nolla: en kopia som är oföränderlig eller frånkopplad, och noll fel vid kontrollen.

Lagringen under backupen spelar roll

Backupprogram arbetar med stora block och snabba kloner av befintliga data. Om filsystemet under repositoryt är formaterat med fel klusterstorlek kan det fungera i månader, för att sedan ge fel eller dålig prestanda när volymerna växer. Det är ett exempel på ett fel som inte syns i den dagliga statusen, men som avgör om återställningen fungerar den dag den behövs. Kontrollera rekommendationerna från leverantören när repositoryt skapas, och dokumentera hur det är gjort.

Testa återställningen, på riktigt

Det enda sättet att veta om en backup fungerar är att återställa den. Det behöver inte vara dramatiskt:

• Regelbundet och automatiskt: låt backupsystemet starta upp maskiner i ett isolerat nät och kontrollera att de svarar.
• Manuellt, några gånger per år: återställ ett helt system, till exempel en testmiljö för ett produktionssystem, och mät tiden. Stämmer den med det verksamheten räknar med?
• Enskilda filer: det vanligaste återställningsfallet. Testa det också.

Efter ett större test skriver jag en runbook och en kort testrapport. Runbooken är för den som ska göra det nästa gång, kanske mitt i natten. Rapporten visar vad som tog tid och vad som behöver ändras.

Glöm inte nycklarna

Krypterad backup är rätt. Men om krypteringsnyckeln, lösenordet till backupprogrammet eller inloggningen till lagringen bara finns på servern som brann upp, är backupen oläslig. Var ligger lösenorden? Vem kommer åt dem? Har någon provat att återställa från noll, på en ny maskin, med bara det som finns i lösenordshanteraren?