---
# source: src/content/services/de/disaster-recovery.md
# route:  /de/services/disaster-recovery/
title: Disaster Recovery
group: infrastructure
order: 7
tags: [backup-recovery, architecture, migration]
vendors: [hpe, veeam]
summary: RPO und RTO zuerst, Technik danach. Und ein Konzept, das nie getestet wurde, ist eine Hoffnung.
photoNeed: "A failover rehearsal in progress: two engineers at a screen with a runbook open beside them, mid-test rather than posed"
stub: false
draft: false
---

## Wogegen es schützt

Gegen Stromausfall, Wasser, Feuer und Erdbeben, die alle selten sind und trotzdem
vorkommen. Und gegen Ransomware, wo ein durchdachtes Disaster-Recovery-Konzept den
Unterschied zwischen Tagen und Wochen macht.

## Womit wir anfangen

Mit zwei Zahlen. **RPO**, wie viel Datenverlust akzeptabel ist, und **RTO**, wie lange es
dauern darf, bis es wieder läuft. Beide müssen mit den Stakeholdern verifiziert und
freigegeben werden, denn sie tragen die ganze Architektur und sind keine technische
Grösse.

Danach klassifizieren und priorisieren wir Daten und Systeme. Nicht alles braucht dieselbe
Zahl, und der Versuch, alles gleich zu behandeln, ist der häufigste Grund, warum ein
Konzept zu teuer wird.

## Wie das Design entsteht

Berücksichtigt werden die Workloads in deinen Rechenzentren und in deinen Public Clouds,
dazu die Verfügbarkeits- und Leistungsanforderungen. Auch die Wahl der Standorte fliesst
ein: Wo deine Rechenzentren und Cloud-Regionen liegen, bestimmt mit, was überhaupt möglich
ist.

## Umsetzung, und der Teil, der übersprungen wird

Wir setzen auf Zerto und Veeam. Beide erlauben es, den Ernstfall zu testen: Virtuelle
Server lassen sich am Zielstandort in einer Sandbox starten und überprüfen, ohne die
Produktion zu berühren.

Genau das ist der Teil, der übersprungen wird. Regelmässige Testszenarien mit den
Systemadministratoren und den betroffenen Fachbereichen sind das, was ein Konzept von einer
Hoffnung unterscheidet.