Disaster Recovery i molnet: RTO/RPO-design och automatiserade failover-tester

Disaster recovery är ett område där många bolag tror att de är skyddade ända tills den dag det inte stämmer. Det finns en backup-rutin, en bock i en ruta och en känsla av trygghet. Sedan inträffar något - en region går ner, data raderas, ett ransomware-angrepp - och det visar sig att ingen någonsin testat att faktiskt återställa. Min hållning är att DR handlar mindre om teknik och mer om realism och bevis. Här är hur jag bygger det i molnet.

RTO och RPO: börja med kraven

All DR-design börjar med två tal. RTO, recovery time objective, är hur länge ett system får vara nere innan det måste vara tillbaka. RPO, recovery point objective, är hur mycket data du har råd att förlora mätt i tid. Ett system med RPO på en timme får tappa som mest en timmes data. De här talen styr allt annat, och de ska sättas av verksamheten, inte av tekniken. Ett krav på noll nere och noll dataförlust är möjligt men dyrt, och få system behöver det när man räknar på vad ett avbrott faktiskt kostar.

Olika system förtjänar olika skydd

Det dyraste misstaget är att behandla allt likadant. Att ge varje system samma höga skyddsnivå som det mest kritiska slösar pengar, och att ge det kritiska samma låga nivå som resten är farligt. Jag klassar systemen och matchar strategi mot behov:

• Backup och återställning - billigast, längst RTO. Passar mindre kritiskt.
• Pilot light - en minimal kopia redo att skalas upp.
• Varm standby - en mindre version som körs parallellt.
• Aktiv-aktiv - full drift på flera platser, kortast RTO, dyrast.

Backup som tål angrepp

En backup räcker inte om den kan raderas tillsammans med originalet. Moderna hot, särskilt ransomware, riktar in sig på just backuper. Därför vill jag ha kopior som är oföränderliga och åtskilda - i ett separat konto eller en separat region, med skrivskydd som inte ens en administratör kan kringgå under angreppets gång. Den gamla principen om flera kopior på skilda platser gäller fortfarande, översatt till molnet.

Det avgörande ordet är oföränderlig. Vid ett ransomware-angrepp har angriparen ofta haft åtkomst i veckor och hunnit leta upp och kryptera eller radera de vanliga backuperna innan de slår till på riktigt. En backup som ligger i samma konto med samma behörigheter ger då falsk trygghet. En oföränderlig kopia, skrivskyddad under en bestämd tid och åtskild från produktionskontot, är det som faktiskt står kvar när allt annat är förlorat. Det är skillnaden mellan att betala en lösensumma och att återställa från en kopia du vet att ingen kunnat röra.

Det avgörande: automatisera failover-testerna

Här är hela poängen. En backup eller failover du aldrig testat är inte en plan, det är en förhoppning. Och ett test som körs manuellt en gång om året blir lätt bortprioriterat. Därför automatiserar jag failover-testerna så att de körs regelbundet utan att någon behöver komma ihåg. Ett automatiserat test stänger av en region eller återställer ett system i en isolerad miljö och mäter den faktiska tiden mot RTO-målet. Nästan varje test avslöjar något - en saknad behörighet, ett beroende ingen tänkte på, en process som tar dubbelt så lång tid som antaget.

Geografisk spridning efter behov

Molnregioner går ner, om än sällan. Hur mycket geografisk spridning du behöver beror på dina RTO- och RPO-krav. För kritiska system replikerar jag data till en annan region och har en plan för att starta där. För mindre kritiska kan en backup som kan återställas i en annan region räcka. Spridningen ska matcha kraven - inte vara maximal för allt, vilket bara blir dyrt. Hur det här ser ut konkret för en e-handlare har jag skrivit om i min genomgång av multi-region failover.

Det är frestande att lösa osäkerhet med maximal spridning, men full replikering över flera regioner för allt är dyrt och komplext, och det mesta behöver det inte. Genom att klassa systemen och bara ge de mest kritiska den dyraste nivån håller du både kostnaden och komplexiteten nere där det går. Ett internt rapportverktyg som tål en dags återställning behöver inte samma skydd som orderflödet. Den disciplinen - rätt nivå till rätt system - är vad som skiljer en genomtänkt DR-strategi från en både dyr och ändå otestad ambition.

Vanliga misstag

• RTO och RPO satta av tekniken i stället för verksamheten.
• Samma skyddsnivå för alla system, oavsett kritikalitet.
• Backuper som kan raderas tillsammans med originalet.
• Failover-tester som körs manuellt eller inte alls.

Vill du ha hjälp att bygga en DR som faktiskt håller kan du läsa om min molninfrastruktur.

Relaterat

• GCP för dataintensiva svenska bolag: BigQuery + Vertex + Looker
• Migrera från on-prem till Azure på 90 dagar: Spelboken
• FinOps på AWS: 23 tactics som halverar molnfakturan

Vill du ta det vidare?

Vill ni veta att er disaster recovery faktiskt håller, inte bara på papperet, hjälper jag er - med strategi och automatiserade tester. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.