Hvordan går du til værks med disaster recovery på AWS?

Question

Accepted Answer

**Disaster recovery (DR)** er planlægning af, hvordan man genopretter systemer og data efter en større fejl eller katastrofe. AWS tilbyder DR-strategier med forskellige afvejninger mellem **genoprettelseshastighed**, **datatab** og **omkostninger** — defineret af RTO- og RPO-målsætninger.

## Vigtige begreber: RTO og RPO

```text
RTO (Recovery Time Objective) → how QUICKLY you must recover (acceptable downtime)
RPO (Recovery Point Objective) → how much DATA LOSS is acceptable (recover to how
  recent a point — e.g. "at most 5 minutes of data lost")
→ Lower RTO/RPO (faster recovery, less data loss) = higher cost/complexity.
  Define these based on business needs; they drive the DR strategy choice.
```

## DR-strategier (omkostninger vs. genoprettelseshastighed)

```text
1. BACKUP & RESTORE → back up data (to S3, snapshots); restore after a disaster
   → cheapest; slowest recovery (hours); higher RPO. For tolerant workloads.
2. PILOT LIGHT → core systems (e.g. database, replicated) kept minimal/ready;
   scale up the rest on disaster → moderate cost, faster recovery
3. WARM STANDBY → a scaled-down but RUNNING copy in another region; scale up on failover
   → higher cost, fast recovery (minutes)
4. MULTI-SITE ACTIVE-ACTIVE → full running copies in multiple regions serving traffic
   → highest cost/complexity; near-zero RTO/RPO. For the most critical systems.
```

## Praktiske DR-praksisser

```text
✓ Regular, tested BACKUPS (automated; cross-region copies; verify they restore!)
✓ Cross-REGION strategy for region-level disasters (DR often = another region)
✓ INFRASTRUCTURE AS CODE → recreate environments quickly/reliably
✓ TEST DR plans regularly (a plan never tested may fail when needed)
✓ Automate failover where possible; document runbooks
→ Match the strategy to the workload's RTO/RPO and budget.
```

## Hvorfor det betyder noget

At forstå disaster recovery er vigtig viden på seniorniveau, fordi **at genvinde systemerne efter større fejl er afgørende for kritiske systemer**, og AWS DR involverer vigtige afvejninger, så det er værdifuldt for design af modstandsdygtige systemer.

DR adresserer realiteten om, at større katastrofer kan ske (regionfejl, datakorruption, katastrofale fejl), og **kritiske systemer skal kunne genoprettes** — hvilket gør DR-planlægning væsentlig for systemer, hvor nedetid eller datatab har alvorlige konsekvenser.

At forstå **RTO og RPO** er fundamentalt: disse målsætninger (hvor hurtigt du skal genoprette, og hvor meget datatab der er acceptabelt) **driver DR-strategien** og skal defineres baseret på forretningsbehov — hvilket præciserer, at DR ikke er en løsning, der passer alle, men en bevidst afvejning.

At forstå **DR-strategierne** og deres **omkostnings-vs-genoprettelseshastighed-afvejninger** — backup & restore (billigst, langsomst), pilot light (kernesystemer klar), warm standby (skaleret-ned kørende kopi, hurtig genopretning) og multi-site active-active (fulde kørende kopier, næsten-nul RTO/RPO men højeste omkostninger) — er nøgleviden til at vælge en passende strategi: mere krævende genoprettelsesmålsætninger koster mere, så strategien skal passe til arbejdsbelastningens kritikalitet og budget.

At forstå **praktiske DR-praksisser** (regelmæssige testede sikkerhedskopier, tværregion-strategi for region-niveau katastrofer, Infrastructure as Code for hurtig miljøgenopretning, og afgørende **test af DR-planer**, da utestede planer ofte mislykkes når de er nødvendige) afspejler moden operationel disciplin.

Fordi at genvinde fra katastrofer er væsentlig for kritiske systemer, og DR involverer virkelige afvejninger (genoprettelseshastighed, datatab, omkostninger), der skal matches med forretningsbehov, og fordi forståelse af RTO/RPO, DR-strategierne og praktiske praksisser muliggør design af passende genoprettelsesmuligheder, er forståelse af disaster recovery på AWS vigtig viden på seniorniveau for konstruktion af modstandsdygtige systemer — et kritisk aspekt af drift af vigtige forretningsarbejdsbelastninger, hvilket afspejler den risikostyrings- og resiliens-planerings-modenhed, der forventes for seniorer med ansvar for systemer, hvor fejl og datatab har alvorlige konsekvenser.