Drift og beredskab

Backup og gendannelsestest: Kan jeres app komme tilbage?

En backup er ikke bare en fil med data. Den er en dokumenteret mulighed for at få den vigtigste del af appen i drift igen efter en fejlopdatering, sletning, kompromitteret konto eller driftsfejl. Det ved I først, når gendannelsen er afprøvet.

Opdateret 1. august 2026 · Ca. 13 minutters læsetid

Backup skal dække mere end databasen

Kortlæg de dele, appen ikke kan fungere uden. Et Git-repository kan beskytte kode og historik, men det indeholder normalt hverken produktionsdata, uploadede filer, brugerkonti eller indstillinger hos cloud- og integrationsleverandører.

Del af løsningen	Eksempler	Det skal planen svare på
Kode og deployment	Repository, branches, workflows og buildindstillinger	Hvilken kendt version kan udgives igen, og hvem har adgang?
Database	Kunder, sager, ordrer, roller og historik	Hvor ofte kopieres data, hvor længe beholdes de, og hvordan gendannes de?
Filer	Billeder, PDF'er, bilag og eksportfiler	Er versionering, soft delete eller separat kopi nødvendig?
Konfiguration	DNS, regler, indekser, miljøer og planlagte jobs	Hvad ligger som kode, og hvad findes kun i en portal?
Identitet og integrationer	Brugere, SSO, API-adgange og webhooks	Kan adgang og forbindelser genetableres uden at gemme secrets usikkert?

Aftal hvor meget data og tid virksomheden kan miste

To enkle mål gør backupplanen konkret. RPObeskriver, hvor langt tilbage man højst accepterer at miste ændringer. Hvis en dags registreringer er uacceptable at genskabe manuelt, er en ugentlig kopi ikke nok. RTO beskriver, hvor længe funktionen må være utilgængelig, før konsekvensen bliver for stor.

Målene kan være forskellige for hver del af appen. Et internt statistikdashboard kan måske vente, mens ordre- eller sagsdata skal hurtigere tilbage. Vælg ud fra forretningskonsekvens, ikke ud fra hvad platformens standardopsætning tilfældigvis tilbyder.

Vælg en mekanisme, der passer til datatypen

Cloud Firestore

Firestores planlagte backup er en konsistent kopi af databasen på et bestemt tidspunkt og kan gendannes til en ny database. Den omfatter data og indekskonfiguration, men ikke blandt andet Security Rules og TTL-politikker. De dele skal derfor dokumenteres og helst ligge som versioneret konfiguration. Managed export/import er en anden mekanisme; en eksport er ikke et præcist snapshot fra eksportens starttidspunkt og kan indeholde samtidige ændringer.

Azure SQL og andre administrerede SQL-databaser

Azure SQL tager automatiske backups og kan gendanne til et tidligere tidspunkt inden for den valgte opbevaringsperiode. En point-in-time restore opretter en ny database, hvilket er nyttigt til en isoleret test. Kontrollér den konkrete databases retention, rettigheder og om eventuelle langtidskopier er nødvendige. På andre platforme kan mekanismer og vilkår være anderledes.

PostgreSQL, I selv driver

PostgreSQL beskriver SQL-dump, filsystembackup og løbende arkivering som forskellige tilgange med forskellige egenskaber. pg_dump er nyttig til eksport, men den officielle dokumentation fraråder den som fast backupmetode for produktionsdatabaser bortset fra enkle tilfælde. Planen skal passe til den konkrete drift, datamængde og ønskede gendannelsestid.

Objektlager og uploadede filer

Versionering og soft delete kan beskytte mod overskrivning og sletning, men er ikke automatisk en backup af hele appen. I Azure Blob Storage anbefaler Microsoft flere lag af databeskyttelse; en lås på selve storage-kontoen beskytter ikke nødvendigvis de enkelte blobs. Dokumentér også hvordan filer kobles til databaseposter efter restore.

Backup må ikke skabe en ny sikkerhedsrisiko

Begræns adgangen: Kun få roller bør kunne ændre backupopsætning, slette kopier eller starte en gendannelse.
Adskil fejlområder: Overvej om en kompromitteret produktionsadministrator også kan slette alle kopier.
Krypter og log: Backup indeholder ofte samme følsomme data som produktion og skal beskyttes og overvåges derefter.
Gem ikke secrets i runbooken: Beskriv hvor godkendt adgang findes, hvordan den roteres, og hvem der kan frigive den.
Planlæg sletning: Retention skal passe til formål og aftaler. Når slettede personoplysninger gendannes fra en ældre kopi, skal de håndteres igen efter virksomhedens sletteproces.

GDPR giver ikke én fast backupopskrift. De passende foranstaltninger afhænger af risikoen. Datatilsynet fremhæver både muligheden for at genskabe data, sikker opbevaring af kopier og løbende kontrol af, at backup faktisk virker.

Sådan gennemfører I en sikker gendannelsestest

1. Vælg et realistisk scenarie. Eksempelvis slettede kundeposter, overskrevne filer eller en fejlbehæftet release med datamigrering.
2. Brug et isoleret mål. Gendan til en ny database, bucket eller et særskilt testmiljø. Overskriv ikke produktion for at bevise, at backup virker.
3. Registrér udgangspunktet. Notér backup-ID, tidspunkt, ansvarlig, forventet indhold og hvilke dele der skal gendannes særskilt.
4. Følg kun den dokumenterede runbook. Hvis testen kræver viden, som kun én person husker, er det et konkret resultat, der skal rettes.
5. Kontrollér mere end antal rækker. Åbn udvalgte sager, relationer og filer. Test login, rettigheder og appens vigtigste arbejdsgang mod det gendannede miljø.
6. Mål forløbet. Registrér datatabsvinduet, tiden til brugbar drift, fejl og manuelle trin, og sammenhold resultatet med de aftalte mål.
7. Luk testen forsvarligt. Slet testkopier efter den aftalte proces, fjern midlertidige adgange, og opdatér runbooken med læringen.

Runbooken skal kunne bruges under pres

Skriv et kort driftsdokument, som en anden relevant person kan følge. Det bør pege på systemejere, leverandørkonti, datakilder, backupplaceringer, nødvendige rettigheder, rækkefølge for gendannelse, kontrolpunkter, beslutning om trafikskift og kontaktpersoner. Medtag dato og resultat for seneste test – men ingen adgangskoder eller nøgler.

Typiske fejl

Git forveksles med hel backup: Koden kan genskabes, men data, filer og cloudindstillinger mangler.
“Backup succeeded” accepteres som bevis: Jobbet kørte grønt, men ingen har prøvet at bruge resultatet.
Retention er kortere end opdagelsestiden: Fejlen opdages først, efter den sidste brugbare kopi er udløbet.
Kun databaseposter kontrolleres: Vedhæftninger, roller, regler, jobs og integrationer virker stadig ikke.
Testen sker i produktion: En driftsøvelse bliver selv årsag til datatab eller nedetid.
Ingen ejer alarmen: En mislykket backup sender måske en mail, men ingen har ansvar for at reagere.

Tjekliste til en troværdig backupplan

□ Kode, database, filer, konfiguration, identitet og integrationer er kortlagt.
□ RPO og RTO er aftalt for de vigtigste funktioner.
□ Backupfrekvens og retention følger risikovurderingen og faktisk ændringstakt.
□ Adgang, kryptering, sletning og ansvar er dokumenteret.
□ Fejl i backupjob giver en alarm til en navngiven ansvarlig.
□ En gendannelse er gennemført i et isoleret miljø.
□ Data, filer, rettigheder og et centralt brugerflow er kontrolleret efter restore.
□ Det målte resultat er sammenholdt med de aftalte RPO- og RTO-mål.
□ Runbooken har ejer, seneste testdato og tidspunkt for ny test.

Relaterede guides

GitHub til kode og historik Firebase Hosting og Firestore Azure Table Storage og Blob Storage Se alle guides

Officielle kilder

Backupfunktioner, opbevaringsperioder og konsoltrin ændres. Kontrollér den aktuelle dokumentation for den platform og det abonnement, appen faktisk bruger.