Disaster recovery, backuper, RTO/RPO, failover och framför allt den fråga som många företag ställer sig först efter ett avbrott: kan vi verkligen återställa systemet och komma tillbaka till arbetet?
Serverfel. Skadad databas. Fel efter driftsättning. Ransomware. Problem hos infrastrukturleverantören. Oavsiktlig radering av data. Avbrott i en hel region.
Scenarierna är många. Problemet är att de flesta företag främst förbereder sig för att avbrottet inte ska inträffa.
Och betydligt mer sällan förbereder man sig på situationen där det faktiskt inträffar.
Det är just detta som är området disaster recovery.
Och här uppstår den grundläggande frågan: om din applikation slutar fungera idag klockan 14:00, hur lång tid behöver du för att starta den igen och hur mycket data kan du förlora under tiden?
Om svaret är ”vi har backup”, så är det ännu inte ett svar på den frågan.
Backup är inte disaster recovery
Backup är en kopia av data. Disaster recovery är processen för att återställa systemets drift.
Det är en mycket viktig skillnad.
Du kan ha dagliga kopior av databasen och ändå inte veta:
-
om den senaste kopian är korrekt,
-
om den går att återställa,
-
hur lång tid återställningen tar,
-
om databasen efter återställningen fungerar med den aktuella versionen av applikationen,
-
om du också återställer systemkonfigurationen,
-
om du har alla nycklar, certifikat och hemligheter som behövs för att starta miljön,
-
om infrastrukturen som krävs för att starta applikationen fortfarande är tillgänglig,
-
vem som ska utföra de enskilda stegen,
-
om hela processen ryms inom den tid som är affärsmässigt acceptabel.
NIST pekar uttryckligen på behovet av att testa återställning från kopior, och de aktuella AWS-riktlinjerna behandlar också regelbundna recovery-tester som ett sätt att kontrollera om backupen faktiskt gör det möjligt att uppnå de antagna RTO- och RPO-målen.
Därför är backup en del av recovery-strategin, inte dess fullständiga motsvarighet.
Den viktigaste frågan: vad händer efter ett avbrott?
Låt oss föreställa oss en webbutik.
Klockan 10:17 slutar databasen att svara.
Applikationsservern fortsätter att fungera, men användarna kan inte logga in. Beställningar fungerar inte. Administrationspanelen slutar svara. Betalningssystemet får inte korrekt information.
Teamet kontrollerar situationen.
Det visar sig att den senaste backupen av databasen gjordes klockan 8:00.
I teorin går det att återställa data.
Men då uppstår nästa frågor;
- Vet man var kopian finns?
- Vet man hur den ska återställas?
- Är personen som kan göra det tillgänglig?
- Är backupen komplett?
- Matchar applikationens konfiguration den version som finns sparad i kopian?
- Kommer databasen att fungera med den aktuella applikationen efter återställningen?
- Och viktigast av allt: hur lång tid tar det att återställa butikens drift?
Om ingen tidigare har kontrollerat detta kan svaret bli en överraskning.
RTO - hur mycket stillestånd kan vi acceptera?
RTO, alltså Recovery Time Objective, anger den maximalt acceptabla tiden för att återställa systemet efter ett avbrott.
Exempelvis betyder RTO = 4 timmar att organisationen utgår från att systemets drift kan återställas inom högst fyra timmar.
Det betyder dock inte att varje applikation borde ha ett RTO på fyra timmar.
För ett internt system som används några gånger om dagen kan en sådan tid vara acceptabel. För en försäljningsplattform som körs dygnet runt kan det innebära mycket stora förluster.
RTO bör därför utgå från verksamheten, inte från vad infrastrukturen för närvarande erbjuder.
NIST definierar RTO som den tid under vilken systemet kan befinna sig i återställningsfasen innan det påverkar organisationens verksamhet negativt.
RPO - hur mycket data kan vi förlora?
Den andra grundläggande parametern är RPO, alltså Recovery Point Objective.
RPO svarar på frågan: hur långt tillbaka i tiden kan vi gå med data efter ett avbrott?
Exempel: RPO = 1 timme betyder att organisationen accepterar en potentiell förlust på maximalt omkring en timmes data.
Om systemet slutar fungera klockan 15:00 och den senaste användbara kopian är från 14:00, är det just ett sådant scenario som ryms inom det antagna RPO:t. Men om backupen körs en gång per dygn är det svårt att förvänta sig ett RPO på en timme.
RPO påverkar alltså direkt hur kopior görs, hur data replikeras och hur infrastrukturen utformas.
RTO berättar främst hur länge vi kan vara otillgängliga.
RPO berättar hur mycket data vi kan förlora.
Dessa två parametrar bör fastställas tillsammans med verksamheten, eftersom uppnåendet av dem hänger ihop med kostnader och tekniska lösningar. Microsoft betonar också att RTO och RPO bör utgå från verkliga affärskrav, inte från det abstrakta antagandet om ”noll stillestånd och noll dataförlust”.
Backup kan finnas och ändå vara oanvändbar
Det här är en av de farligaste myterna inom IT.
”Backupen körs korrekt” betyder inte automatiskt: ”systemet kan återställas från den”.
Kopian kan vara ofullständig. Den kan vara skadad. Den kan innehålla data som inte går att använda korrekt. Den kan vara skapad på ett sätt som inte gör det möjligt att återställa hela miljön.
Därför måste backup testas genom faktisk återställning.
Det räcker inte att kontrollera om filen finns.
Den måste återställas.
Systemet måste startas.
Data måste kontrolleras.
Beroenden måste verifieras.
Konfigurationen måste kontrolleras.
Tiden måste mätas.
Och frågan måste besvaras om resultatet motsvarar RTO- och RPO-kraven.
AWS pekar som ett typiskt misstag just på att återställa en backup utan att kontrollera om den återställda resursen faktiskt fungerar och om de återvunna uppgifterna kan användas.
Failover - när vi inte vill vänta på återställning
Alla applikationer kan inte tillåta sig att vänta flera timmar på återställning. I sådana fall används bland annat failover-mekanismer.
Failover innebär att driften växlas från den primära miljön till en förberedd reservmiljö.
Det kan vara:
-
en reservserver,
-
en andra tillgänglighetszon,
-
en andra region,
-
en databasreplik,
-
en standby-miljö,
-
en alternativ infrastruktur redo att startas.
I den enklaste modellen körs applikationen på en plats, och vid ett fel startar vi upp en reservmiljö. I mer avancerade lösningar körs en del av infrastrukturen parallellt och är förberedd för att ta över trafiken.
Det finns dock ingen enda strategi som passar alla.
Backup och restore är vanligtvis billigare, men kan innebära längre återställningstid. Lösningar som warm standby eller aktiv redundans kan avsevärt korta ner återställningen, men kräver större investeringar och en mer komplex infrastruktur.
Failover måste också testas
Här uppstår ett annat problem.
Företaget kan ha en reservmiljö, men har inte använt den på två år;
- Fungerar den fortfarande?
- Stämmer konfigurationen överens med produktionen?
- Har den tillräcklig prestanda?
- Är alla tjänster tillgängliga?
- Är certifikaten aktuella?
- Kommer DNS att växla över korrekt?
- Kommer applikationen att ansluta till databasen?
- Kommer auktoriseringsmekanismen att fungera?
- Vet teamet exakt vad det ska göra?
Först testet ger svar på dessa frågor.
AWS rekommenderar regelbunden testning av failover just för att verifiera återställningsvägen och kontrollera om de faktiska RTO- och RPO-värdena stämmer överens med antagandena.
En disaster recovery-miljö som aldrig har testats är bara delvis mer än ett antagande.
Disaster recovery handlar inte bara om infrastruktur
Det är lätt att se på DR enbart genom servrarnas prisma.
Det är fel.
Återställning omfattar också:
- Data
Är alla viktiga data skyddade? - Applikationen
Har vi rätt version av koden och möjlighet att driftsätta den? - Konfigurationen
Vet vi vilka inställningar som krävs för att starta systemet? - Hemligheter och certifikat
Har vi säker åtkomst till nycklar, tokens och certifikat? - Externa beroenden
Vad händer om ett externt betalningssystem, ett API, en identitetsleverantör eller en SaaS-tjänst blir otillgänglig? - Infrastrukturen
Har vi en plats där applikationen kan köras? - Människorna
Vet man vem som fattar beslutet att starta proceduren? - Procedurerna
Finns det en konkret runbook, eller bygger återställningen på en persons kunskap?
Det sistnämnda är särskilt viktigt.
Om bara en administratör vet hur systemet ska återställas har vi ännu ingen robust procedur. Vi har en beroendeställning till en specifik person.
Den värsta tidpunkten att skriva en återställningsprocedur
Det är när systemet redan inte fungerar.
Då uppstår tidspress, stress, samtal från kunder och frågor från ledningen.
Därför bör proceduren förberedas i förväg.
Den bör bland annat ange:
-
när vi startar disaster recovery,
-
vem som fattar beslutet,
-
vilka system som har högst prioritet,
-
var säkerhetskopiorna finns,
-
hur de återställs,
-
vilka beroenden som måste startas,
-
hur failover ser ut,
-
hur man verifierar att allt fungerar korrekt,
-
hur avbrottet kommuniceras,
-
när failback kan påbörjas,
-
vem som godkänner återgången till primärmiljön.
Vid ett allvarligt fel bör det inte finnas utrymme för frågan: "Vad gör vi nu?"
Proceduren bör ha besvarat det i förväg.
DR bör testas som en applikationsfunktion
Ett bra angreppssätt är att behandla återställning ungefär som mjukvarutestning. Det räcker inte att skapa en procedur en gång.
Systemet förändras.
Databasen växer.
Beroenden förändras.
Ny infrastruktur tillkommer.
Applikationsversioner ändras.
Nya integrationer dyker upp.
Behörigheter förändras.
Därför kräver även återställningsstrategin kontinuerlig kontroll.
Testet kan börja med ett enkelt scenario: "Databasen har gått förlorad. Låt oss återställa den från den senaste kopian."
Sedan kan man gå vidare till mer komplexa scenarier:
- "Applikationsservern fungerar inte."
- "Hela produktionsmiljön är otillgänglig."
- "Data har krypterats."
- "Den primära infrastrukturnoden fungerar inte."
- "Vi har inte tillgång till huvudadministratören."
Varje sådant test kan avslöja problem som inte syns under normal drift av systemet.
Behöver varje applikation avancerad disaster recovery?
Nej.
Och det är också viktigt.
Att designa en infrastruktur som klarar varje tänkbart scenario kan bli oproportionerligt dyrt.
Om ett fel i en intern applikation bara innebär en timmes besvär, behöver vi inte nödvändigtvis en active-active-infrastruktur i flera regioner. Men om ett fel i systemet innebär att försäljning, produktion, kundtjänst eller en kritisk affärsprocess stoppas, ser situationen helt annorlunda ut.
Först måste man fastställa hur ett avbrott påverkar verksamheten.
Först därefter ska tekniken väljas.
Det kan leda till olika lösningar:
Backup + restore
En enklare och billigare lösning för mindre kritiska system.
Warm standby
Reservmiljön är delvis förberedd och kan snabbt startas upp.
Hot standby
Reservmiljön körs i större utsträckning parallellt och är redo att ta över belastningen.
Active-active
Två miljöer kan samtidigt hantera trafik, vilket minskar beroendet av en enskild felkälla.
Valet av lösning bör utgå från RTO, RPO, systemets kritikalitet, kostnaden för avbrott och de tekniska möjligheterna.
Checklista: är din applikation redo för ett avbrott?
Det är värt att svara på några enkla frågor.
1. Har vi backup?
Det är bara början.
2. Förvaras backupen på ett sätt som också skyddar den från fel i produktionsmiljön?
3. Har vi någonsin genomfört en fullständig återställning?
4. Hur lång tid tar restore faktiskt?
5. Känner vi till RTO?
6. Känner vi till RPO?
7. Kan vi återställa inte bara data, utan också applikationen och dess konfiguration?
8. Har vi en återställningsprocedur?
9. Kan fler än en person utföra den?
10. Har vi testat failover?
11. Är reservmiljön uppdaterad?
12. Har vi efter de senaste ändringarna i systemet testat återställningen på nytt?
Om vi svarar "jag vet inte" på flera frågor är det ett mycket bra tillfälle att se över strategin för disaster recovery.
Den viktigaste testet är: ”Visa”
Inom IT är det väldigt lätt att säga:
- ”Vi har en backup.”
- ”Vi har en reservserver.”
- ”Vi har en procedur.”
- ”Vi har disaster recovery.”
- Men systemets säkerhet bör inte enbart bygga på deklarationer.
Den viktigaste frågan är: Visa att du kan återskapa det.
- Kör restore.
- Mät tiden.
- Kontrollera data.
- Testa applikationen.
- Genomför failover.
- Kontrollera proceduren.
- Upprepa testet efter betydande ändringar.
Först då kan man säga att recovery-strategin har testats i praktiken.
Backup skyddar data. Recovery återställer verksamheten
Det är nog den viktigaste skillnaden.
Backup svarar på frågan: ”Har vi en kopia?”
Disaster recovery svarar på en mycket svårare fråga: ”Kan vi återgå till drift efter ett haveri?”
Och mellan det ena och det andra finns hela återställningsarkitekturen: RPO, RTO, replikering, backups, restore, failover, konfiguration, procedurer, ansvar och regelbundna tester.
Ett väl utformat system utgår inte från att ett avbrott aldrig kommer att inträffa. Det utgår från att ett avbrott någon gång kommer att inträffa och att man då måste veta vad man ska göra.
För verklig applikationsresiliens handlar inte om att den aldrig går sönder. Den handlar om att organisationen, när något går fel, kan återgå till drift på ett förutsägbart, kontrollerat sätt och i linje med verksamhetens krav.
Ordlista
Disaster Recovery (DR) - strategi och procedurer som gör det möjligt att återställa systemens drift efter ett allvarligt fel.
Backup - en kopia av data avsedd för senare återställning.
Restore - processen att återställa data eller ett system från en kopia.
RTO (Recovery Time Objective) - den maximalt acceptabla tiden för att återställa systemet.
RPO (Recovery Point Objective) - den maximalt acceptabla dataförlusten uttryckt i tid.
Failover - att växla systemets drift från den primära miljön till en reservmiljö.
Failback - att återföra driften till den primära miljön efter att orsaken till felet har åtgärdats.
Recovery test - ett test som ska bekräfta att systemet faktiskt kan återställas enligt de antagna förutsättningarna.
Runbook - en detaljerad instruktion för hur man ska agera i ett visst felscenario.
