---
title: "Disaster Recovery Test: So testen Sie Ihren DR-Plan"
date: 2026-06-03T08:20:00+02:00
author: FAST LTA
canonical_url: "https://www.fast-lta.de//de/blog/disaster-recovery-test-so-testen-sie-ihren-dr-plan"
section: "Entries: Articles"
---
### Die 3 Test­me­tho­den [\#](#die-3-testmethoden "Die 3 Testmethoden")

#### Metho­de 1: Table­top Exer­cise (Walk­th­rough) [\#](#methode-1-tabletop-exercise-walkthrough "Methode 1: Tabletop Exercise (Walkthrough)")

**Was:** Simu­lier­tes Sze­na­rio, alle Rol­len sit­zen zusam­men, durch­spie­len was pas­siert — ohne ech­te Systeme.

**Vor­be­rei­tung:** 2 – 4 Stunden.

**Durch­füh­rung:** 2 – 3 Stun­den (Table­top Session).

**Bei­spiel-Sze­na­rio:** ​“Es ist Mon­tag 9 Uhr. Sie kom­men ins Büro. Der ERP-Ser­ver ist off­line und das Back­up-Sys­tem ant­wor­tet nicht. Was tun Sie?”

Rol­len:

- Inci­dent Com­man­der: Lei­tet die Diskussion
- IT-Lei­ter: Dia­gnos­ti­ziert was los ist
- CFO: Eva­lu­iert geschäft­li­che Konsequenzen
- Com­mu­ni­ca­ti­ons Mana­ger: Plant exter­ne Kommunikation

Das Team durch­spielt: ​“Was ist der ers­te Anruf? An wen geben wir den Incident?Was sagen wir dem Kunden?”

**Nut­zen:**

- Iden­ti­fi­ziert Lücken im IR-Plan
- Klärt Rol­len und Verantwortlichkeiten
- Sehr nied­ri­ge Aus­fall­kos­ten (nichts geht wirk­lich down)
- Good für Kri­sen­kom­mu­ni­ka­ti­on und Entscheidungsfindung

**Schwä­che:**

- Tes­tet nicht die tech­ni­schen Wiederherstellungsschritte
- Oft zu theoretisch

#### Metho­de 2: Teil­test (Par­ti­al Reco­very Test) [\#](#methode-2-teiltest-partial-recovery-test "Methode 2: Teiltest (Partial Recovery Test)")

**Was:** Ein ein­zel­nes Sys­tem wird tat­säch­lich aus Back­up wie­der­her­ge­stellt — aber nicht in Pro­duc­tion. In Test-Umge­bung oder alter Hardware.

**Vor­be­rei­tung:** 1 Woche (Pla­nung, Backup-Vorbereitung).

**Durch­füh­rung:** 4 – 8 Stun­den (ech­te Recovery).

**Bei­spiel-Sze­na­rio:** ​“Wir tes­ten ERP-Reco­very. Wir neh­men das neu­es­te ERP-Back­up und stel­len es auf einer sepa­ra­ten Test-VM wie­der her. Wir boo­ten die VM, veri­fi­zie­ren dass das Sys­tem funk­tio­niert, und dann löschen wir die Test-VM.”

Das ist ein **ech­te Reco­very** — aber nicht risi­ko­be­haf­tet, weil Pro­duc­tion nicht berührt wird.

**Nut­zen:**

- Tes­tet den ech­ten Recovery-Prozess
- Misst tat­säch­li­che Reco­very-Zeit (nicht geschätzt)
- Iden­ti­fi­ziert Feh­ler im Back­up oder Recovery-Software
- Doku­men­tier­tes Ergeb­nis für Audits

**Schwä­che:**

- Nur ein Sys­tem pro Test
- Tes­tet nicht die Reco­very-Rei­hen­fol­ge (wel­ches Sys­tem zuerst?)

#### Metho­de 3: Voll­test (Full Dis­as­ter Reco­very Test) [\#](#methode-3-volltest-full-disaster-recovery-test "Methode 3: Volltest (Full Disaster Recovery Test)")

**Was:** Alle kri­ti­schen Sys­te­me wer­den gleich­zei­tig aus Back­up wie­der­her­ge­stellt — voll­stän­di­ger Prozess.

**Vor­be­rei­tung:** 4 Wochen (Pla­nung, Infra­struk­tur-Vor­be­rei­tung, kom­mu­ni­zie­ren mit Teams).

**Durch­füh­rung:** 1 – 3 Tage (Voll­stän­di­ge Recovery).

**Bei­spiel-Sze­na­rio:** ​“Wir simu­lie­ren einen kom­plet­ten Dat­a­cen­ter-Aus­fall. Alle Pro­duk­ti­ons-Sys­te­me (AD, ERP, File­ser­ver, E‑Mail) wer­den in der Reco­very-Umge­bung wie­der­her­ge­stellt. Wir tes­ten die Reco­very-Rei­hen­fol­ge, die Inter-Sys­tem-Kom­mu­ni­ka­ti­on, und am Ende: kann der Geschäfts­be­trieb funktionieren?”

Das ist eine **voll­stän­di­ge End-to-End Reco­very** — unter Testbedingungen.

**Nut­zen:**

- Tes­tet gesam­tes Resilienz-System
- Iden­ti­fi­ziert Abhän­gig­keits­pro­ble­me (z.B. ​“ERP funk­tio­niert nicht ohne Fileserver”)
- Misst gesam­te RTO (nicht ein­zeln pro System)
- Vali­diert dass Back­up-Infra­struk­tur funktioniert
- Größ­te Kon­fi­denz in tat­säch­li­che Recovery-Fähigkeit

**Schwä­che:**

- Gro­ßer Aufwand
- Erfor­dert dedi­zier­te Infra­struk­tur (oder Production-Ausfallzeitfenster)
- Teu­er
- Logis­tisch kom­plex (alle Teams beteiligt)

### BSI-Anfor­de­run­gen: CON.3.A11 Test­fre­quenz [\#](#bsi-anforderungen-con-3-a11-testfrequenz "BSI-Anforderungen: CON.3.A11 Testfrequenz")

Das BSI IT-Grund­schutz Pro­fil CON.3 (Con­ti­nui­ty Manage­ment) defi­niert Testanforderungen:

**CON.3.A11:** ​“Wie­der­her­stel­lung kri­ti­scher Infor­ma­tio­nen und Sys­te­me soll­ten regel­mä­ßig getes­tet werden.”

Das ist vage, aber in der Pra­xis wird das so interpretiert:

Kri­ti­k­ali­tät SystemTable­topTeil­testVoll­test\*\*Kri­tisch\*\*2x p.a.4x p.a.1x p.a.\*\*Wich­tig\*\*1x p.a.2x p.a.optio­nal\*\*Nor­mal\*\*1x p.a.1x p.a.optio­nalFür grö­ße­re Unter­neh­men mit NIS2-Com­pli­ance wird ein jähr­li­cher Voll­test fast erwartet.

### Prak­ti­scher Test-Kalen­der [\#](#praktischer-test-kalender "Praktischer Test-Kalender")

Ein prag­ma­ti­scher Ansatz für ein mit­tel­stän­di­sches Unternehmen:

```
Q1 (Jan-Mär):
├── Woche 1-2: Tabletop Exercise (alle)
├── Woche 3-4: Teiltest ERP
└── Dokumentation & Lessons Learned

Q2 (Apr-Jun):
├── Woche 1-2: Tabletop Exercise fokussiert auf Cybersecurity-Szenario
└── Woche 3-4: Teiltest Fileserver

Q3 (Jul-Sep):
├── Woche 1-2: Teiltest E-Mail
└── Woche 3-4: Lessons Learned Session

Q4 (Okt-Dez):
├── Woche 1-4: Volltest (alle Systeme) — inklusive externe Evaluation
└── Management Report & Plan für nächstes Jahr

```

Das deckt BSI-Anfor­de­run­gen ab ohne Pro­duc­tion zu beeinträchtigen.

### Doku­men­ta­ti­on der Test­ergeb­nis­se [\#](#dokumentation-der-testergebnisse "Dokumentation der Testergebnisse")

Nach jedem Test soll­te doku­men­tiert werden:

**Test Sum­ma­ry:**

- Datum, Test­typ (Tabletop/​Teiltest/​Volltest)
- Getes­te­te Systeme
- Teilnehmer/​Rollen
- Test­ziel

**Erkennt­nis­se:**

- Was funk­tio­nier­te?
- Was funk­tio­nier­te nicht?
- Kri­ti­sche Feh­ler (mit Remediation-Plan)
- Erkennt­nis­se für nächs­ten Test

**RTO-Mes­sung:**

- Geschätz­te RTO (alt)
- Tat­säch­li­che RTO (Test-Ergeb­nis)
- Dif­fe­renz analysieren

**Inte­gri­tät-Vali­die­rung:**

- Wur­den Daten kor­rekt wiederhergestellt?
- Gab es Kor­rup­ti­on oder Datenverlust?
- Sys­te­me funk­tio­nier­ten nor­mal nach Recovery?

**Appr­ovals:**

- Unter­schrift von IT-Lei­ter, CIO, even­tu­ell CRO (Chief Risk Officer)

Die­ses Doku­ment ist spä­ter dein Beweis gegen­über Audi­to­ren, dass Reco­very tat­säch­lich funktioniert.

### Häu­fi­ge Feh­ler bei DR-Tests [\#](#h%C3%A4ufige-fehler-bei-dr-tests "Häufige Fehler bei DR-Tests")

**Feh­ler 1: Test-Umge­bung ist nicht realistisch** ​“Wir haben getes­tet, aber nur mit 10% der ech­ten Daten­men­ge. Rea­ler Test wür­de 10x län­ger dauern.”

Lösung: Nut­ze ech­te Back­up-Daten und ech­te Hardware-Dimensionierung.

**Feh­ler 2: Nur die IT tes­tet, nicht die Business** ​“Das IT-Team hat die Reco­very durch­ge­führt, aber wir haben nicht getes­tet ob das Busi­ness damit arbei­ten kann.”

Lösung: Bring Busi­ness-Rol­len in den Test (nicht nur durch­le­sen, son­dern tes­ten dass ihre Anwen­dun­gen funktionieren).

**Feh­ler 3: Test-Daten wer­den nicht gelöscht** ​“Nach dem Test bleibt ein Shadow-Sys­tem online, das wird ver­ges­sen, und irgend­wann ist es out-of-sync zur Production.”

Lösung: Expli­zi­te Cle­a­nup. Nach Test: Sys­te­me löschen, Doku­men­ta­ti­on archivieren.

**Feh­ler 4: Tests zei­gen Pro­ble­me, wer­den nicht remedied** ​“Der Full­test hat gezeigt, dass Reco­very 10 Stun­den dau­ert, nicht 4 wie RTO vor­sieht. Aber wir haben nichts gemacht.”

Lösung: Reco­very-Fin­dings müs­sen in einen Reme­dia­ti­on-Back­log gehen. Eska­lie­ren bis fix.

### RTO-Mes­sung im Test [\#](#rto-messung-im-test "RTO-Messung im Test")

Das ist der kri­tischs­te Punkt eines DR-Tests: **RTO tat­säch­lich mes­sen**.

Das bedeu­tet nicht nur ​“Reco­very dau­er­te 2 Stun­den”. Es bedeutet:

1. **Start-Zeit doku­men­tie­ren** (wann wur­de Reco­very gestartet)
2. **Ers­te Daten ver­füg­bar** (wann war das Sys­tem online, aber noch nicht getestet)
3. **Veri­fi­zie­rung abge­schlos­sen** (wann wis­sen Sie, dass das Sys­tem sau­ber ist)
4. **Full func­tion­a­li­ty** (wann kön­nen User nor­mal arbeiten?)

Typi­scher­wei­se: RTO = Full Func­tion­a­li­ty Zeitpunkt.

Ein Bei­spiel:

- 10:00 Uhr: Reco­very gestartet
- 11:45 Uhr: Ser­ver bootet
- 12:00 Uhr: Ers­te Log­in funktioniert
- 12:15 Uhr: Inte­gri­tät-Check ok
- 12:30 Uhr: User kön­nen wie­der arbeiten

RTO gemes­sen: 2.5 Stun­den (10:00 — 12:30).

Die­se Mes­sung ist wert­voll für Zukünf­ti­ge Recovery-Planung.

### Häu­fi­ge Fra­gen [\#](#h%C3%A4ufige-fragen "Häufige Fragen")

**Müs­sen wir Pro­duc­tion-Sys­te­me für Voll­test abschalten?** Tech­nisch nicht — wenn Sie dedi­zier­te Test-Infra­struk­tur haben. Aber oft ist ein Aus­fall­zeit­fens­ter sauberer.

**Wie oft müs­sen wir Voll­test machen?** Min­des­tens 1x pro Jahr. Aggres­si­ve Resi­li­enz-Pro­gram­me machen 2x pro Jahr.

**Kön­nen wir Tests mit exter­ne Con­sul­tant outsourcen?** Ja, aber nur wenn Ihr Team auch dabei ist und lernt. Ein Test, bei dem nur eine exter­ne Fir­ma teil­nimmt, hilft wenig.

---

### Disaster Recovery

Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können.

[Mehr erfahren →](https://www.fast-lta.de//de/glossar/disaster-recovery)