En vellykket sikkerhetskopi viser at data er kopiert. Den viser ikke alene at virksomheten kan gjenopprette filer, tjenester og normal drift innenfor tiden den har til rådighet.
Derfor bør backup vurderes som en del av beredskapen, ikke bare som lagring. En gjenopprettingstest kan avdekke manglende tilganger, avhengigheter, dokumentasjon og kapasitet før en reell hendelse gjør feilene kostbare.
Kunnskapsrom har tidligere forklart 3-2-1-regelen for sikkerhetskopiering og hvordan virksomheter kan redusere risikoen ved løsepengevirus. Denne artikkelen handler om neste spørsmål: Hvordan kontrollerer man at tilbakeveien faktisk virker?
Start med det virksomheten må få tilbake
Backupdiskusjoner begynner ofte med lagringssted, intervall, oppbevaringstid og leverandør. Det er viktige valg, men beredskapsplanlegging bør også ta utgangspunkt i virksomhetens kritiske leveranser.
NISTs veiledning for beredskapsplanlegging anbefaler å vurdere informasjonssystemer og drift for å fastsette krav og prioriteringer. I praksis betyr det at virksomheten bør kunne svare på følgende:
- Hvilke tjenester og data må gjenopprettes først?
- Hvor lenge kan hver tjeneste være utilgjengelig?
- Hvor mye nytt eller endret innhold kan gå tapt uten uakseptabel konsekvens?
- Hvem kan beslutte og gjennomføre en gjenoppretting?
- Hvilke tekniske og organisatoriske avhengigheter må være tilgjengelige?
Dette flytter oppmerksomheten fra om en backupjobb er markert som vellykket, til om virksomheten kan gjenoppta arbeidet på en kontrollert måte.
Tre nivåer for praktisk testing
Modellen nedenfor er en praktisk arbeidsmodell for mindre virksomheter, ikke en formell standard. Den deler testingen i filtest, tjenestetest og driftstest. Hvert nivå undersøker mer av den samlede gjenopprettingsevnen.
1. Filtest
En filtest kontrollerer om én konkret fil, mappe, e-post eller dokumentversjon kan hentes tilbake. Testen bør bruke ufarlige testdata og gjennomføres uten å overskrive produksjonsdata.
Registrer blant annet:
- hvor lang tid det tar å finne riktig gjenopprettingspunkt
- om filnavn, versjoner og tidsstempler er forståelige
- om den ansvarlige faktisk har nødvendige tilganger
- om innhold, metadata og rettigheter er riktige etterpå
En filtest gir begrenset sikkerhet, men er en enkel måte å kontrollere at backupen kan brukes til det vanligste gjenopprettingsbehovet.
2. Tjenestetest
En tjenestetest omfatter en hel arbeidsflate eller teknisk tjeneste. Det kan være en bruker i Microsoft 365, et delt filområde, en database, en virtuell server eller et nettsted.
Her må virksomheten kontrollere mer enn selve datakopien. Tjenesten kan være avhengig av identitet, DNS, sertifikater, lisenser, integrasjoner, konfigurasjon og riktig rekkefølge ved oppstart. Testmiljøet bør være isolert slik at gjenopprettingen ikke skader eller forveksles med produksjon.
Resultatet bør dokumentere om tjenesten startet, om dataene kunne brukes, hvilke avhengigheter som manglet og hvor lang tid hele prosessen tok.
3. Driftstest
En driftstest undersøker hele kjeden fra avbrudd til gjenopptatt arbeid. Den kan gjennomføres som en teknisk øvelse, en bordøvelse eller en kombinasjon.
Testen bør avklare:
- hvordan hendelsen oppdages og klassifiseres
- hvem som beslutter at gjenoppretting skal starte
- hvilken rekkefølge systemene må gjenopprettes i
- hvordan brukere, ledelse og berørte parter varsles
- hvor dokumentasjonen finnes dersom primærsystemet er utilgjengelig
- hvordan virksomheten bekrefter at normal drift faktisk er gjenopptatt
Denne testen viser om backup, ansvar, kommunikasjon og tekniske avhengigheter fungerer som én samlet beredskapsevne.
RTO og RPO må knyttes til konsekvens
To begreper brukes ofte for å beskrive behovet:
- Recovery Time Objective (RTO) er målet for hvor raskt en tjeneste skal være gjenopprettet etter et avbrudd.
- Recovery Point Objective (RPO) uttrykker hvor mye datatap, målt bakover i tid, virksomheten kan akseptere.
En RTO på fire timer er lite verdt dersom en test viser at gjenopprettingen tar en arbeidsdag. Tilsvarende må et RPO-krav støttes av backupintervaller og tekniske løsninger som faktisk kan levere det.
Kravene bør derfor knyttes til konkrete konsekvenser. Hvor mange ordre, dokumentendringer eller arbeidstimer går tapt? Hvilke frister eller leveranser påvirkes? Svarene gjør det mulig å prioritere ulike systemer i stedet for å gi alle samme krav.
Skytjeneste, bevaring og backup er ulike lag
Skytjenester har ofte redundans, papirkurv, versjonshistorikk og innebygde gjenopprettingsfunksjoner. Disse egenskapene reduserer flere typer risiko, men de er ikke automatisk det samme som en testet backup- og beredskapsplan.
Microsoft dokumenterer for eksempel Microsoft 365 Backup som en egen tjeneste for beskyttelse og gjenoppretting av Exchange-postbokser, OneDrive-kontoer og SharePoint-områder. Microsofts dokumentasjon skiller også mellom backupens gjenopprettingsvindu og regler for bevaring og sletting i Purview.
Det relevante spørsmålet er derfor ikke bare om data ligger i skyen. Virksomheten må vite hvilke hendelser de innebygde funksjonene dekker, hvor lenge innhold kan gjenopprettes, hvem som har tilgang til verktøyene og om prosessen er testet for aktuelle scenarioer.
Vanlige grunner til at gjenoppretting stopper
Selv når backupdataene er intakte, kan gjenopprettingen forsinkes av forhold rundt løsningen:
- kritiske systemer og rekkefølgen mellom dem er ikke prioritert
- ansvar for beslutning og gjennomføring er uklart
- administratortilganger eller flerfaktorautentisering er utilgjengelig
- konfigurasjon, krypteringsnøkler eller lisenser mangler
- DNS, nettverk, identitet eller integrasjoner er ikke med i planen
- backupen er ikke tilstrekkelig isolert fra produksjonsmiljøet
- dokumentasjonen ligger bare i systemet som er nede
Dette er også grunnen til at grunnleggende kontroll på IT-driften er viktig. Gjenoppretting av data løser ikke alene manglende oversikt over systemet rundt.
Hvor ofte bør restore testes?
Det finnes ikke ett testintervall som passer alle. Frekvens og omfang bør bestemmes av konsekvensen ved bortfall, hvor ofte løsningen endres, avhengighetene og tidligere testresultater.
En mindre virksomhet kan bruke følgende som utgangspunkt og justere etter risiko:
- regelmessige filtester for de viktigste datatypene
- tjenestetest etter vesentlige endringer og med et fast, risikobasert intervall
- periodisk driftstest eller bordøvelse for de mest kritiske leveransene
En enkel og gjentakbar test er mer nyttig enn en omfattende plan som aldri gjennomføres. Samtidig må testen være stor nok til å undersøke det faktiske kravet virksomheten har satt.
Sjekkliste for den første testen
- Velg ett kritisk datasett og en ufarlig testkandidat.
- Beskriv forventet resultat, RTO og RPO før testen starter.
- Avklar hvem som beslutter, utfører og godkjenner gjenopprettingen.
- Kontroller at nødvendige tilganger og dokumentasjon er tilgjengelige.
- Gjenopprett til et sikkert og egnet mål uten å overskrive produksjon.
- Mål tiden fra beslutning til verifisert resultat.
- Kontroller innhold, funksjon, metadata og rettigheter.
- Dokumenter feil, avhengigheter og forbedringstiltak med ansvarlig og frist.
Testdata og gjenopprettede kopier må behandles med samme krav til tilgang, personvern og sletting som originaldataene.
Dette bør ledelsen få vite
Ledelsen trenger vanligvis ikke alle detaljene fra backupkonsollen. Et kort beslutningsgrunnlag bør vise hvilke systemer som er kritiske, når gjenoppretting sist ble testet, hvor lang tid det tok, hvilke krav som ble oppfylt og hvilke svakheter som fortsatt står åpne.
En grønn backupstatus er nyttig driftsinformasjon. Dokumentert gjenoppretting er derimot beviset på at virksomheten kjenner tilbakeveien.
Kilder
