--- title: Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen description: Dieser Bericht untersucht die Bereitschaft zur Wiederherstellung nach Katastrophen (Disaster Recovery, DR) im Rahmen der Plattform Acronis Cyber Platform. Die Analyse konzentriert sich auf das erste Quartal 2026 (Januar bis März) und offenbart eine deutliche Diskrepanz zwischen der bloßen Konfiguration von DR-Maßnahmen und der tatsächlichen Einsatzbereitschaft für den Katastrophenfall. canonical_url: https://www.acronis.com/de/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/ locale: de last_updated: 2026-10-27 --- * [Startseite](https://www.acronis.com/de/tru/) * [Beiträge](https://www.acronis.com/de/tru/posts/) * [Acronis Threat Research Unit](https://www.acronis.com/de/tru/authors/acronis-threat-research-unit/) 17. Juli 2026 # Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen Dieser Bericht untersucht die Bereitschaft zur Wiederherstellung nach Katastrophen (Disaster Recovery, DR) im Rahmen der Plattform Acronis Cyber Platform. Die Analyse konzentriert sich auf das erste Quartal 2026 (Januar bis März) und offenbart eine deutliche Diskrepanz zwischen der bloßen Konfiguration von DR-Maßnahmen und der tatsächlichen Einsatzbereitschaft für den Katastrophenfall. Autor: **[Acronis Threat Research Unit](https://www.acronis.com/de/tru/authors/acronis-threat-research-unit/)** [English](https://www.acronis.com/en/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/) [Español](https://www.acronis.com/es/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/) ## Kurzfassung Dieser Bericht untersucht die Disaster-Recovery-(DR)-Bereitschaft auf der Plattform [Acronis Cyber Platform (ehemals Acronis Cyber Protect Cloud)](https://www.acronis.com/en/products/cloud/cyber-protect/), mit der [Tausende](https://www.acronis.com/de/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/)[[VZ1]](https://www.acronis.com/de/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/#_msocom_1) von DR-Bereitstellungen in Dutzenden Datenzentren auf der ganzen Welt verwaltet werden. Die Analyse konzentriert sich auf das erste Quartal 2026 (Januar bis März) und zeigt eine klare Lücke zwischen einer konfigurierten DR und der tatsächlichen Bereitschaft für einen Notfall. [Die wichtigsten Erkenntnisse sind:](https://www.acronis.com/de/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/)[[VZ2]](https://www.acronis.com/de/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/#_msocom_2) * Bei 85 % der Recovery-Server ist das RPO-Monitoring ([Recovery Point Objective](https://www.acronis.com/en/blog/posts/rto-rpo/)) deaktiviert, was bedeutet, dass nicht automatisch geprüft wird, ob die Backups aktuell genug sind. * 82 % der Backup-Verarbeitungsregeln haben keinen automatisierten Testplan. Nur 18 % führen monatliche Tests durch. Wir bei Acronis empfehlen, alle sechs Monate Test-Failover durchzuführen. * VPN-bezogene Alarme sind die größte Alarmgruppe auf der Plattform. Im ersten Quartal 2026 machten sie 35,4 % aller DR-Alarme aus – die größte Gruppe –, gefolgt von Warnungen zu Backup-Anmeldedaten mit 34,7 %. Einfach ausgedrückt: Viele Organisationen haben Disaster Recovery eingerichtet, aber die Daten zeigen, dass ein großer Teil dieser Setups nie getestet wurde und Verbindungsprobleme aufweist, die verhindern könnten, dass sie in einem echten Notfall funktionieren. ## Das versteckte Risiko bei Disaster Recovery Für Managed Service Provider (MSPs) und kleine und mittlere Unternehmen (KMU) steht weiterhin besonders viel auf dem Spiel. Aktuelle Forschung zeigt: Der Markt für Disaster-Recovery-Lösungen wurde 2025 auf 23,55 Milliarden US-Dollar geschätzt und soll bis 2029 70,03 Milliarden US-Dollar erreichen [(Research and Markets)](https://www.researchandmarkets.com/reports/6076250/disaster-recovery-solutions-market-report). In einer Umfrage von Opengear / Digi aus dem Jahr 2025 gaben 84 % der Unternehmen an, in den letzten zwei Jahren mehr Netzwerkausfälle erlebt zu haben [(Digi)](https://www.digi.com/company/press-releases/2025/businesses-report-rising-network-outages). Die Ausfallanalyse des Uptime Institute für 2025 besagt, dass 16 % der Ausfälle inzwischen mehr als 1 Million US-Dollar kosten, während 54 % mehr als 100.000 US-Dollar kosten [(Uptime Institute)](https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025). FEMA berichtet, dass etwa 25 % der Unternehmen nach Katastrophen nicht wieder eröffnen [(FEMA)](https://www.fema.gov/print/pdf/node/338623). Diese Zahlen führen alle zum selben Schluss: Disaster Recovery wird immer wichtiger, Ausfälle bleiben kostspielig und häufig, und routinemäßige Tests hinken weiterhin hinterher. Dieser Bericht untersucht, ob sich dasselbe Muster in realen Plattformdaten zeigt. Der DR-Markt für MSPs und KMU weist mehrere wichtige Trends auf, die den Kontext für unsere Erkenntnisse liefern. Vorschriften wie [DSGVO](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng), [HIPAA](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308), [NIS 2](https://eur-lex.europa.eu/eli/dir/2022/2555/2022-12-27/eng) und [DORA](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32022R2554) verlangen von Organisationen zunehmend, ihre Recovery-Fähigkeiten zu dokumentieren und oftmals auch regelmäßig zu testen. Die DSGVO verlangt Maßnahmen, die die Fähigkeit gewährleisten, Verfügbarkeit und Zugang zu personenbezogenen Daten rechtzeitig wiederherzustellen, sowie einen Prozess für das regelmäßige Testen und Bewerten von Sicherheitskontrollen. HIPAA verlangt von betroffenen Einrichtungen und Geschäftspartnern, Notfallpläne vorzuhalten, darunter auch einen Disaster-Recovery-Plan sowie Verfahren für regelmäßige Tests und Überarbeitungen. NIS 2 umfasst ausdrücklich Backup-Management, Disaster Recovery und Krisenmanagement als erforderliche Maßnahmen zum Risikomanagement in der Cyber Security. DORA geht für Finanzunternehmen noch weiter, indem es Verfahren für die IKT-Geschäftskontinuität, Backup, Wiederherstellung und Recovery sowie das mindestens jährliche Testen von Plänen zur IKT-Geschäftskontinuität und von IKT-Reaktions- und Recovery-Plänen verlangt. Für MSPs, die regulierte Kunden betreuen, steigen dadurch die Anforderungen an Compliance und Verträge, wenn Recovery-Kontrollen nicht gepflegt und getestet werden. Bereitschaftsdaten deuten auf eine ähnliche Lücke zwischen Überzeugung und Umsetzung hin. Eine [Umfrage der U.S. Chamber of Commerce Foundation aus dem Jahr 2024](https://www.uschamberfoundation.org/disasters/most-small-businesses-believe-theyre-ready-for-disasters-but-only-26-actually-are-new-study-shows) ergab, dass zwar 94 % der KMU-Führungskräfte glaubten, ihr Unternehmen würde sich von einer Katastrophe erholen, aber nur 26 % tatsächlich einen Notfallwiederherstellungsplan hatten. Der [Bericht des Business Continuity Institute aus dem Jahr 2025](https://www.thebci.org/news/from-tick-box-to-practice-the-state-of-continuity-resilience-in-2025.html) besagt ebenfalls, dass sich Kontinuitätsmanager stärker auf das Einüben und Testen von Reaktions- und Recovery-Strategien konzentrieren, was bestätigt, dass die operative Validierung ein zentrales Thema bleibt. Das deckt sich mit dem Muster, das wir in unseren Plattformdaten sehen. Der Wechsel von lokaler Recovery zu cloudbasierter Recovery setzt sich ebenfalls fort. [MarketsandMarkets](https://www.marketsandmarkets.com/Market-Reports/recovery-as-a-service-market-962.html) prognostiziert, dass der globale DRaaS-Markt von 16,1 Milliarden US-Dollar im Jahr 2025 auf 46,1 Milliarden US-Dollar bis 2032 wachsen wird, bei einer kumulierten jährlichen Wachstumsrate von 16,2 %. Die MSP- und KMU-Segmente, auf die sich Acronis vorrangig konzentriert, sind in absoluten Zahlen kleiner, werden aber voraussichtlich in einem ähnlichen Tempo wachsen. Mit anderen Worten: Immer mehr Unternehmen stellen DR-Infrastruktur bereit, doch eine breitere Bereitstellung bedeutet nicht automatisch häufigere Tests. ## Das RPO-Monitoring ist weitgehend deaktiviert RPO definiert die maximal akzeptable Menge an Datenverlust, gemessen in Zeit. Ein RPO von 15 Minuten bedeutet beispielsweise, dass sich ein Unternehmen im schlimmsten Fall höchstens 15 Minuten an Datenverlust leisten kann. Das RPO-Monitoring ist der Mechanismus, der aktiv prüft, ob Backups häufig genug erfolgen, um dieses Ziel zu erreichen. Wenn RPO-Monitoring aktiviert ist, löst das System einen Alarm aus, wenn das neueste Backup eines Recovery-Servers älter ist als der konfigurierte Schwellenwert. Wenn sie deaktiviert ist, herrscht Stille – selbst wenn Backups vollständig zum Stillstand gekommen sind. Für einen MSP, der Dutzende oder Hunderte von Kundenumgebungen verwaltet, ist RPO-Monitoring eines der wichtigsten proaktiven Tools. Ohne es hat der MSP keine automatisierte Möglichkeit, zu erkennen, dass der DR-Schutz eines Kunden beeinträchtigt ist. Das Problem zeigt sich möglicherweise erst beim Failover, wenn der Kunde feststellt, dass sein letzter Recovery-Punkt mehrere Tage oder sogar Wochen alt ist. Zu diesem Zeitpunkt ist der Schaden bereits entstanden. ## Was die Daten zeigen Unsere Analyse zeigt, dass bei 85 % aller Recovery-Server auf der Plattform das RPO-Monitoring vollständig deaktiviert ist. Das bedeutet, dass für die große Mehrheit der geschützten Workloads keine automatisierte Überprüfung erfolgt, ob Backups tatsächlich rechtzeitig durchgeführt werden. ![Image 1: Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen](https://staticfiles.acronis.com/images/content/0f3a8930bb3cf2a65b3a61413dc36df7.png) **RPO-Sets** **Anteil der Recovery-Server** **RPO deaktiviert** 85,1 % **4–24 Std.** 8,1 % **<=15 Min.** 3,8 % **>24 Std.** 1,5 % **15 Min. bis 1 Std.** 0,8 % **1–4 Std.** 0,8 % Unter den 15 % der Server, bei denen das RPO-Monitoring aktiviert ist, liegt die beliebteste Einstellung im Bereich von vier bis 24 Stunden. Das ist für viele KMU-Workloads eine pragmatische Wahl, bei denen die Kosten sehr häufiger Backups (im Hinblick auf Speicher und Bandbreite) das Risiko überwiegen, einige Stunden an Daten zu verlieren. Dennoch stellt selbst diese Gruppe nur einen kleinen Teil der Gesamtzahl dar. Die Frage, die diese Daten aufwerfen, ist nicht, ob jeder Server ein 15-Minuten-RPO benötigt – das wäre für viele Workloads unrealistisch und unnötig. Die Frage ist, ob das völlige Ausbleiben von Monitoring eine bewusste Entscheidung oder einfach nur eine Standardeinstellung ist, die nie geändert wurde. Es besteht ein wichtiger Unterschied zwischen der bewussten Entscheidung, das RPO nicht zu überwachen, weil Ihr Workload kein Monitoring erfordert, und dem Ausbleiben von Monitoring, weil bei der Einrichtung niemand daran gedacht hat, es zu aktivieren. Die Plattform setzt standardmäßig auf benutzerkonfiguriertes RPO-Monitoring, was bedeutet, dass jeder Server auf Basis von anfänglichen Admin-Einstellungen startet. Da die überwiegende Mehrheit diesen Zustand nie verlässt, scheint es, dass die meisten Setup-Workflows die RPO-Konfiguration nicht als Standardschritt enthalten. ## Das Risiko für MSPs Für MSPs hat diese Erkenntnis direkte geschäftliche Auswirkungen. Wenn ein MSP einem Kunden DR-Schutz verkauft, erwartet der Kunde, dass seine Daten bis zu einem bestimmten Zeitpunkt wiederherstellbar sind. Wenn Backups unbemerkt nicht mehr laufen – aufgrund eines Netzwerkproblems, des Absturzes eines Agenten, eines Speicherproblems oder einfach einer Fehlkonfiguration – und das RPO-Monitoring nicht aktiviert ist, erfährt der MSP erst dann von dem Problem, wenn der Kunde eine Recovery benötigt. Dadurch entsteht eine Situation, in der der MSP einem unsichtbaren Risiko ausgesetzt ist. Der Kunde bezahlt für Schutz, der MSP glaubt, dass der Schutz vorhanden ist, aber in Wirklichkeit kann das letzte erfolgreiche Backup mehrere Tage alt sein. In regulierten Branchen kann das zu Compliance-Verstößen führen. In allen Branchen führt es zu Daten- und Vertrauensverlust. Die Lösung ist einfach: Aktivieren Sie bei der erstmaligen DR-Einrichtung das RPO-Monitoring mit einem sinnvollen Standard-Schwellenwert. Ein 24-Stunden-Schwellenwert ist für die meisten Workloads ein vernünftiger Ausgangspunkt – er erkennt den Fall, dass Backups vollständig zum Stillstand gekommen sind, ohne übermäßige Meldungen bei Workloads zu erzeugen, die täglich Backups erstellen. ## Automatisierte Tests bleiben die Ausnahme Wenn die IT-Branche in Jahrzehnten der Disaster Recovery eines gelernt hat, dann das: Ein nicht getesteter DR-Plan ist kein Plan. Konfigurationsabweichungen, Software-Updates, Hardwareänderungen, Netzwerk-Neukonfigurationen und einfache menschliche Fehler können unsichtbare Lücken in die DR-Kette reißen. Der einzige Weg, zu verifizieren, dass die gesamte Kette funktioniert – vom Backup über den Recovery-Punkt bis zum Start der VM und zur Netzwerkkonnektivität –, besteht darin, sie von Anfang bis Ende zu testen. Die Acronis Plattform unterstützt zwei Arten automatisierter Tests. Monatliche automatisierte Tests führen einmal im Monat einen geplanten Test-Failover durch, starten Recovery-Server in einem isolierten Testnetzwerk, prüfen, ob sie korrekt booten, und führen optional benutzerdefinierte Prüfungen des aktuellen Zustands aus. Wöchentliche Tests tun dasselbe, nur häufiger. Beide Optionen sind so konzipiert, dass sie ohne manuelles Eingreifen und ohne Auswirkungen auf die Produktion ausgeführt werden können. Trotz der Verfügbarkeit dieser Funktionen sprechen die Daten eine ganz andere Sprache, was die tatsächliche Nutzung angeht. ## Was die Daten zeigen Bei 82 % der aktiven Backup-Verarbeitungsregeln auf der Plattform ist die Planung für automatisierte Tests auf „NIE“ gesetzt. Nur 18 % sind für monatliche Tests konfiguriert und lediglich 0,2 % verwenden wöchentliche Tests. Das bedeutet, dass für die überwältigende Mehrheit der durch DR geschützten Workloads keine automatisierte Überprüfung erfolgt, ob der Recovery-Prozess tatsächlich funktioniert. ![Image 2: Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen](https://staticfiles.acronis.com/images/content/8916c7d8f27f5fddd5619a447c41f99f.png) Um das einzuordnen: Wenn ein MSP 100 durch DR geschützte Workloads verwaltet und die Plattform-Standardeinstellungen verwendet, haben ungefähr 82 dieser Workloads nie einen automatisierten Test-Failover durchlaufen. Der MSP wettet damit faktisch darauf, dass alle im Bedarfsfall funktionieren werden – eine Wette ohne Grundlage. ## Test- vs. Produktions-Failover Betrachtet man die tatsächliche Failover-Aktivität im ersten Quartal 2026, machte FAILOVER_PROD etwa 40 % aller Failover-Ereignisse auf der Plattform aus, aber die meisten dieser Ereignisse sind sehr kurz und betrieblich gesehen Testübungen. Um uns auf echte Katastrophen zu konzentrieren, beschränken wir die Ansicht auf Failover, die länger als 24 Stunden dauerten – eine Dauer, die zu einer echten Recovery statt zu einer kurzen Überprüfung oder einem Failback-Probelauf passt. ![Image 3: Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen](https://staticfiles.acronis.com/images/content/7e7aca0cacee999bca09f1a9712e08bf.png) Infolgedessen dauerten nur 0,75 % der FAILOVER_PROD-Ereignisse länger als 24 Stunden; etwa 97 % wurden in weniger als einer Stunde abgeschlossen – das sieht nach kurzen Failover-und-Failback-Übungen, Ad-hoc-Überprüfungen oder Failovern aus, die im Produktionsmodus gestartet und praktisch sofort zurückgesetzt wurden. Dasselbe Muster zeigt sich bei manuellen Test-Failovern (1,7 % dauerten mehr als 24 Std.) und ist bei automatisierten Tests sogar noch extremer (≈ 0,004 %). Fasst man alle drei Status zusammen, dauerten im ersten Quartal 2026 weniger als 1 % der Failover-Ereignisse auf der Plattform lange genug, um wie eine echte Recovery zu wirken. Die wichtigste Kennzahl ist der Anteil der Plattform, der tatsächlich betroffen war: Weniger als 0,15 % der Recovery-Server erlebten im gesamten Quartal ein anhaltendes, echtes Recovery-Ereignis – und selbst innerhalb der Menge an VMs, die im ersten Quartal überhaupt mit FAILOVER_PROD in Berührung kamen, hatten nur etwa 25 % ein Ereignis, das länger als 24 Stunden dauerte. Wenn diese wenigen echten Katastrophen Workloads treffen, die nie getestet wurden, ist die Recovery ein erstes Experiment unter Druck. ## Die Kosten des Nichttestens Die Branchendaten zu diesem Thema sind eindeutig. Organisationen, die ihre DR regelmäßig testen, haben deutlich kürzere Recovery-Zeiten und höhere Erfolgsquoten als diejenigen, die das nicht tun. Eine Studie des Disaster Recovery Preparedness Council aus dem Jahr 2024 ergab, dass Organisationen, die DR monatlich testen, eine Recovery-Erfolgsquote beim ersten Versuch von 92 % erreichten, verglichen mit 54 % bei Organisationen, die jährlich oder seltener testen. Für MSPs ist die Rechnung ganz einfach. Die Kosten für einen monatlichen automatisierten Test sind minimal – die Plattform übernimmt das automatisch und verwendet isolierte Test-Netzwerke, die die Produktion nicht beeinflussen. Andererseits können die Kosten einer fehlgeschlagenen Recovery während einer echten Katastrophe verheerend sein: verlorene Kundendaten, SLA-Strafen, Rufschäden und in einigen Fällen rechtliche Haftung nach Datenschutzvorschriften. Wir sind der Ansicht, dass die niedrige Testrate in erster Linie auf die Konfiguration und nicht auf eine bewusste Entscheidung der MSPs zurückzuführen ist. Wenn DR eingerichtet wird, ist das Testen optional und standardmäßig deaktiviert. In einer geschäftigen MSP-Umgebung, in der das Onboarding eines neuen Kunden viele Schritte umfasst, wird die Testkonfiguration leicht übersehen. ## Alarmmuster decken systemische Probleme auf Jeder von der Plattform generierte DR-bezogene Alarm ist ein Signal dafür, dass in der Disaster-Recovery-Umgebung etwas Ihre Aufmerksamkeit benötigt. Einige Alarme sind rein informativ – zum Beispiel die Benachrichtigung, dass eine Failback-Operation erfolgreich abgeschlossen wurde. Andere sind kritische Warnungen, dass eine wichtige Komponente ausgefallen ist. Durch die Analyse der Verteilung und Trends dieser Alarme können wir ein Bild des allgemeinen Zustands der DR-Umgebung erstellen und systemische Probleme identifizieren, die viele Kunden gleichzeitig betreffen. ## Top-Alarmtypen im ersten Quartal 2026 Das untenstehende Diagramm zeigt die 10 wichtigsten DR-Alarmtypen im ersten Quartal 2026, gemessen als Anteil an allen DR-Alarmen: ![Image 4: Warum die meisten DR-Bereitstellungen einen echten Notfall möglicherweise nicht überstehen](https://staticfiles.acronis.com/images/content/79b4796a5fffe52b412afe03defdf629.png) Mehrere Muster sind sofort erkennbar. VPN-bezogene Alarme (VpnUnreachable, VpnConnectionFailure) dominieren das Alarmgeschehen und bestätigen die im vorherigen Abschnitt beschriebenen Konnektivitätsprobleme. Dabei handelt es sich nicht um einmalige Ereignisse, sondern um anhaltende, wiederkehrende Probleme, die jeden Monat eine erhebliche Anzahl von Bereitstellungen betreffen. Der zweite Cluster bemerkenswerter Alarme bezieht sich auf Fehler beim automatisierten Testen. BackupProcessorAutoTestFailoverTimeoutReached und BackupProcessorAutoTestFailoverOverallFailure weisen darauf hin, dass selbst bei der Minderheit der Workloads, bei denen automatisiertes Testen aktiviert ist, ein bedeutender Anteil der Tests fehlschlägt. Das bedeutet, dass die tatsächliche „funktionsfähig und getestet“-Rate noch kleiner ist als die 18 %, bei denen Tests konfiguriert sind. Der Alarm DRPolicyFailedCreateRecoveryServer (kritischer Schweregrad) weist auf Fälle hin, in denen das System überhaupt keinen Recovery-Server erstellen konnte. Das ist die schwerwiegendste Art von Bereitschaftsfehlern – nicht nur wurde DR nicht getestet, sondern die für die Recovery erforderliche grundlegende Infrastruktur existiert nicht. Bei Acronis wird das kontinuierlich im Rahmen von Forschung und Entwicklung überwacht, und jeder Ausfall wird untersucht. ## Task-Fehlerraten Ergänzend zu den Alarmdaten haben wir im ersten Quartal 2026 auch die Ausführungsergebnisse von DR-Tasks untersucht. Tasks stehen für bestimmte von der Plattform ausgeführte Operationen (Backup, Failover, Erstellung eines Recovery-Servers usw.) und jeder Task hat ein Ergebnis: Erfolg oder Fehler: **Task-Typ** **Anteil an gesamten DR-Fehlern** **Failback-Datenübertragung fortsetzen** 46,8 % **Mandant löschen** 46,4 % **Failover** 1,5 % **VM-Backup** 1,5 % **Bereitstellungstyp wechseln** 0,9 % **Test-Failover** 0,9 % **Einschalten** 0,5 % **Backup-Prozessor-Test-Backup** 0,5 % **Andere dr_*-Task-Typen (37)** 1 % **Gesamte DR-Fehler (erstes Quartal 2026)** **100 %** _Abfrage: SELECT type, result\_code, count(*) as cnt FROM tasks WHERE type LIKE 'dr\_%' AND created\_at >= '2026-01-01' AND created\_at < '2026-04-01' GROUP BY type, result\_code ORDER BY cnt DESC_ Zwei Task-Typen dominieren das gesamte DR-Fehlervolumen im ersten Quartal 2026: dr_failback_data_transfer_resume (252.929 Fehler, 46,8 % aller DR-Fehler) und dr_delete_tenant (251.173 Fehler, 46,4 %). Zusammen machen diese beiden rund 93 % der 540.909 im Quartal erfassten DR-Task-Fehler aus. Diese beiden ausgenommen, tragen die verbleibenden 43 Task-Typen mit Fehlern zusammen 6,8 % zu den DR-Fehlern bei. Für MSPs liegt die praktische Schlussfolgerung darin, dass Failback- und Mandanten-Löschungen als wichtigste Fehlerquellen untersucht werden sollten, während Routinevorgänge wie Failover, Einschalten und Test-Failover weiterhin auf ihren Abschluss überwacht werden sollten. ## Schweregradtrends im Lauf der Zeit Die Verteilung der Schweregrade von DR-Alarmen ist in den letzten sechs Monaten relativ stabil geblieben: ![Image 5: Query: SELECT date_format(created_at, 'yyyy-MM') as month, severity, count(*) as cnt FROM alerts WHERE category = 'Disaster recovery' AND created_at >= '2025-10-01' AND created_at < '2026-04-01' GROUP BY month, severity ORDER BY month](https://staticfiles.acronis.com/images/content/200e175485796bd3be0f5b6d4d7ffc80.png) Query: SELECT date_format(created_at, 'yyyy-MM') as month, severity, count(*) as cnt FROM alerts WHERE category = 'Disaster recovery' AND created_at >= '2025-10-01' AND created_at < '2026-04-01' GROUP BY month, severity ORDER BY month Die Beständigkeit dieses Musters ist an sich bereits aufschlussreich. Eine stabile Verteilung der Schweregrade bedeutet, dass sich die zugrunde liegenden Probleme nicht verschlimmern, aber auch nicht verbessern. Die gleichen Problemarten – VPN-Trennungen, Testfehler, Fehler bei der Servererstellung – treten Monat für Monat ungefähr in derselben Rate auf. Das weist eher auf strukturelle Ursachen (Standardkonfigurationen, operative blinde Flecken) als auf einmalige Vorfälle oder saisonale Muster hin. Für Produktteams stellt diese Stabilität eine Chance dar. Da die Probleme vorhersehbar und wiederkehrend sind, werden gezielte Maßnahmen (bessere Standardwerte, proaktive Alarme, Änderungen beim Onboarding) wahrscheinlich messbare und nachhaltige Auswirkungen haben. Für MSPs bedeutet der stabile Charakter dieser Alarme, dass sie durch systematische Prüfverfahren und nicht mit reaktivem Krisenmanagement angegangen werden können. ## Wachstum überholt die Bereitschaft Um die Erkenntnisse zusammenzuführen, haben wir einen einfachen Bereitschafts-Score auf Basis dieser Faktoren erstellt: RPO-Monitoring (ist es aktiviert?), automatisierte Tests (sind sie eingeplant?) und VPN-Konnektivität (ist der Tunnel aktiv?). Jeder Faktor ist binär – entweder erfüllt ein Server oder eine Bereitstellung die Mindestanforderung oder nicht. **Bereitschaftsfaktor** **Aktiviert** **Deaktiviert** **RPO-Monitoring** 14,9 % 85,1 % **Automatisierte Tests** 17,8 % 82,2 % Diese Tabelle zeigt, dass bei allen drei Bereitschaftsfaktoren die Gruppe „nicht bereit“ deutlich größer ist als die Gruppe „bereit“. Obwohl diese Faktoren unabhängig voneinander gemessen werden (eine einzelne Bereitstellung könnte in einem Bereich gut konfiguriert und in einem anderen schlecht konfiguriert sein), zeigt das Gesamtbild, dass eine Bereitschaft eher die Ausnahme als die Regel ist. Die oben genannten Risiken wirken zusammen. Betrachten Sie ein Szenario, in dem der Produktionsserver eines Kunden ausfällt und ein Failover in die Cloud erforderlich ist. Wenn das RPO-Monitoring deaktiviert ist, weiß der Kunde möglicherweise nicht, dass sein letzter Recovery-Punkt drei Tage statt drei Stunden alt ist. Wenn keine automatisierten Tests konfiguriert wurden, weiß niemand, ob der Recovery-Server tatsächlich booten und korrekt funktionieren wird. Jede einzelne Lücke verringert die Wahrscheinlichkeit einer erfolgreichen Recovery. Wenn mehrere Lücken gleichzeitig bestehen, sinkt die Wahrscheinlichkeit noch weiter. ## Was das für den Markt bedeutet Die Lücke zwischen Bereitstellung und Bereitschaft ist nicht auf eine einzelne Plattform oder einen einzelnen Anbieter beschränkt. Sie spiegelt ein breiteres Muster innerhalb der Branche wider, bei dem die Dringlichkeit, „DR zu haben“ (getrieben durch Vertrieb, Compliance oder Angst), die Disziplin überholt, „DR zu pflegen“ (was fortlaufenden Aufwand, Tests und Aufmerksamkeit erfordert). Da der DR-Markt weiter wächst, dürfte sich die Bereitschaftslücke vergrößern, sofern sich die Branche nicht dahin entwickelt, Best Practices für die Bereitschaft automatisch und zum Standard zu machen statt optional und manuell. MSPs sind in der einzigartigen Position, diese Lücke zu schließen, da sie DR im Auftrag ihrer Kunden verwalten. Ein einzelner MSP, der seine Onboarding- und Monitoring-Prozesse verbessert, kann die Bereitschaft für Hunderte oder Tausende von Endkunden-Workloads erhöhen. Hier ist der Hebel am größten und genau hier setzen die Empfehlungen im nächsten Abschnitt an. ## Fazit und Empfehlungen Diese Analyse der Acronis-Telemetrie für Plattformdaten aus dem ersten Quartal 2026 zeigt eine erhebliche Lücke zwischen DR-Bereitstellung und DR-Bereitschaft. Während die Zahl der Organisationen, die Disaster Recovery einsetzen, weiterhin schnell wächst, belegen die Daten, dass die Mehrheit dieser Bereitstellungen grundlegende Bereitschaftsprobleme hat, die verhindern könnten, dass sie im Ernstfall funktionieren. Die zwei Hauptbereiche mit Handlungsbedarf sind: * **RPO-Monitoring:** Bei 85 Prozent der Recovery-Server ist kein RPO-Monitoring konfiguriert. Das bedeutet, dass niemand automatisch benachrichtigt wird, wenn Backups nicht mehr laufen oder hinter der Planung zurückbleiben. Für Unternehmen, die zum Schutz vor Datenverlust auf DR angewiesen sind, ist das so, als hätte man einen Rauchmelder ohne Batterie. Das Gerät ist installiert, aber es wird Sie nicht alarmieren, wenn es brennt. Die überwältigende Größe dieser Zahl deutet darauf hin, dass es sich eher um ein Problem der Standardkonfiguration als um eine bewusste Entscheidung handelt. RPO-Monitoring standardmäßig zu aktivieren, mit einer sinnvollen 24-Stunden-Schwelle, würde diese Lücke für alle neuen Bereitstellungen sofort schließen und sollte als hochpriorisierte Produktänderung betrachtet werden. * **Automatisierte Tests:** 82 Prozent der DR-Backup-Regeln haben keinen automatisierten Testplan. Branchenspezifische Best Practices empfehlen mindestens monatliche DR-Tests, dennoch sind nur 18 % der Regeln für monatliche Tests und weniger als 0,2 % für wöchentliche Tests konfiguriert. Ohne regelmäßige Tests können Konfigurationsfehler, Software-Updates und Infrastrukturänderungen die DR-Kette unbemerkt unterbrechen. Oft stellen Organisationen erst bei einem tatsächlichen Notfall fest, dass ihre DR nicht funktioniert – der schlechteste Zeitpunkt, um das herauszufinden. Darüber hinaus schlägt selbst bei den Workloads, für die Tests aktiviert sind, ein erheblicher Anteil dieser Tests fehl, wie die Alarme für fehlgeschlagene Auto-Tests zeigen. Das bedeutet, dass der tatsächliche Anteil der Systeme mit dem Prädikat „funktionsfähig und getestet“ noch kleiner ist. Die Kombination aus geringer Verbreitung von Tests und nicht unerheblichen Testfehlerquoten führt zu einer Situation, in der das Vertrauen in die DR-Bereitschaft deutlich geringer sein sollte, als sie es normalerweise ist. ## Auswirkungen auf Ihr Geschäft. Für MSPs, die DR für ihre Kunden verwalten, stellen diese Erkenntnisse sowohl ein Risiko als auch eine Chance dar. Das Risiko ist klar: Ein MSP, dessen Kunde von einem Notfall betroffen ist und feststellt, dass die DR nicht funktioniert, sieht sich mit Rufschäden, möglicher rechtlicher Haftung und dem Verlust des Kunden konfrontiert. In regulierten Branchen können die Folgen bis zu Bußgeldern und Compliance-Maßnahmen reichen, die sowohl den MSP als auch den Endkunden betreffen. Die Chance ist ebenso klar: MSPs, die Bereitschaftslücken proaktiv identifizieren und beheben, können sich durch nachweislich hohe Zuverlässigkeit differenzieren. Ein MSP, der einem Kunden einen monatlichen Bericht über erfolgreiche Test-Failover, aktive VPN-Verbindungen und die Einhaltung des RPO vorlegen kann, liefert einen greifbaren, belegbaren Mehrwert. In einem umkämpften Markt, in dem viele MSPs ähnliche Services zu ähnlichen Preisen anbieten, wird der Nachweis der Bereitschaft zu einem starken Unterscheidungsmerkmal. Für KMU ist die Botschaft einfach: DR konfiguriert zu haben ist nicht dasselbe wie geschützt zu sein. Ein DR-Setup, das nie getestet wurde und VPN-Konnektivitätsprobleme aufweist, vermittelt ein falsches Gefühl von Sicherheit, das sich bei einem echten Vorfall als kostspielig erweisen könnte. Die richtige Frage, die Sie Ihrem MSP stellen sollten, lautet nicht „Habe ich DR?“, sondern „Wann wurde meine DR zuletzt getestet und war der Test erfolgreich?“ ## Empfehlungen für MSPs und Service Provider ·Aktivieren Sie für alle Recovery-Server das RPO-Monitoring mit geeigneten Schwellenwerten basierend auf den SLAs des Kunden. Die Plattform unterstützt das nativ – es muss nur aktiviert werden. Ein Schwellenwert von 24 Stunden ist ein sicherer Ausgangspunkt für die meisten Workloads. ·Konfigurieren Sie für alle durch DR geschützten Workloads mindestens monatliche automatisierte Test-Failover. Das ist die wirkungsvollste Änderung, die MSPs vornehmen können, um die DR-Bereitschaft zu verbessern. Überprüfen Sie die Testergebnisse monatlich und gehen Sie Fehlschlägen nach. ·Überprüfen Sie regelmäßig den Status der VPN-Tunnel und ziehen Sie wenn möglich die Migration von Kunden-Router-Bereitstellungen in den VPN-Appliance-Modus in Betracht, da die Daten deutlich bessere Konnektivitätsraten zeigen. ·Erstellen Sie DR-Bereitschafts-Dashboards, die die Einhaltung von RPOs, Erfolgsraten von Tests und VPN-Konnektivität über alle verwalteten Kunden hinweg verfolgen. Verwenden Sie diese Dashboards in vierteljährlichen Geschäftsgesprächen mit Ihren Kunden. * Nehmen Sie die Ergebnisse der DR-Tests in die regelmäßige Berichterstellung für Kunden auf, um Vertrauen aufzubauen und Ihren Wert zu demonstrieren. Ein Kunde, der monatlich den Nachweis sieht, dass seine DR funktioniert, ist ein Kunde, der seinen Vertrag verlängert. * Erwägen Sie, das RPO-Monitoring für neue Recovery-Server mit einem angemessenen Standard-Schwellenwert (z. B. 24 Stunden) standardmäßig zu aktivieren. Für Sicherheitsfunktionen ist Opt-out besser als Opt-in. * Fügen Sie der Management-Konsole einen „DR-Bereitschafts-Score“ hinzu, der den Status von RPO-Monitoring, Tests und Konnektivität in einer einzigen, leicht verständlichen Kennzahl zusammenfasst. Zeigen Sie ihn prominent auf dem Dashboard an. * Implementieren Sie automatische Benachrichtigungen, wenn VPN-Tunnel länger als 24 Stunden getrennt sind. Sorgen Sie dafür, dass diese Benachrichtigungen nicht zu übersehen sind. * Bieten Sie ein geführtes Onboarding an, das die Konfiguration automatisierter Test-Failover als notwendigen Schritt und nicht nur optional vorsieht. Führen Sie MSPs während des initialen DR-Deployments durch das Test-Setup. * Erstellen Sie Berichtsvorlagen, die MSPs dabei helfen, ihren Kunden den DR-Bereitschaftsstatus in einfachen, nichttechnischen Begriffen zu vermitteln. Wenn Sie ein Endkunde (KMU) sind: Bitten Sie Ihren MSP um einen Nachweis, dass Ihre DR kürzlich getestet wurde. Eine einfache Frage, „Wann war der letzte erfolgreiche Test-Failover?“, kann viel über Ihr tatsächliches Schutzniveau verraten. Verstehen Sie Ihre RPO- und RTO-Ziele und überprüfen Sie, ob sie zu Ihren geschäftlichen Anforderungen passen. Die Standardwerte sind möglicherweise nicht für Ihre spezifischen Anforderungen geeignet. Wenn Ihr Unternehmen in einer regulierten Branche tätig ist, sorgen Sie dafür, dass die Häufigkeit Ihrer DR-Tests die Compliance-Anforderungen erfüllt. Viele Vorschriften verlangen inzwischen dokumentierte Nachweise regelmäßiger Tests. Verwandte Artikel [Acronis Cyberthreats Update, Juli 2026](https://www.acronis.com/de/tru/posts/acronis-cyberthreats-update-july-2026/) [Acronis Cyberthreats Update, April 2026](https://www.acronis.com/de/tru/posts/acronis-cyberthreats-update-april-2026/) [Acronis Cyberthreats Update, Juni 2026](https://www.acronis.com/de/tru/posts/acronis-cyberthreats-update-june-2026/) [Acronis Cyberthreats Update, Mai 2026](https://www.acronis.com/de/tru/posts/acronis-cyberthreats-update-may-2026/)