Disaster recovery, backups, RTO/RPO, failover og frem for alt det spørgsmål, som mange virksomheder først stiller sig selv efter et nedbrud: kan vi virkelig gendanne systemet og komme tilbage til arbejdet?
Servernedbrud. Beskadiget database. Fejl efter udrulning. Ransomware. Problemer hos infrastrukturleverandøren. Utilsigtet sletning af data. Nedbrud i en hel region.
Der er mange scenarier. Problemet er, at de fleste virksomheder først og fremmest forbereder sig på, at et nedbrud slet ikke sker.
Og langt sjældnere forbereder de sig på den situation, hvor det alligevel sker.
Det er netop området disaster recovery.
Og her opstår det grundlæggende spørgsmål: hvis din applikation holder op med at virke i dag kl. 14:00, hvor lang tid har du så brug for til at starte den op igen, og hvor meget data kan du miste undervejs?
Hvis svaret er „vi har en backup”, så er det endnu ikke et svar på det spørgsmål.
Backup er ikke disaster recovery
Backup er en kopi af data. Disaster recovery er processen med at genoprette systemets drift.
Det er en meget vigtig forskel.
Du kan få taget databasen backuppet hver dag og stadig ikke vide:
-
om den seneste kopi er korrekt,
-
om den kan gendannes,
-
hvor lang tid gendannelsen tager,
-
om databasen efter gendannelsen vil fungere sammen med den aktuelle version af applikationen,
-
om du også gendanner systemkonfigurationen,
-
om du har alle nøgler, certifikater og hemmeligheder, der er nødvendige for at starte miljøet,
-
om den infrastruktur, der er nødvendig for at starte applikationen, stadig er tilgængelig,
-
hvem der skal udføre de enkelte trin,
-
om hele processen holder sig inden for den forretningsmæssigt acceptable tid.
NIST peger direkte på behovet for at teste gendannelse af sikkerhedskopier, og de aktuelle AWS-retningslinjer behandler også periodiske recovery-tests som en måde at kontrollere, om en backup faktisk gør det muligt at opnå de fastsatte RTO og RPO.
Derfor er backup et element i recovery-strategien, ikke dens fulde ækvivalent.
Det vigtigste spørgsmål: hvad sker der efter et nedbrud?
Lad os forestille os en webbutik.
Kl. 10:17 holder databasen op med at svare.
Applikationsserveren kører stadig, men brugerne kan ikke logge ind. Ordrer virker ikke. Adminpanelet svarer ikke længere. Betalingssystemet modtager ikke korrekte oplysninger.
Teamet undersøger situationen.
Det viser sig, at den seneste backup af databasen blev taget kl. 8:00.
Teoretisk kan dataene gendannes.
Men så opstår de næste spørgsmål;
- Ved man, hvor kopien er?
- Ved man, hvordan den skal gendannes?
- Er den person, der kan gøre det, tilgængelig?
- Er backupen komplet?
- Passer applikationskonfigurationen til den version, der er gemt i kopien?
- Vil databasen fungere med den aktuelle applikation efter gendannelsen?
- Og det vigtigste: hvor lang tid tager det at få butikken i drift igen?
Hvis ingen har testet det før, kan svaret være en overraskelse.
RTO - hvor meget nedetid kan vi acceptere?
RTO, altså Recovery Time Objective, angiver den maksimalt acceptable tid til at gendanne systemet efter et nedbrud.
Eksempelvis betyder RTO = 4 timer, at organisationen forudsætter, at systemet kan gendannes og være i drift igen inden for højst fire timer.
Det betyder dog ikke, at alle applikationer bør have et RTO på fire timer.
For et internt system, der bruges et par gange om dagen, kan en sådan tid være acceptabel. For en salgsplatform, der kører 24/7, kan det betyde meget alvorlige tab.
RTO bør derfor komme fra forretningen og ikke fra det, infrastrukturen aktuelt tilbyder.
NIST definerer RTO som den tid, et system kan forblive i gendannelsesfasen, før det påvirker organisationens drift negativt.
RPO - hvor meget data kan vi miste?
Den anden grundlæggende parameter er RPO, altså Recovery Point Objective.
RPO besvarer spørgsmålet: hvor langt tilbage kan vi rulle data tilbage efter et nedbrud?
Eksempel: RPO = 1 time betyder, at organisationen accepterer et potentielt datatab på maksimalt omkring en time.
Hvis systemet bryder sammen kl. 15:00, og den seneste brugbare backup er fra kl. 14:00, er det netop et scenarie, der passer til det fastsatte RPO. Men hvis der kun tages backup én gang om dagen, er det svært at forvente et RPO på én time.
RPO påvirker derfor direkte måden, sikkerhedskopier tages på, datagengivelse og design af infrastrukturen.
RTO fortæller os først og fremmest hvor længe vi kan være utilgængelige.
RPO fortæller hvor meget data vi kan miste.
Disse to parametre bør fastsættes sammen med forretningen, fordi opnåelsen af dem er forbundet med omkostninger og tekniske løsninger. Microsoft understreger også, at RTO og RPO bør udspringe af reelle forretningskrav og ikke af den abstrakte antagelse „nul nedetid og intet datatab”.
Backup kan eksistere og stadig være ubrugelig
Det er en af de farligste myter i IT.
„Backup udføres korrekt” betyder ikke automatisk: „systemet kan gendannes fra den”.
En kopi kan være ufuldstændig. Den kan være beskadiget. Den kan indeholde data, som ikke kan bruges korrekt. Den kan være lavet på en måde, der ikke gør det muligt at gendanne hele miljøet.
Derfor skal backup testes ved faktisk gendannelse.
Det er ikke nok at kontrollere, om filen eksisterer.
Den skal gendannes.
Systemet skal startes.
Dataene skal kontrolleres.
Afhængighederne skal verificeres.
Konfigurationen skal kontrolleres.
Tiden skal måles.
Og der skal svares på, om resultatet svarer til RTO- og RPO-forudsætningerne.
AWS peger som en typisk fejl netop på at gendanne en backup uden at kontrollere, om den gendannede ressource faktisk virker, og om de gendannede data kan bruges.
Failover - når vi ikke vil vente på gendannelse
Ikke alle applikationer kan tillade sig at vente flere timer på gendannelse. I sådanne tilfælde bruges blandt andet failover-mekanismer.
Failover betyder at skifte driften fra det primære miljø til et forberedt backupmiljø.
Det kan være:
-
en backupserver,
-
en anden tilgængelighedszone,
-
en anden region,
-
en databasekopi,
-
et standby-miljø,
-
en alternativ infrastruktur klar til at blive startet.
I den enkleste model kører applikationen ét sted, og ved nedbrud starter vi et reserve- miljø. I mere avancerede løsninger kører en del af infrastrukturen parallelt og er klar til at overtage trafikken.
Der findes dog ikke én strategi, der passer til alle.
Backup og gendannelse er som regel billigere, men kan betyde længere gendannelsestid. Løsninger som warm standby eller aktiv redundans kan reducere recovery betydeligt, men kræver større investeringer og mere kompleks infrastruktur.
Failover skal også testes
Her opstår endnu et problem.
Virksomheden kan have et reserve- miljø, men har ikke brugt det i to år;
- Virker det stadig?
- Matcher konfigurationen produktionen?
- Har den tilstrækkelig ydeevne?
- Er alle tjenester tilgængelige?
- Er certifikaterne aktuelle?
- Vil DNS skifte korrekt over?
- Vil applikationen forbinde til databasen?
- Vil autorisationsmekanismen virke?
- Ved teamet, præcis hvad de skal gøre?
Kun testen kan besvare disse spørgsmål.
AWS anbefaler regelmæssig test af failover netop for at verificere gendannelsesforløbet og kontrollere, om de faktiske RTO og RPO stemmer overens med forudsætningerne.
Et disaster recovery-miljø, som aldrig er blevet testet, er kun delvist andet end en antagelse.
Disaster recovery er ikke kun infrastruktur
Det er let kun at se på DR gennem servernes prisme.
Det er en fejl.
Recovery omfatter også:
- Data
Er alle vigtige data beskyttet? - Applikationen
Har vi den rigtige kodeversion og mulighed for at udrulle den? - Konfigurationen
Ved vi, hvilke indstillinger der er nødvendige for at starte systemet? - Hemmelige oplysninger og certifikater
Har vi sikker adgang til nøgler, tokens og certifikater? - Eksterne afhængigheder
Hvad sker der, hvis et eksternt betalingssystem, API, identitetsudbyder eller SaaS-tjeneste bliver utilgængelig? - Infrastrukturen
Har vi et sted, hvor applikationen kan køre? - Mennesker
Er det klart, hvem der træffer beslutningen om at iværksætte proceduren? - Procedurerne
Findes der en konkret runbook, eller baserer recovery sig på én persons viden?
Det sidste er særligt vigtigt.
Hvis kun én administrator ved, hvordan systemet skal gendannes, har vi endnu ikke en robust procedure. Vi har en afhængighed af et bestemt menneske.
Det værste tidspunkt at skrive en recovery-procedure
Det er, når systemet allerede ikke virker.
Så opstår tidspres, stress, opkald fra kunder og spørgsmål fra ledelsen.
Derfor bør proceduren være forberedt på forhånd.
Den bør blandt andet definere:
-
hvornår vi iværksætter disaster recovery,
-
hvem der træffer beslutningen,
-
hvilke systemer der har højeste prioritet,
-
hvor backupperne ligger,
-
hvordan de gendannes,
-
hvilke afhængigheder der skal startes,
-
hvordan failover ser ud,
-
hvordan korrekt funktion verificeres,
-
hvordan nedbruddet kommunikeres,
-
hvornår failback kan påbegyndes,
-
hvem der godkender tilbagevenden til primærmiljøet.
Ved et alvorligt nedbrud bør der ikke være plads til spørgsmålet: „Hvad gør vi nu?”
Proceduren bør have besvaret det på forhånd.
DR bør testes som en applikationsfunktion
En god tilgang er at behandle recovery på samme måde som softwaretests. Det er ikke nok at forberede en procedure én gang.
Systemet ændrer sig.
Databasen vokser.
Afhængighederne ændrer sig.
Der kommer ny infrastruktur til.
Applikationsversionerne ændrer sig.
Der opstår nye integrationer.
Rettighederne ændrer sig.
Derfor kræver recovery-strategien også løbende kontrol.
Testen kan begynde med et simpelt scenarie: „Databasen er gået tabt. Lad os gendanne den fra den seneste kopi.”
Senere kan man gå videre til mere komplekse scenarier:
- „Applikationsserveren virker ikke.”
- „Hele produktionsmiljøet er utilgængeligt.”
- „Data er blevet krypteret.”
- „Den primære infrastrukturregion virker ikke.”
- „Vi har ikke adgang til hovedadministratorens konto.”
Hver sådan test kan afsløre problemer, som ikke er synlige under normal drift af systemet.
Har hver applikation brug for avanceret disaster recovery?
Nej.
Og det er også vigtigt.
At designe en infrastruktur, der er robust over for ethvert tænkeligt scenarie, kan være uforholdsmæssigt dyrt.
Hvis et nedbrud i en intern applikation kun kan betyde en times ulejlighed, har vi ikke nødvendigvis brug for active-active-infrastruktur i flere regioner. Hvis et systemnedbrud derimod betyder, at salg, produktion, kundeservice eller en kritisk forretningsproces stopper, ser situationen helt anderledes ud.
Først skal man fastlægge nedbruddets betydning for forretningen.
Først derefter skal teknologien vælges.
Det kan føre til forskellige løsninger:
Backup + gendannelse
En enklere og billigere løsning til systemer med lavere kritikalitet.
Warm standby
Reserve- miljøet er delvist forberedt og kan hurtigt startes.
Hot standby
Reserve- miljøet kører i højere grad parallelt og er klar til at overtage belastningen.
Active-active
To miljøer kan samtidig håndtere trafikken og dermed reducere afhængigheden af et enkelt fejlpunkt.
Valget af løsning bør afhænge af RTO, RPO, systemets kritikalitet, nedetidsomkostninger og de tekniske muligheder.
Tjekliste: Er din applikation klar til nedbrud?
Det er værd at besvare nogle enkle spørgsmål.
1. Har vi backup?
Det er kun begyndelsen.
2. Opbevares backupen på en måde, der også beskytter den mod nedbrud i produktionsmiljøet?
3. Har vi nogensinde foretaget en fuld gendannelse?
4. Hvor lang tid tager restore faktisk?
5. Kender vi RTO?
6. Kender vi RPO?
7. Kan vi gendanne ikke kun data, men også applikationen og dens konfiguration?
8. Har vi en recovery-procedure?
9. Er der mere end én person, der kan udføre den?
10. Har vi testet failover?
11. Er reserve- miljøet opdateret?
12. Har vi testet recovery igen efter de seneste ændringer i systemet?
Hvis vi på flere spørgsmål svarer „jeg ved ikke”, er det et rigtig godt tidspunkt at se nærmere på disaster recovery-strategien.
Den vigtigste test lyder: „Vis det“
I IT er det meget let at sige:
- „Vi har en backup.”
- „Vi har en reserve-server.”
- „Vi har en procedure.”
- „Vi har disaster recovery.”
- Men systemets sikkerhed bør ikke udelukkende bygge på erklæringer.
Det vigtigste spørgsmål er: Vis, at du kan genskabe det.
- Start restore.
- Mål tiden.
- Tjek dataene.
- Test applikationen.
- Gennemfør failover.
- Tjek proceduren.
- Gentag testen efter væsentlige ændringer.
Først da kan man sige, at recovery-strategien er blevet afprøvet i praksis.
Backup beskytter data. Recovery genopretter forretningen
Det er nok den vigtigste forskel.
Backup besvarer spørgsmålet: „Har vi en kopi?”
Disaster recovery besvarer et langt sværere spørgsmål: „Kan vi vende tilbage til drift efter et nedbrud?”
Og mellem de to findes hele gendannelsesarkitekturen: RPO, RTO, replikering, backups, restore, failover, konfiguration, procedurer, ansvar og regelmæssige tests.
Et godt designet system går ikke ud fra, at et nedbrud aldrig vil ske. Det går ud fra, at et nedbrud før eller siden vil ske, og at man skal vide, hvad man skal gøre.
For ægte robusthed i en applikation handler ikke om, at den aldrig går i stykker. Den handler om, at når noget går galt, kan organisationen vende tilbage til drift på en forudsigelig, kontrolleret og forretningsmæssigt forsvarlig måde.
Ordliste
Disaster Recovery (DR) - en strategi og procedurer, der gør det muligt at genoprette driften af systemer efter et alvorligt nedbrud.
Backup - en kopi af data beregnet til senere gendannelse.
Restore - processen med at gendanne data eller et system fra en kopi.
RTO (Recovery Time Objective) - den maksimalt acceptable tid til at gendanne et system.
RPO (Recovery Point Objective) - det maksimalt acceptable datatab udtrykt i tid.
Failover - skift af systemdrift fra det primære miljø til et backupmiljø.
Failback - tilbagevenden af driften til det primære miljø efter årsagen til nedbruddet er fjernet.
Recovery test - en test, der skal bekræfte, at systemet faktisk kan gendannes i overensstemmelse med de vedtagne forudsætninger.
Runbook - en detaljeret instruks for, hvordan man handler i et bestemt nedbrudsscenarie.
