Spørg udviklerne, om I har backup, og svaret er ja. Spørg, hvornår I sidst har gendannet hele produktet fra den, og tag tid på, hvor lang en pause der kommer. En backup er først bevist, når den er gendannet. Et SaaS-produkt består desuden af langt mere end en database: filer, opsætning, hemmelige nøgler, køer og en række eksterne tjenester. To øvelser fortæller jer, hvor I står: gendannelse af hele produktet i et tomt miljø og gendannelse af én enkelt kunde. Begge skal køres med stopur, og resultatet skal skrives ned.
To tal, ledelsen skal tage stilling til
Fagfolk bruger to forkortelser. RPO (recovery point objective) angiver, hvor meget data I højst må miste, målt i tid. RTO (recovery time objective) angiver, hvor længe produktet højst må være væk.
Tallene er forretningsbeslutninger. Må I miste den seneste time af kundernes arbejde? Den seneste dag? Må produktet være væk en time, eller kan det tåle at vente til næste morgen? Svaret afhænger af, hvad kunderne bruger produktet til, og hvad I har lovet i jeres SLA. Vælges tallene lavt, stiger kravene til opsætningen. Bliver de aldrig valgt, gælder det, som teknikken tilfældigvis giver, og det opdager I først på dagen, hvor det skal bruges.
Ledelsens side af sagen, herunder hvordan beredskabet hænger sammen med resten af virksomheden, er beskrevet i backup og reetablering. Her handler det om teknikken i produktet.
Hvad “hele produktet” består af
Lav en liste, før I øver. Den bør rumme:
- Databaser. Med tilstrækkeligt hyppige kopier til at holde jeres RPO.
- Filer og vedhæftninger. De ligger ofte uden for databasen og har deres egen backup, eller ingen.
- Infrastruktur. Kan miljøet bygges op fra en beskrivelse i kode, eller er det klikket sammen i en brugerflade for år tilbage? Infrastruktur som kode betyder, at opsætningen ligger som filer, der kan køres igen.
- Hemmeligheder og nøgler. Krypteringsnøgler, adgangskoder til tjenester og certifikater. Mister I krypteringsnøglen, er backuppen værdiløs.
- Domæne og DNS. Ejes kontoen af jer, og ved nogen, hvor den ligger?
- Eksterne tjenester. Mailudsendelse, betaling og login, og opsætningen hos dem.
- Kildekode og byggepipeline. Kan I bygge og udrulle en version, hvis værktøjet er væk?
- Viden. Findes trinene på skrift, så en anden kan følge dem?
Hvem der har adgang, er en del af øvelsen. En backup, som kun én person kan nå, er en nøglepersonafhængighed, se når én udvikler kender hele koden.
Øvelse 1: Hele produktet i et tomt miljø
Formålet er at finde ud af, om I kan stå op fra ingenting. Sådan kan den holdes:
- Vælg en dato, og fortæl, at formålet er at finde huller. Fejl er det ønskede resultat.
- Start med en tom konto eller et adskilt miljø. Brug aldrig produktionsmiljøet til øvelsen.
- Lad en anden end den, der plejer at stå for driften, følge trinene.
- Start stopuret, og før log over hvert trin.
- Gendan seneste backup, byg miljøet, sæt nøgler ind, og start produktet.
- Kontrollér, at en bruger kan logge ind og gennemføre kerneflowet, og at data passer.
- Stop uret, og sammenlign med jeres RTO.
Den første øvelse går sjældent glat. Der mangler en nøgle, en opsætning står kun i en persons hoved, og noget tager længere tid end forventet. Hvert fund bliver til en opgave med en ejer.
Øv også scenariet, hvor hele regionen eller kontoen er væk. Ligger backuppen i samme konto som produktet, kan en fejl, en slettet konto eller en ramt administrator tage begge dele. Kopier bør ligge adskilt fra den daglige drift med særskilte adgange.
Øvelse 2: Én enkelt kunde
Den oftest forekommende situation er mindre dramatisk. En kunde har ved en fejl slettet noget, eller en fejl i en release har ødelagt en del af data hos en enkelt kunde. Resten af produktet kører, og I kan ikke rulle alle andre kunder tilbage.
Her viser det sig, om jeres design understøtter det. Deler alle kunder én database, er det ikke muligt uden videre at hente én kunde tilbage. Metoden er ofte at gendanne en kopi af hele backuppen i et adskilt miljø og overføre kundens data derfra. Øv det med en testkunde, og mål tiden.
Stil tre spørgsmål bagefter:
- Hvor langt tilbage kan I hente data for én kunde?
- Kan I gøre det, uden at andre kunder bemærker noget?
- Hvad tager det af tid fra udviklerne?
Svaret afgør, hvad I kan love kunderne, og om der skal bygges noget, fx blød sletning, hvor data kan fortrydes i et stykke tid. Det afhænger af, om kunderne deler database, se multi-tenant mod én installation pr. kunde.
Tag også stilling til sletning. En kunde, der har fået data slettet, skal ikke dukke op igen ved en gendannelse. Se persondata i produktet.
Hyppighed og dokumentation
Gentag den fulde øvelse årligt og efter større ombygninger, fx efter flytning af platform. Automatiske prøver kan hjælpe: Lad et job gendanne seneste backup hver nat i et testmiljø og melde, om det lykkedes. Det erstatter ikke øvelsen, for det tester kun data, men det opdager en backup, der er holdt op med at virke.
Gem resultatet: dato, deltagere, målt tid, fund og opfølgning. Det er præcis det, kunderne spørger om i et sikkerhedsspørgeskema. Et svar med dato og målt tid står langt stærkere end ordet “ja”. Skriftlige trin gør også overdragelse lettere den dag, personerne skifter.
Det skal I lade være med
· At regne en grøn status fra backupværktøjet som bevis.
· At opbevare backup og produktion under samme adgang.
· At lade den samme person eje hele øvelsen hvert år.
· At øve i produktionsmiljøet.
Det skal I kræve af den eksterne
- ☐ Et ledelsesgodkendt RPO og RTO.
- ☐ En liste over alt, hvad produktet består af.
- ☐ En gennemført øvelse af hele produktet med tid på.
- ☐ En gennemført øvelse af gendannelse af én kunde.
- ☐ En skriftlig rapport med fund, ejere og datoer.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Overvågning, vagt og driftshændelser · Hvor ligger data?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
