DRaaS-Checkliste: was Sie prüfen sollten, bevor Sie einen Vertrag über Disaster Recovery as a Service unterschreiben
Eurokommerz, Wien, seit 2006: Private AI/ML · IT Managed Services · Enterprise Training · KI-Hardware & Software
- Wiederherstellungsziele gehören je Systemstufe ins SLA, mit einem RTO, der von Ihrer Failover-Anforderung bis zu laufenden Systemen gezählt wird; der Leitfaden der ENISA zur Überwachung von Sicherheits-Service-Levels in Cloud-Verträgen misst die Wiederherstellungsgeschwindigkeit auf dieselbe Weise, ab dem Zeitpunkt der Anforderung
- Kapazität ist nur reserviert, wenn der Vertrag es so festhält: In Veeam Cloud Connect kann ein Hardware-Plan mehrere Tenants bedienen, von denen jeder alle Ressourcen des Plans nutzen kann, und NIST SP 800-34 Rev. 1 warnt, dass ein von mehreren Organisationen geteilter Standort womöglich nicht alle aufnehmen kann, wenn ein Notfall genügend von ihnen gleichzeitig trifft
- Veeams Test eines Cloud-Failover-Plans startet jedes Replikat von seinem neuesten Wiederherstellungspunkt und prüft, ob es auf Ping antwortet; Anwendungsprüfungen und ein schriftlicher Bericht müssen deshalb im Vertrag vereinbart werden, ebenso die Zahl der Tests pro Jahr
- Gehen in Veeam Cloud Connect der Produktionsstandort und der Backup-Server des Tenants gemeinsam verloren, startet der Anbieter den Failover-Plan, den der Tenant vorab erstellt hat; der Vertrag muss deshalb festlegen, wer ihn anfordern darf, über welchen Kanal und wie schnell der Anbieter handelt
- Die Durchführungsverordnung (EU) 2024/2690 nennt in Punkt 5.1.4 Buchstabe h die Rückgabe und Vernichtung von Informationen unter den Pflichten bei Vertragsende, und ein Tenant von Veeam Cloud Connect, dessen Laufzeit (Lease) abgelaufen ist, kann keine VM-Daten mehr vom Cloud-Host wiederherstellen oder kopieren; die Exit-Klausel muss den Zugriff deshalb offenhalten, bis die Daten zurück sind
Eurokommerz × Vixen.UNO: Cloud Disaster Recovery Experten kontaktieren →
Was Sie vor Abschluss eines DRaaS-Vertrags prüfen sollten
Bevor Sie einen Vertrag über DRaaS (Disaster Recovery as a Service) unterschreiben, prüfen Sie, ob er Folgendes festlegt: die Wiederherstellungsziele je Systemstufe und ihre Messung, die für Sie vorgehaltene Kapazität, Zahl und Umfang der Failover-Tests, das Verfahren für die Ausrufung des Notfalls, wo Ihre Daten liegen und wer sie erreichen kann, und wie die Daten bei Vertragsende zu Ihnen zurückkommen und gelöscht werden. Jede Antwort gehört in den Vertrag oder in sein Service Level Agreement (SLA), und zwar so formuliert, dass Sie sie bei einem Test überprüfen können.
DRaaS ist ein Ausweichstandort, den ein Anbieter betreibt: Ihre virtuellen Maschinen werden in sein Rechenzentrum repliziert und können dort gestartet werden, solange Ihr eigener Standort ausgefallen ist. Damit mieten Sie einen Standort zwischen Warm Site und Hot Site, statt ihn selbst aufzubauen (siehe unseren Vergleich von Hot, Warm und Cold Sites). Ein Backup bewahrt Kopien von Daten auf, die noch Hardware und einen Neuaufbau brauchen; DRaaS hält die Systeme startbereit.
Die Fragen stützen sich auf NIST SP 800-34 Rev. 1, die Durchführungsverordnung (EU) 2024/2690, den Leitfaden der ENISA von 2012 zur Überwachung von Sicherheits-Service-Levels in Cloud-Verträgen und die Dokumentation von Veeam zu Cloud Connect. Die Verordnung bindet nur die in ihrem Artikel 1 genannten Einrichtungen, und welche Regeln Ihr Unternehmen binden, ist eine rechtliche Bewertung, die Ihre Rechtsabteilung vornimmt.
| BEREICH | WAS SIE FRAGEN | EINE GUTE ANTWORT |
|---|---|---|
| RPO und RTO je Stufe | Wie werden sie definiert, gemessen und berichtet? | Ziele je Stufe im SLA, der RTO ab Ihrer Failover-Anforderung gezählt, der erreichte RPO berichtet |
| Kapazität im Notfall | Sind CPU, RAM und Speicher für Sie reserviert? | Die reservierte Menge, wie viele Kunden sie teilen, Ihre Priorität, wenn mehrere gleichzeitig umschalten, wie lange Sie dort laufen dürfen |
| Failover-Tests | Wie viele pro Jahr, und was belegen sie? | Eine Zahl pro Jahr, Testkapazität inklusive, ein isoliertes Netz, Anwendungsprüfungen, ein schriftlicher Bericht mit Zeiten |
| Ausrufung des Notfalls | Wer darf einen Failover starten, und wie schnell handelt der Anbieter? | Benannte Personen auf beiden Seiten, ein Kanal, der ohne Ihre E-Mail funktioniert, die Reaktionszeit im SLA |
| Netzwerk beim Failover | Wie erreichen Benutzer und Partner die Replikate? | Ein schriftliches Konzept für IP-Adressen, VPN, DNS und Firewall-Änderungen, ein Verantwortlicher je Schritt, in einem Test erprobt |
| Failback | Wie kehren die Systeme zurück, und wer führt das durch? | Ein schriftliches Verfahren mit dem Datenweg zurück, dem Ausfallzeitfenster und einem Verantwortlichen je Schritt |
| Datenstandort | Wo liegen Replikate, Pläne und Protokolle? | Land und Rechenzentren im Vertrag genannt, kein Umzug ohne Ihre Zustimmung |
| Verschlüsselung | Wie sind Daten bei der Übertragung und im Ruhezustand geschützt? | TLS bei der Übertragung, Verschlüsselung im Ruhezustand für den Replikatspeicher, der Schlüsselinhaber benannt |
| Betreiber und Zertifikate | Wer betreibt das Rechenzentrum? | Der Betreiber benannt, ein Zertifikat nach ISO/IEC 27001, dessen Geltungsbereich den Standort einschließt, Auditrechte oder Auditberichte |
| Zugriff des Anbieters | Wer beim Anbieter kann Ihre Replikate erreichen? | Benannte Rollen, Zugriff genehmigt und protokolliert, Ihr Backup-Server nur mit Ihrer Zustimmung verwaltet |
| Unterauftragnehmer, Vorfälle | Wer ist noch beteiligt, und wann erfahren Sie von Sicherheitsvorfällen? | Unterauftragnehmer im Vertrag genannt, ein Auftragsverarbeitungsvertrag, Sicherheitsvorfälle unverzüglich gemeldet |
| Wartung, Versionen | Können Sie während einer Wartung beim Anbieter einen Failover auslösen? | Wartung vorab angekündigt, Failover-Anforderungen auch Währenddessen bearbeitet, Softwareversionen kompatibel gehalten |
| Support | Wie schnell reagiert der Support? | Servicezeiten und Reaktionszeiten im SLA, ein benannter Eskalationskontakt |
| Exit | Was geschieht mit Ihren Daten, wenn Sie den Vertrag beenden? | Eine Kündigungsfrist, die die Replikation zu einem neuen Standort abdeckt, Zugriff, bis Ihre Daten zurück sind, Löschung schriftlich bestätigt |
NIST SP 800-34 Rev. 1 (2010), Abschnitt 3.4.3; Durchführungsverordnung (EU) 2024/2690, Anhang, Punkte 4.2.6 und 5.1.4; ENISA, Procure Secure (April 2012); Veeam Cloud Connect Guide, Build 13.1.1.18, gelesen am 6. Oktober 2026. Die guten Antworten sind unsere Lesart dieser Quellen.
Wie ein DRaaS-SLA RPO und RTO definieren sollte
Der RTO eines Anbieters deckt nur einen Teil Ihres Ausfalls ab, denn die Erkennung und die Entscheidung, den Notfall auszurufen, bleiben meist auf Ihrer Seite; unser Leitfaden zum Festlegen von RPO und RTO je System zählt auf, was ein vollständiger RTO außerdem umfasst. Das SLA muss deshalb festhalten, wo die Uhr des Anbieters startet und wo sie stoppt. Eine klare Formulierung startet sie mit Ihrer Failover-Anforderung über den vereinbarten Kanal und stoppt sie, sobald die Systeme dieser Stufe am Ausweichstandort laufen und im vereinbarten Netz antworten. Der Leitfaden der ENISA misst die Wiederherstellung aus dem Backup auf dieselbe Weise, als „die ab dem Zeitpunkt der Anforderung benötigte Zeit, um Daten aus dem Backup zu erhalten“.
Bei einem stündlichen Replikationszeitplan kann der neueste nutzbare Wiederherstellungspunkt im Moment eines Ausfalls älter als eine Stunde sein, denn ein Punkt zählt erst, wenn sein Lauf abgeschlossen ist, und nach einem Lauf, der fehlschlägt oder länger als geplant dauert, bleibt der vorherige Punkt der neueste. Fragen Sie, wie der Replikationsrückstand überwacht und an Sie berichtet wird.
Der RTO einer Stufe hängt auch davon ab, wie viele Maschinen gleichzeitig starten. Veeams Leitfaden zu Cloud-Failover-Plänen hält fest: „Die maximale Anzahl von VMs, die beim Ausführen eines Failover-Plans gleichzeitig gestartet werden können, beträgt 10.“ Lassen Sie sich für eine große Stufe die Zeiten aus einem Test des vollständigen Plans geben.
In unserem Service Cloud Disaster Recovery sind Support sowie Ziel-RPO und -RTO je Systemstufe im SLA fixiert. Schicken Sie uns Ihre Systeme nach Stufen und die Zielwerte, die Sie brauchen; im ersten Gespräch gehen wir sie mit Ihnen durch.
Kapazität im Notfall: reserviert oder geteilt
Die Hosts eines Anbieters am Ausweichstandort bedienen viele Kunden, und der Vertrag entscheidet, was das bedeutet, wenn ein regionaler Stromausfall oder ein Hochwasser mehrere von ihnen gleichzeitig zum Failover zwingt. NIST SP 800-34 Rev. 1 warnt, dass ein von mehreren Organisationen geteilter Standort „möglicherweise nicht alle Kunden aufnehmen kann, wenn ein Notfall genügend dieser Kunden gleichzeitig trifft“, und fordert, die Prioritätsregelung des Anbieters und die Wiederherstellungstage, also wie lange Sie den Standort belegen können, im Vertrag auszuhandeln.
In Veeam Cloud Connect legt ein Hardware-Plan CPU, RAM, Speicher und Netze fest, die ein Tenant nutzen darf, und in Veeams Worten heißt es: „Der Service Provider kann einen oder mehrere Tenants demselben Hardware-Plan zuordnen“ und „Jeder Tenant, der dem Hardware-Plan zugeordnet ist, kann den gesamten Satz an Ressourcen nutzen, der im Hardware-Plan festgelegt ist.“ Ein Hardware-Plan setzt also Grenzen je Tenant; ob die Hosts dahinter alle zugeordneten Tenants gleichzeitig betreiben können, hängt von der Kapazitätsplanung des Anbieters ab. Schreiben Sie die für Sie vorgehaltene Kapazität in den Vertrag, mit der Angabe, ob sie geteilt wird und wie sie mitwächst, wenn Sie Systeme hinzufügen.
Failover-Tests: wie oft, wie isoliert und was der Bericht zeigt
Legen Sie im Vertrag die Zahl der Failover-Tests pro Jahr fest, ebenso, was jeder Test abdeckt und ob die Testkapazität enthalten ist. NIST fordert, dass Vereinbarungen „Tests, einschließlich Terminplanung, Verfügbarkeit, Testdauer und, falls erforderlich, zusätzlicher Tests“ abdecken, und nach Punkt 4.2.6 der Verordnung gilt für die Einrichtungen, die sie erfasst: Sie „dokumentieren die Testergebnisse“.
Veeams Test eines Cloud-Failover-Plans „schaltet nicht von einer Produktions-VM auf ihr Replikat um“; er setzt jedes Replikat auf seinen neuesten Wiederherstellungspunkt zurück, startet das Betriebssystem und prüft, ob die VM auf Ping antwortet. Das zeigt, dass die Maschinen starten; eine Anmeldung am ERP-System und funktionierende Schnittstellen brauchen dagegen Anwendungsprüfungen durch die Systemverantwortlichen, deren Dauer am RTO gemessen wird. Tests starten Replikate auf den Hosts des Anbieters und beanspruchen damit die Failover-Kapazität, und sie gehören in ein von der Produktion isoliertes Netz; unser Artikel zu Disaster-Recovery-Tests behandelt solche Aufbauten.
Unser Service Cloud Disaster Recovery umfasst planmäßige Failover-Tests in isolierter Umgebung, mit einem Bericht nach jedem Test darüber, was hochgekommen ist, wie schnell und was zu beheben ist. Beschreiben Sie im Formular unten die Systeme, die Sie zuerst testen lassen würden.
Den Notfall ausrufen, das Netzwerk beim Failover und das Failback
In Veeam Cloud Connect gilt: „Der Cloud-Failover-Plan muss vorab von einem Tenant erstellt werden“, und gespeichert wird er auf dem Backup-Server des Anbieters. Geht der Backup-Server des Tenants zusammen mit dem Produktionsstandort verloren, sieht der dokumentierte Weg vor, dass der Tenant den Anbieter kontaktiert, der dann den Plan startet. Der Vertrag sollte festlegen, wer auf Ihrer Seite diese Anforderung stellen darf, über welchen Kanal (einen, der ohne Ihre E-Mail und Ihren Verzeichnisdienst funktioniert), wie der Anbieter die Identität des Anrufers bestätigt und wie schnell er handelt. Solange der Backup-Server des Anbieters im Wartungsmodus ist, können Tenants weder einen Teil-Failover noch einen vollständigen Standort-Failover starten, und Vorgänge mit Cloud-Failover-Plänen bleiben nur auf der Seite des Anbieters verfügbar; der Vertrag sollte deshalb auch regeln, wie Wartung angekündigt wird und wie Failover-Anforderungen währenddessen bearbeitet werden. Nach Veeams Kompatibilitätsregeln gilt für ein Major-Upgrade, dass es „auf der Seite des Service Providers beginnen muss“, was Ihre eigenen Major-Upgrades an den Zeitplan des Anbieters bindet.
Netzseitig behandelt Veeam Teil-Failover und vollständigen Standort-Failover unterschiedlich, wie unser Vergleich von Veeam-Replikation, Backup Copy und Cloud Connect erklärt. Der Anbieter teilt Replikaten öffentliche IP-Adressen zu; DNS-Einträge, VPN-Zugänge für Benutzer und Firewall-Regeln bei Partnern brauchen jeweils einen Verantwortlichen, und der letzte Testbericht sollte zeigen, dass sie erledigt sind.
Das Failback braucht eine eigene Klausel, denn Veeam Cloud Connect hält fest: „Der Failback-Vorgang ist nur auf der Seite des Tenants verfügbar“, und nach einem vollständigen Standort-Failover führt der Tenant das Failback für jede VM des Plans gesondert aus. Ist Ihr Backup-Server mit dem Standort verloren gegangen, muss ein neu aufgebauter mit dem Anbieter verbunden werden, bevor das Failback beginnen kann. Vereinbaren Sie, wer diese Schritte ausführt, auf welchem Weg die Daten zurückkommen und wie lange die Rückschaltung dauert.
Datenstandort, Verschlüsselung und Zugriff des Anbieters
Die Replikate, der Backup-Server des Anbieters mit Ihren Failover-Plänen und die Protokolle liegen jeweils in einem Land und einem Rechenzentrum, die der Vertrag nennen sollte. NIST empfiehlt einen Standort „in einem geografischen Gebiet, das voraussichtlich nicht von derselben Gefahr beeinträchtigt wird wie der Hauptstandort der Organisation“; unser Artikel dazu, wie weit zwei Rechenzentren auseinanderliegen sollten, behandelt die Entfernung. In Veeam Cloud Connect legt der Backup-Server des Anbieters ein TLS-Zertifikat vor und baut eine sichere Verbindung zu Ihrem auf. Für ruhende Daten beschreibt Veeams Leitfaden eine Verschlüsselung, die Tenants in Backup- und Backup-Copy-Jobs einschalten, während Replikate VM-Dateien auf dem Speicher des Anbieters sind; fragen Sie also, wie dieser Speicher verschlüsselt ist und wer die Schlüssel hält.
Veeam schottet die Daten der Tenants voneinander ab, die Hosts betreibt aber der Anbieter. Fragen Sie, welche seiner Rollen Ihre Replikate erreichen können, wie dieser Zugriff genehmigt und protokolliert wird und ob er Ihren eigenen Backup-Server verwalten darf, was in Veeam eine Option voraussetzt, die der Tenant beim Verbinden aktiviert. Punkt 5.1.4 der Verordnung erfasst außerdem die unverzügliche Meldung von Sicherheitsvorfällen, das Recht auf Audits oder auf den Erhalt von Auditberichten sowie Anforderungen an die Vergabe von Unteraufträgen.
Exit: Rückgabe und Löschung der Daten am Vertragsende
Punkt 5.1.4 Buchstabe h nennt die Rückgabe und Vernichtung der Informationen unter den Pflichten bei Beendigung des Vertrags, und die ENISA schlägt Exporttests mit einer „Simulation der Beendigung des Dienstes“ vor. In Veeam Cloud Connect kann ein Anbieter für ein Tenant-Konto eine Laufzeit (Lease) festlegen, und Veeam schreibt: „Wenn die Laufzeit abläuft, kann der Tenant keine Backup-, Backup-Copy- und Replikationsaufgaben ausführen und keine VM-Daten aus dem Cloud-Repository oder vom Cloud-Host wiederherstellen und kopieren.“ Löscht der Anbieter ein Tenant-Konto, gilt für ausgeschaltete Replikate: Veeam „löscht die eigentlichen Replikatdateien aus dem Datastore oder Volume“; Replikate, die nach einem Failover laufen, behält es dagegen.
Die Exit-Klausel sollte deshalb eine Kündigungsfrist festlegen, die lang genug ist, um Ihre Systeme zu einem neuen Ausweichstandort zu replizieren, damit sie in der Zwischenzeit geschützt bleiben, und Ihren Zugriff offenhalten, bis alles, was nur beim Anbieter liegt, etwa Backups oder Systeme, die dort nach einem Failover laufen, wieder bei Ihnen ist. Sie sollte auch das Format nennen, in dem die Daten zurückkommen; ein Veeam-Replikat einer vSphere-VM ist „die exakte Kopie der VM im nativen VMware-vSphere-Format“. Die Löschung sollte schriftlich bestätigt werden, einschließlich aller weiteren Kopien, die der Anbieter aufbewahrt, zum Beispiel in seinen eigenen Backups.
Was wir tun
Im Rahmen unseres Service Cloud Disaster Recovery läuft der Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS), mit EU-Datenresidenz, und Replikate werden verschlüsselt übertragen und gespeichert. Unser Engineering-Partner Vixen.UNO richtet die Replikation virtueller Maschinen ab einem 15-Minuten-Intervall via Veeam Cloud Connect ein, verwaltet aus Ihrer bestehenden Veeam-Konsole oder komplett auf unserer Seite. Zum technischen Assessment gehört das Standort-Sizing, und Support, RPO und RTO sind im SLA fixiert, wobei Ihre Ziele je Systemstufe definiert werden. Planmäßige Failover-Tests laufen in isolierter Umgebung, mit einem Bericht nach jedem Test. Standort, Replikation, Tests und Support fallen unter einen Vertrag mit Eurokommerz, in dem die Subauftragsverarbeiter namentlich genannt sind, und ein Auftragsverarbeitungsvertrag ist auf Anfrage erhältlich, wie unsere Seite Sicherheit & Compliance darlegt.
FAQ
Was ist DRaaS (Disaster Recovery as a Service)?
Was ist der Unterschied zwischen DRaaS und Backup?
Was gehört auf die Checkliste vor dem Vertrag mit einem DRaaS-Anbieter?
Was sollte ein DRaaS-SLA enthalten?
Ist Kapazität für die Wiederherstellung in einem DRaaS-Vertrag reserviert?
Was passiert mit unseren Daten, wenn ein DRaaS-Vertrag endet?
Schicken Sie uns die Systeme, die Sie schützen wollen, nach Stufen gruppiert, mit RPO und RTO, die jede Stufe braucht, dazu Ihren aktuellen Aufbau für Backup und Replikation und die Fragen aus dieser Checkliste, die Ihnen am wichtigsten sind. Wir antworten innerhalb eines Werktages mit einem Termin für ein erstes Gespräch, in dem wir Ihre kritischen Systeme, Ihr aktuelles Backup und Ihre Zielwerte durchgehen, und Sie erhalten zwei oder drei mögliche DR-Szenarien. Das erste Gespräch ist kostenlos.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages