IT-guide

Backup, disaster recovery og forretningskontinuitet

Backup beskytter data, men forretningskontinuitet kræver mere: prioritering, afhængigheder, gendannelsesrækkefølge, alternative arbejdsgange og dokumenteret ansvar.

RTORPOBackupDisaster RecoveryBIA

Senest fagligt gennemgået: 10. august 2026 · Af Mikkel R. Søndergaard

RTO og RPO

RTO (Recovery Time Objective) beskriver det mål, man har for hvor hurtigt en service skal kunne genoprettes efter en hændelse. RPO (Recovery Point Objective) beskriver hvor stort et datatab i tid der højst er acceptabelt. De to mål styrer forskellige designvalg.

En backup er kun én komponent

En databasebackup hjælper ikke, hvis applikationskonfiguration, krypteringsnøgler, identitetsafhængigheder eller integrationsopsætning mangler. Gendannelsesdesignet skal se på hele servicen.

Restore-tests skaber bevis

Det er ikke nok at se, at backupjobbet er grønt. En restore-test undersøger, om data faktisk kan gendannes, om proceduren er kendt, og om resultatet er konsistent med de øvrige systemer.

Business Impact Analysis

NIST's contingency-planning-vejledning bruger Business Impact Analysis som et centralt trin til at forstå kritiske processer, konsekvenser og gendannelsesbehov. Det hjælper organisationen med at prioritere frem for at give alle systemer samme mål.

Gendannelsesrækkefølge følger afhængigheder

Et ERP-system kan være teknisk gendannet, men stadig ubrugeligt uden identitet, DNS, integrationsplatform eller database. En realistisk plan beskriver derfor både services og deres rækkefølge.

Alternative arbejdsgange

Nogle processer kan fortsætte manuelt i en periode; andre kan ikke. Dokumenterede workarounds kan være en vigtig del af kontinuitetsplanen, især hvis et system har længere RTO.

Denne side forklarer arkitektur og principper. Konkrete valg afhænger af organisation, risici, lovgivning, leverandører, kontrakter og eksisterende systemlandskab.