Disaster recovery: Backup, restore-test og RTO/RPO

Kort svar: Test en brugbar gendannelse

Et grønt backupjob viser, at kopieringen er gennemført. En restore-test skal vise, om de valgte data kan gendannes og bruges, hvem der gør arbejdet, og hvor der mangler noget i planen.

For et website omfatter det typisk filer, database, konfiguration og afhængigheder. Aftal både en teknisk kontrol og en forretningskontrol: Kan den ansvarlige faktisk udføre den opgave, sitet er til for?

Har I brug for hjælp til at afklare workload, test og ansvar, beskriver ALCOs backup- og gendannelsesydelse den eksisterende service. Guiden her giver en testmodel; den dokumenterer ikke en gennemført kundetest eller en lovet gendannelsestid.

RPO og RTO: mål for datatab og tid

RPO (Recovery Point Objective) er målet for, hvor langt tilbage det seneste brugbare gendannelsespunkt må ligge i forhold til hændelsen. Et mål på fire timer kræver, at den valgte historik kan understøtte det.
RTO (Recovery Time Objective) er målet for, hvor længe forretningen kan undvære systemet. Tiden til at få adgang, vælge en kopi og kontrollere resultatet skal også passe ind i planen.

Målene fastlægges pr. system. En hurtig filrestore beviser ikke, at hele websitets drift kan genetableres lige så hurtigt.

Før testen: aftal omfang og et sikkert testmiljø

Vælg ét konkret scenarie, eksempelvis at et website og dets database skal genetableres efter en fejl. Beskriv, hvad testen skal bevise, og hvad den ikke omfatter.

Udpeg ansvarlige. Hvem godkender testen, udfører den, kontrollerer forretningsfunktionen og lukker testmiljøet bagefter?
Vælg data og gendannelsespunkt. Notér de berørte filer, databaser, versioner og afhængigheder. Kontrollér, at nødvendige adgange og nøgler findes hos de rette ansvarlige.
Adskil testen fra produktion. Aftal testadresse, adgang og håndtering af data. Stop eller afskær mails, betalinger, planlagte jobs og integrationer, som ellers kan påvirke rigtige brugere eller systemer.
Skriv acceptkriterier før start. Eksempelvis at en ansvarlig kan logge ind, åbne en bestemt side, hente en fil og kontrollere et udvalgt dataudsnit.

En aftalt øvelse i et isoleret miljø er noget andet end en restore direkte oven i produktion. Ved en virkelig hændelse skal gendannelsespunkt og fremgangsmåde vurderes ud fra hændelsen; følg den aftalte beredskabs- og ansvarsmodel.

Gennemfør testen og registrér hele forløbet

Start registreringen, når det aftalte testscenarie begynder. Notér ventetid og manuelle trin, ikke kun tiden hvor backupværktøjet flytter data.

Kontrollér, at det valgte gendannelsespunkt er tilgængeligt, og registrér dets tidspunkt.
Gendan de aftalte dele i testmiljøet. Notér fejl, manglende afhængigheder og nødvendige manuelle rettelser.
Udfør de tekniske og forretningsmæssige acceptkontroller. En login-side alene er ikke bevis for, at funktionerne virker.
Registrér, hvornår systemet er godkendt til den aftalte anvendelse. Sammenhold resultatet med målene, og giv afvigelser en ansvarlig og næste handling.
Luk testmiljøet, når resultaterne er bevaret efter aftale. Aftal oprydning af eventuelle kopier og midlertidige adgange.

Skabelon til jeres restore-test

Brug felterne som udgangspunkt for en testjournal. Tilpas dem til systemet; opbevar selve journalen i jeres godkendte driftsdokumentation frem for på en offentlig side.

Felt	Det skal I registrere
System og scenarie	Hvilket website eller system testes, og hvilken fejl skal øvelsen efterligne?
Omfang og afhængigheder	Filer, database, konfiguration og eksterne funktioner, der indgår eller er udeladt
Ansvar og godkendelse	Testansvarlig, teknisk udførende og den, der godkender forretningsfunktionen
Mål og tidspunkter	Aftalt RPO/RTO, simuleret hændelsestid, gendannelsespunkt, teststart og godkendt afslutning
Resultat af kontroller	Hvad virker, hvad fejler, og hvilken dokumentation understøtter det?
Afvigelser og næste skridt	Mangler, ansvarlig, aftalt opfølgning og behov for en ny test
Oprydning	Hvem lukker testmiljø, data og midlertidige adgange efter aftale?

Illustrativt eksempel: kopieringstid er ikke hele gendannelsestiden

Alle tider nedenfor er opdigtede for at vise beregningen. De er ikke et ALCO-kunderesultat, et benchmark eller en SLA. Eksemplet bruger samme dag og tidszone, et RPO-mål på fire timer og et RTO-mål på fire timer.

Tidspunkt	Hændelse i eksemplet
08.00	Tidspunktet for det seneste valgte, brugbare gendannelsespunkt
10.30	Den simulerede hændelse begynder; systemet regnes som utilgængeligt
11.00	Adgang og valg af kopi er afklaret; selve restore startes
13.20	Data er gendannet, men funktioner og afhængigheder mangler stadig kontrol
14.10	Den ansvarlige godkender den aftalte funktion efter kontrollen

Muligt datatab i eksemplet er 2 timer og 30 minutter, fra 08.00 til 10.30. Den samlede gendannelsestid er 3 timer og 40 minutter, fra 10.30 til 14.10. Begge ligger inden for eksemplets firetimersmål.

Hvis man kun rapporterede kopieringstiden fra 11.00 til 13.20, ville man overse adgangsafklaring og validering. En øvelse med små datamængder eller allerede tilgængelige medarbejdere kan heller ikke uden videre forudsige en virkelig hændelse.

Hvor ofte skal restore testes?

Vælg interval efter kritikalitet, ændringer og krav. Planlæg også en ny vurdering efter større ændringer i platform, database, integrationer, backupmodel eller ansvarlige. Aftal, hvem der følger op, hvis testen ikke når målene.

Et snapshot kan være et nyttigt gendannelsespunkt, men siger ikke alene noget om adskillelse, adgang, bevaret historik eller en fungerende restore. Undersøg, hvilke fejl der kan ramme både produktion og kopier.

Kilder og næste skridt

NCSC anbefaler regelmæssig backup og kontrol af, at data kan gendannes; CISA anbefaler at teste backupprocedurer og beskytte kopier mod ransomware. Testjournalen og tidslinjen ovenfor er guidens egne illustrative beslutningshjælpemidler.

Vil I afklare, hvad der skal testes i jeres miljø, så se ALCOs backup og gendannelse. Tag de vigtigste systemer, nuværende backup og seneste kendte test med til samtalen. Kontakt ALCO er også en mulighed.