IT-katastrofeberedskab: flowchart for disaster recovery

Sådan fungerer det

1. Omdøb banerne til de roller, I faktisk har

   Erstat overvågning / drift, DR-koordinator, ledelse, infrastrukturteam og systemejere med jeres rigtige roller: NOC eller overvågning, en it-beredskabsansvarlig, den vagthavende direktør på kriselisten, platform- og databaseteams, navngivne systemejere. Mindre organisationer lægger ofte koordinator- og infrastrukturbanen sammen; er der ingen i en bane, så slet den frem for at lade den stå ubemandet.

2. Skriv jeres aktiveringskriterier ind i beslutningen

   Gør 'Er kriterierne for DR-aktivering opfyldt?' objektiv nok til, at nogen kan anvende den under pres: primært site utilgængeligt, forventet nedetid længere end RTO for et tier 1-system, primær storage eller database kan ikke gendannes på stedet. Navngiv den rolle, der må aktivere, og en stedfortræder, og notér, hvordan de kontaktes uden for arbejdstid.

3. Kobl rigtige RTO- og RPO-tal på hvert system

   Tag målene fra konsekvensanalysen, ikke fra det, infrastrukturen aktuelt kan levere, og list dem i tiers ud for 'Prioritér systemer efter RTO og RPO'. Notér afhængighedsrækkefølgen såvel som prioritetsrækkefølgen — en tier 1-applikation kan ikke valideres, før identitets-, netværks- og databasetjenesterne under den er oppe.

4. Beskriv jeres faktiske genetableringsmekanisme

   'Failover til nødsite' betyder noget vidt forskelligt for replikeret infrastruktur, en warm standby, en anden cloud-region og en genopbygning fra backupmedier. Skriv mekanismen, linket til runbooken, hvor adgangskoder og break glass-konti ligger, og eventuelle manuelle DNS- eller netværksændringer ind i kassernes kommentarer, så diagrammet kan bruges under en genetablering og ikke kun i en evaluering.

5. Definér, hvad 'integritet verificeret' betyder, og hvem der siger det

   Fastlæg tjekkene bag 'Er dataintegriteten verificeret?': posttællinger, konsistens- og referencetjek, smoketest på applikationsniveau, sammenligning med sidst kendte gode tilstand. Beslut, hvad 'en ældre kopi' betyder, hvor mange gendannelsesforsøg I gør, før I eskalerer, og notér, at hvert skridt tilbage øger det datatab, I skal erklære over for RPO'en.

6. Tilføj failback, test derefter diagrammet, og gem versionen

   Bekræft, at failback-forløbet svarer til jeres måde at arbejde på: vindue, resynkronisering af data fra nødsitet, godkendelse i ændringsstyringen og det punkt, hvor DR formelt afblæses. Øv derefter diagrammet, sammenlign den opnåede genetableringstid og det opnåede datatab med jeres mål i evalueringen, og udgiv den godkendte version, så folk øver den revision, de også ville følge live.

Ofte stillede spørgsmål

Hvad er forskellen på disaster recovery og business continuity?

Business continuity handler om at holde organisationen i gang med at levere sine produkter og ydelser under en forstyrrelse, med de midler der er: manuelle nødløsninger, nødlokaler, omplacerede medarbejdere, reserveleverandører, kundekommunikation. Disaster recovery er it-delen af det: at genetablere de systemer, data og den infrastruktur, organisationen afhænger af. Kontinuitetsarbejdet sætter prioriteterne, fordi konsekvensanalysen afgør, hvilke aktiviteter der betyder mest, og hvor længe de kan være afbrudt; disaster recovery arver de tider som RTO- og RPO-mål og leverer op imod dem. En DR-plan uden input fra kontinuitetsarbejdet har det med at genetablere det, der er lettest at genetablere, først.

Hvad betyder RTO og RPO egentlig?

RTO, recovery time objective, er den måltid, inden for hvilken et system eller en service skal kunne bruges igen, målt fremad fra forstyrrelsen — ikke fra det øjeblik, nogen skriver under på en aktivering. RPO, recovery point objective, er det tidspunkt, data skal gendannes til, målt baglæns fra forstyrrelsen, og i praksis altså det maksimale datatab, organisationen vil acceptere. De to driver forskellige investeringer: RTO afhænger af, hvor hurtigt I kan få infrastrukturen op (standby-kapacitet, automatisering, øvelse), mens RPO er begrænset af, hvor ofte data kopieres væk — natlige backups kan ikke understøtte en RPO på under cirka et døgn, uanset hvor hurtigt gendannelsen kører. Begge begreber er defineret i beredskabsstandarder som ISO 22301.

Hvem bør godkende en DR-aktivering, og hvornår?

Aktiveringen bør ligge hos en rolle, der kan acceptere omkostningen og risikoen ved en failover — typisk en direktør eller kriselederen — med en navngiven stedfortræder og en dokumenteret vej uden for arbejdstid. Den er bevidst adskilt fra DR-koordinatorrollen i dette diagram: koordinatoren vurderer og indstiller, ledelsen godkender, og koordinatoren kører derefter genetableringen. Udløseren bør være skrevet på forhånd og kunne afprøves mod fakta, der findes tidligt i et nedbrud, for den dyre fejl er ikke at aktivere for tidligt; det er at bruge tre timer på at afgøre, om det her tæller, mens RTO-uret løber.

Hvad sker der, hvis de gendannede data fejler integritetstjekket?

Diagrammet løber i løkke i stedet for at presse videre: 'Er dataintegriteten verificeret?' sender fejlgrenen til 'Gendan fra en ældre kopi', som fører tilbage i gendannelsestrinnet, så verifikationen køres igen. Netop den løkke er dér, RPO'en bliver testet under virkelige forhold, for hvert skridt tilbage til en ældre kopi øger det datatab, I skal erklære — og på et tidspunkt er det ærlige svar, at målet ikke kan holdes, og at forretningen skal have at vide, hvilken periode den selv skal rekonstruere manuelt. Det er værd at aftale på forhånd, hvor mange forsøg I gør, hvem der må acceptere et gendannelsespunkt dårligere end RPO'en, og hvordan afvigelsen dokumenteres.

Hvor ofte bør disaster recovery-processen testes?

Ofte nok til, at planen afspejler det aktuelle miljø — og med resultaterne skrevet ned. De fleste organisationer kører en blanding: hyppige gendannelsestjek på backups, komponent- eller delvise failover-test i løbet af året og en større øvelse med fast interval, typisk årligt, hvor regulerede brancher og kritiske ydelser forventes at gøre mere. Vigtigere end intervallet er, hvad der testes. En gendannelse, der aldrig faktisk bliver monteret og læst, beviser ingenting, og en øvelse, der springer validering og failback over, skjuler netop de to problemer, der gør mest ondt i en rigtig hændelse: systemejere, der finder fejl, ingen havde forudset, og ingen aftalt vej tilbage til det primære site.