---
title: Why most DR deployments may not survive a real disaster
description: This report examines the disaster recovery (DR) readiness across the Acronis Cyber Platform platform, managing thousands of DR deployments across dozens of data centers worldwide. The analysis focuses on Q1 2026 (January – March) and reveals a clear gap between having DR configured and being truly ready for a disaster.
canonical_url: https://www.acronis.com/en/tru/posts/why-most-dr-deployments-may-not-survive-a-real-disaster/
locale: en
last_updated: 2026-10-27
---

*   [Home](https://www.acronis.com/en/tru/)
*   [Articles](https://www.acronis.com/en/tru/posts/)
*   [Acronis Threat Research Unit](https://www.acronis.com/en/tru/authors/acronis-threat-research-unit/)

01 June 2026

# Why most DR deployments may not survive a real disaster

This report examines the disaster recovery (DR) readiness across the Acronis Cyber Platform platform, managing thousands of DR deployments across dozens of data centers worldwide. The analysis focuses on Q1 2026 (January – March) and reveals a clear gap between having DR configured and being truly ready for a disaster.

Author: **[Acronis Threat Research Unit](https://www.acronis.com/en/tru/authors/acronis-threat-research-unit/)**

Other languages available:[Deutsch](https://www.acronis.com/de/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/)

**Author: Alexander Ivanyuk**, Senior Director, Technology

## Executive summary

This report examines the disaster recovery (DR) readiness across the Acronis Cyber Platform (formerly Acronis Cyber Protect Cloud) platform, managing thousands of DR deployments across dozens of data centers worldwide. The analysis focuses on Q1 2026 (January – March) and reveals a clear gap between having DR configured and being truly ready for a disaster.

### The key findings are:

*   Eighty-five percent of recovery servers have RPO ([recovery point objective](https://www.acronis.com/en/blog/posts/rto-rpo/)) monitoring turned off, meaning there is no automatic check on whether backups are recent enough. 

*   Eighty-two percent of backup processor rules have no automated test schedule. Only 18% run monthly tests. We at Acronis have a recommendation to perform test failovers every six months.

*   VPN-related alerts are the largest alert family on the platform. In Q1 2026 they accounted for 35.4% of all DR alerts — the biggest group — followed by backup-credentials warnings at 34.7%.

In simple terms, many organizations have configured disaster recovery, but the data shows that a large portion of these setups have never been tested and have connectivity issues that could prevent them from working during a real emergency.

## The hidden risk in disaster recovery

For managed service providers (MSPs) and small-to-medium businesses (SMBs), the stakes remain especially high. Recent research shows:

The disaster recovery solutions market was valued at $23.55 billion in 2025 and is [projected to reach $70.03 billion by 2029](https://www.researchandmarkets.com/reports/6076250/disaster-recovery-solutions-market-report).

In a [2025 Opengear / Digi survey](https://www.digi.com/company/press-releases/2025/businesses-report-rising-network-outages), 84% of businesses said they had seen network outages increase over the past two years. [Uptime Institute’s 2025 outage analysis](https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025) says 16% of outages now cost more than $1 million, while 54% cost more than $100,000.

[FEMA reports](https://www.fema.gov/print/pdf/node/338623) that about 25% of businesses do not reopen after disasters.

These figures point to the same conclusion: Disaster recovery is a growing priority, outages remain costly and common, and routine testing is still lagging. This report examines whether that same pattern is visible in real platform data.

The DR market for MSPs and SMBs has several important trends that provide context for our findings. Regulations such as GDPR, HIPAA, NIS 2 and DORA increasingly require organizations to document recovery capabilities and, in several cases, test them regularly. GDPR requires measures that ensure the ability to restore the availability of and access to personal data in a timely manner and a process for regularly testing and evaluating security controls.

HIPAA requires covered entities and business associates to maintain contingency plans, including a [disaster recovery plan and periodic testing and revision procedures](https://www.acronis.com/en/blog/posts/how-to-test-your-disaster-recovery-plan/). NIS 2 explicitly includes backup management, disaster recovery and crisis management among required cybersecurity risk-management measures. DORA goes further for financial entities by requiring ICT business continuity, backup, restoration, and recovery procedures, and testing of ICT business continuity plans and ICT response and recovery plans at least yearly. For MSPs serving regulated customers, that raises the compliance and contractual stakes when recovery controls are not maintained and tested.

Preparedness data also points to a similar gap between confidence and execution. A [2024 U.S. Chamber of Commerce Foundation survey](https://www.uschamberfoundation.org/disasters/most-small-businesses-believe-theyre-ready-for-disasters-but-only-26-actually-are-new-study-shows) found that while 94% of SMB leaders believed their business would recover from a disaster, only 26% had an actual disaster plan in place. The [Business Continuity Institute’s 2025 report](https://www.thebci.org/news/from-tick-box-to-practice-the-state-of-continuity-resilience-in-2025.html) likewise says continuity managers are focusing more on exercising and testing response and recovery strategies, reinforcing that operational validation remains a central issue. This matches the pattern we see in our platform data.

The shift from on-premises recovery to cloud-based recovery also continues. [MarketsandMarkets](https://www.marketsandmarkets.com/Market-Reports/recovery-as-a-service-market-962.html) projects that the global DRaaS market will grow from $16.1 billion in 2025 to $46.1 billion by 2032, at a 16.2% CAGR. The MSP and SMB segments, which are the primary focus of Acronis, are smaller in absolute size but are expected to grow at a similar pace. In other words, more businesses are deploying DR infrastructure, but wider deployment does not automatically mean more frequent testing.

## RPO monitoring is largely disabled

RPO defines the maximum acceptable amount of data loss measured in time. For example, an RPO of 15 minutes means that in a worst-case disaster scenario, the business can afford to lose at most 15 minutes of data. RPO monitoring is the mechanism that actively checks whether backups are happening often enough to meet this target. When RPO monitoring is enabled, the system will generate an alert if a recovery server's most recent backup is older than the configured threshold. When it is disabled, there is silence — even if backups have stopped entirely.

For an MSP managing dozens or hundreds of client environments, RPO monitoring is one of the most important proactive tools available. Without it, the MSP has no automated way to know that a client's DR protection has degraded. The problem may only surface during failover, when the client discovers that their most recent recovery point is days or even weeks old. At that point, the damage has already been done.

## What the data shows

Our analysis shows that 85% of all recovery servers on the platform have RPO monitoring completely disabled. This means that for the vast majority of protected workloads, there is no automated verification that backups are actually happening on time.

![Image 1: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/0f3a8930bb3cf2a65b3a61413dc36df7.png)

Among the 15% of servers that do have RPO monitoring enabled, the most popular setting falls in the four to 24-hour range. This is a pragmatic choice for many SMB workloads where the cost of very frequent backups (in terms of storage and bandwidth) outweighs the risk of losing a few hours of data. However, even this group represents a small fraction of the total.

The question that this data raises is not whether every server needs a 15-minute RPO — that would be unrealistic and unnecessary for many workloads. The question is whether having no monitoring at all is an intentional decision or simply a default that was never changed.

There is an important difference between choosing not to monitor RPO because your workload does not require it, and not monitoring because no one remembered to enable it during setup. The platform defaults on user configured RPO monitoring, which means that every server starts based on initial admin settings. Given that the vast majority never leave that state, it appears that most setup workflows do not include RPO configuration as a standard step.

## The risk for MSPs

For MSPs, this finding has direct business implications. When an MSP sells DR protection to a client, the client expects that their data will be recoverable up to a certain point in time. If backups silently stop running — due to a network issue, an agent crash, a storage problem, or simply a misconfiguration — and RPO monitoring is not enabled, the MSP will not know about the problem until the client needs to recover.

This creates a situation where the MSP is exposed to a risk they cannot see. The client is paying for protection, the MSP believes the protection is in place, but in reality, the last successful backup may be days old. In regulated industries, this can lead to compliance violations. In all industries, it leads to data loss and damaged trust.

The fix is straightforward: enable RPO monitoring with a sensible default threshold during the initial DR setup. A 24-hour threshold is a reasonable starting point for most workloads — it catches the case where backups have completely stopped without generating excessive noise for workloads that back up daily.

## Automated testing remains the exception

If there is one lesson that the IT industry has learned over decades of disaster recovery, it is this: an untested DR plan is not a plan. Configuration drift, software updates, hardware changes, network reconfigurations, and simple human error can all introduce invisible breaks in the DR chain. The only way to verify that the entire chain works — from backup to recovery point to VM spin-up to network connectivity — is to test it end to end.

The Acronis platform supports two types of automated testing. Monthly automated tests run a scheduled test failover once a month, spinning up recovery servers in an isolated test network, verifying that they boot correctly, and optionally running custom health checks. Weekly tests do the same but more frequently. Both options are designed to run without manual intervention and without impacting production.

Despite the availability of these features, the data tells a very different story about actual adoption.

## What the data shows

A full 82% of active backup processor rules on the platform have their automated testing schedule set to "NEVER." Only 18% are configured for monthly testing, and a mere 0.2% use weekly testing. This means that for the overwhelming majority of DR-protected workloads, there is no automated verification that the recovery process actually works.

![Image 2: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/8916c7d8f27f5fddd5619a447c41f99f.png)

To put this into perspective: If an MSP manages 100 DR-protected workloads and uses the platform defaults, approximately 82 of those workloads have never had an automated test failover. The MSP is, in effect, making a bet that all of them will work when needed — a bet made without evidence.

## Test vs. production failovers

Looking at actual failover activity during Q1 2026, FAILOVER_PROD accounted for about 40% of all failover events on the platform, but most of these events are very short and operationally were test drills. To isolate genuine disasters, we restrict the view to failovers that lasted more than 24 hours — a duration consistent with a real recovery rather than a quick verification or failback rehearsal.

![Image 3: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/7e7aca0cacee999bca09f1a9712e08bf.png)

As a result, only 0.75% of FAILOVER_PROD events lasted more than 24 hours; about 97% completed in under one hour — these look like short failover-and-failback drills, ad-hoc verifications or failovers initiated in production mode and rolled back almost immediately. The same pattern holds for manual test failovers (1.7% lasted >24 h) and is even more extreme for automated tests (≈0.004%). Aggregating across all three statuses, fewer than 1% of failover events on the platform during Q1 2026 lasted long enough to look like a real recovery.

The figure that matters most is the share of the platform actually affected: Fewer than 0.15% of recovery servers experienced a sustained, real recovery event during the entire quarter — and even within the population of VMs that touched FAILOVER_PROD at all in Q1, only about 25% had an event that lasted more than 24 hours.

When these few real disasters strike workloads that have never been tested, the recovery is a first-time experiment performed under pressure.

## The cost of not testing

The industry data on this topic is clear. Organizations that test their DR regularly have significantly shorter recovery times and higher success rates than those that do not. A 2024 study by the Disaster Recovery Preparedness Council found that organizations testing DR monthly achieved 92% first-attempt recovery success, compared to 54% for those testing annually or less.

For MSPs, the math is straightforward. The cost of running a monthly automated test is minimal — the platform handles it automatically, using isolated test networks that do not affect production. On the other hand, the cost of a failed recovery during a real disaster can be catastrophic: lost client data, SLA penalties, reputational damage and, in some cases, legal liability under data protection regulations.

We believe the low testing adoption rate is primarily a result of the configuration rather than a deliberate choice by MSPs. When DR is set up, testing is optional and defaults to off. In a busy MSP environment where onboarding a new client involves many steps, the testing configuration is easily overlooked.

## Alert patterns reveal systemic issues

Every DR-related alert generated by the platform is a signal that something in the disaster recovery environment needs attention. Some alerts are informational — for example, notifying that a failback operation completed successfully. Others are critical warnings that a key component has failed. By analyzing the distribution and trends of these alerts, we can build a picture of the overall health of the DR environment and identify systemic issues that affect many customers simultaneously.

## Top alert types in Q1 2026

The chart below shows the top 10 DR alert types during Q1 2026, measured as a percentage of all DR alerts:

![Image 4: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/79b4796a5fffe52b412afe03defdf629.png)

As a result, only 0.75% of FAILOVER_PROD events lasted more than 24 hours; about 97% completed in under one hour — these look like short failover-and-failback drills, ad-hoc verifications or failovers initiated in production mode and rolled back almost immediately. The same pattern holds for manual test failovers (1.7% lasted >24 h) and is even more extreme for automated tests (≈0.004%). Aggregating across all three statuses, fewer than 1% of failover events on the platform during Q1 2026 lasted long enough to look like a real recovery.

The figure that matters most is the share of the platform actually affected: Fewer than 0.15% of recovery servers experienced a sustained, real recovery event during the entire quarter — and even within the population of VMs that touched FAILOVER_PROD at all in Q1, only about 25% had an event that lasted more than 24 hours.

When these few real disasters strike workloads that have never been tested, the recovery is a first-time experiment performed under pressure.

## The cost of not testing

The industry data on this topic is clear. Organizations that test their DR regularly have significantly shorter recovery times and higher success rates than those that do not. A 2024 study by the Disaster Recovery Preparedness Council found that organizations testing DR monthly achieved 92% first-attempt recovery success, compared to 54% for those testing annually or less.

For MSPs, the math is straightforward. The cost of running a monthly automated test is minimal — the platform handles it automatically, using isolated test networks that do not affect production. On the other hand, the cost of a failed recovery during a real disaster can be catastrophic: lost client data, SLA penalties, reputational damage and, in some cases, legal liability under data protection regulations.

We believe the low testing adoption rate is primarily a result of the configuration rather than a deliberate choice by MSPs. When DR is set up, testing is optional and defaults to off. In a busy MSP environment where onboarding a new client involves many steps, the testing configuration is easily overlooked.

## Alert patterns reveal systemic issues

Every DR-related alert generated by the platform is a signal that something in the disaster recovery environment needs attention. Some alerts are informational — for example, notifying that a failback operation completed successfully. Others are critical warnings that a key component has failed. By analyzing the distribution and trends of these alerts, we can build a picture of the overall health of the DR environment and identify systemic issues that affect many customers simultaneously.

## Top alert types in Q1 2026

The chart below shows the top 10 DR alert types during Q1 2026, measured as a percentage of all DR alerts:

![Image 5: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/b16aa11f6b6c7a3b3feb6a1393e5882d.png)

Two task types dominate the total DR error volume in Q1 2026: dr_failback_data_transfer_resume (252,929 errors, 46.8% of all DR errors) and dr_delete_tenant (251,173 errors, 46.4%). Together, these two account for roughly 93% of the 540,909 DR task errors recorded during the quarter. Outside these two, the remaining 43 task types with errors together contribute 6.8% of DR errors. For MSPs, the practical implication is that failback and tenant-deletion flows should be investigated as the top error sources, while routine operations such as failover, power on and test failover should continue to be monitored for completion.

## Severity trends over time

The severity mix of DR alerts has been relatively stable over the past six months:

![Image 6: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/200e175485796bd3be0f5b6d4d7ffc80.png)

The consistency of this pattern is itself informative. A stable severity distribution means that the underlying issues are not getting worse, but they are also not getting better. The same types of problems — VPN disconnections, test failures, server creation failures — recur month after month at roughly the same rate. This points to structural causes (default configurations, operational blind spots) rather than one-time incidents or seasonal patterns.

For product teams, this stability represents an opportunity. Because the problems are predictable and recurring, targeted interventions (better defaults, proactive alerts, onboarding changes) are likely to have a measurable and lasting impact. For MSPs, the steady-state nature of these alerts means they can be addressed through systematic review processes rather than reactive firefighting.

## Growth outpaces readiness

To bring the findings together, we created a simple readiness composite based on these dimensions: RPO monitoring (is it enabled?), automated testing (is it scheduled?) and VPN connectivity (is the tunnel active?). Each dimension is binary — a server or deployment either meets the minimum bar or it does not.

![Image 7: Why most DR deployments may not survive a real disaster](https://staticfiles.acronis.com/images/content/0f026d187b032ceab90fe74cabb8c480.png)

This table shows that across all three readiness dimensions, the "not ready" group is significantly larger than the "ready" group. While these dimensions are measured independently (a single deployment could be well-configured in one area and poorly configured in another), the overall picture is that readiness is the exception rather than the rule.

The abovementioned risks are compounded. Consider a scenario where a customer's production server fails and they need to failover to the cloud. If RPO monitoring is disabled, the customer may not know that their most recent recovery point is three days old instead of three hours old. If automated testing was never configured, nobody knows whether the recovery server will actually boot and function correctly.

Each individual gap reduces the probability of a successful recovery. When multiple gaps exist simultaneously, the probability drops further.

## What this means for the market

The gap between deployment and readiness is not unique to any single platform or provider. It reflects a broader industry pattern where the urgency to "have DR" (driven by sales, compliance, or fear) outpaces the discipline to "maintain DR" (which requires ongoing effort, testing, and attention). As the DR market continues to grow, the readiness gap is likely to widen unless the industry shifts toward making readiness best practices automatic and default, rather than optional and manual.

MSPs are uniquely positioned to address this gap because they manage DR on behalf of their clients. A single MSP improving their onboarding and monitoring processes can improve readiness for hundreds or thousands of end-customer workloads. This is where the leverage is greatest, and where the recommendations in the next section focus their attention.

## Conclusion and recommendations

This analysis of Acronis telemetry for Q1 2026 platform data reveals a significant gap between DR deployment and DR readiness. While the number of organizations using disaster recovery continues to grow rapidly, the data shows that the majority of these deployments have fundamental readiness issues that could prevent them from working during an actual disaster.

The two main areas of concern are:

### 1. RPO monitoring

Eighty-five percent of recovery servers have no RPO monitoring configured. This means that if backups stop running or fall behind schedule, nobody is automatically notified. For businesses that rely on DR to protect against data loss, this is like having a smoke detector with no battery. The device is installed, but it will not alert you when there is a fire.

The overwhelming nature of this number suggests it is a default-configuration issue rather than a deliberate choice. Enabling RPO monitoring by default, with a reasonable 24-hour threshold, would immediately close this gap for all new deployments and should be considered a high-priority product change.

### 2. Automated testing

Eighty-two percent of DR backup rules have no automated test schedule. Industry best practices recommend at least monthly DR testing, yet only 18% of rules are configured for monthly tests and less than 0.2% for weekly tests. Without regular testing, configuration errors, software updates and infrastructure changes can silently break the DR chain.

The first time many organizations discover their DR does not work is during an actual disaster — the worst possible time to find out. Moreover, even among the workloads that do have testing enabled, a meaningful percentage of those tests fail, as shown by the auto-test failure alerts. This means the true "tested and working" population is smaller still. The combination of low testing adoption and nontrivial test failure rates creates a situation where confidence in DR readiness should be much lower than it typically is.

## The business impact

For MSPs managing DR for their clients, these findings represent both a risk and an opportunity. The risk is clear: an MSP whose client suffers a disaster and discovers their DR does not work faces reputational damage, potential legal liability and client loss. In regulated industries, the consequences can extend to fines and compliance actions that affect the MSP as well as the end customer.

The opportunity is equally clear: MSPs who proactively identify and fix readiness gaps can differentiate themselves through proven reliability. An MSP that can show a client a monthly report of successful test failovers, active VPN connections, and RPO compliance is providing tangible, demonstrable value. In a competitive market where many MSPs offer similar services at similar prices, proof of readiness becomes a powerful differentiator.

For SMBs, the message is simple: Having DR configured is not the same as being protected. A DR setup that has never been tested and has VPN connectivity issues provides a false sense of security that could prove costly during a real incident. The right question to ask your MSP is not "Do I have DR?" but "When was the last time my DR was tested, and did it succeed?"

## Recommendations for MSPs and service providers

*   Enable RPO monitoring for all recovery servers with appropriate thresholds based on client SLAs. The platform supports this natively — it just needs to be turned on. A 24-hour threshold is a safe starting point for most workloads.

*   Configure at least monthly automated test failovers for all DR-protected workloads. This is the single most impactful change MSPs can make to improve DR readiness. Review test results monthly and follow up on failures.

*   Review VPN tunnel status regularly and consider migrating customer-router deployments to VPN appliance mode where possible, as the data shows significantly better connectivity rates.

*   Create DR readiness dashboards that track RPO compliance, testing success rates and VPN connectivity across all managed clients. Use these dashboards in quarterly business reviews with clients.

*   Include DR testing results in regular client reporting to build confidence and demonstrate value. A client who sees monthly proof that their DR works is a client who renews.

*   Consider enabling RPO monitoring by default for new recovery servers, with a reasonable default threshold (e.g., 24 hours). Opt-out is better than opt-in for safety features.

*   Add a "DR Readiness Score" to the management console that combines RPO monitoring, testing and connectivity status into a single, easy-to-understand metric. Display it prominently on the dashboard.

*   Implement automated notifications when VPN tunnels have been disconnected for more than 24 hours. Make these notifications impossible to miss.

*   Provide guided onboarding that includes automated test failover configuration as a required step, not an optional one. Walk MSPs through the testing setup during initial DR deployment.

*   Create reporting templates that help MSPs communicate DR readiness status to their clients in simple, nontechnical terms.

If you are an end customer (SMB): Ask your MSP for proof that your DR has been tested recently. A simple question, "When was the last successful test failover?" can reveal a lot about your actual protection level. Understand your RPO and RTO ([recovery time objective](https://www.acronis.com/en/blog/posts/rto-rpo/)) targets and verify they match your business needs. The defaults may not be appropriate for your specific requirements. If your business operates in a regulated industry, ensure your DR testing frequency meets compliance requirements. Many regulations now require documented evidence of regular testing.

Related articles

[The Gentlemen: A closer look at a not-so-gentle ransomware-as-a- service operation](https://www.acronis.com/en/tru/posts/the-gentlemen-a-closer-look-at-a-not-so-gentle-ransomware-as-a-service-operation/)  
[Acronis AI Copilot: Adoption is high and growing among MSPs](https://www.acronis.com/en/tru/posts/acronis-ai-copilot-adoption-is-high-and-growing-among-msps/)  
[Acronis Cyberthreats Update, October 2026](https://www.acronis.com/en/tru/posts/acronis-cyberthreats-update-october-2026/)  
[AI agents at work: What Acronis endpoint data reveals about MSP and SMB usage](https://www.acronis.com/en/tru/posts/ai-agents-at-work-what-acronis-endpoint-data-reveals-about-msp-and-smb-usage/)