Acronis Disaster Recovery

Acronis Disaster Recovery is an Acronis Cyber Protect Cloud add-on that keeps ready-to-run copies of protected workloads in the Acronis Cloud and brings those copies up in the cloud during an outage. The difference from backup is this: backup stores data, whereas disaster recovery keeps the service running. Production failover, test failover that does not touch production, sequenced startup with runbooks and site-to-site VPN options are all managed from a single console.

The objectives are officially defined too: the Acronis Advanced Disaster Recovery data sheet explicitly states an RPO and RTO of under 15 minutes thanks to the RunVM engine (Acronis Advanced Disaster Recovery data sheet, 2022). That figure is not a guarantee but the operating point the architecture targets; the value you actually achieve depends on replication frequency, workload size, link capacity and runbook design.

The justification for this investment lies in the data on how long outages drag on. According to the IBM Cost of a Data Breach Report 2025, 65% of organisations have still not fully recovered from their breach; among those that say they have fully recovered, the process took more than 100 days in 76% of cases and more than 150 days in 26%, while only 2% recovered in under 50 days (IBM & Ponemon, 2025). The same report puts the global average cost of a data breach at USD 4.44 million (down from USD 4.88 million in 2024); the average cost of extortion and ransomware incidents reaches USD 5.08 million when disclosed by the attacker.

Disaster recovery is therefore not only about earthquake or fire scenarios but about ransomware as well. According to the Acronis H2 2025 Cyberthreats Report, more than 7,600 ransomware victims were publicly disclosed worldwide in the second half of 2025; the most active groups were Qilin (962 victims), Akira (726) and Cl0p (517) (Acronis Cyberthreats Report H2 2025). At Sora Yazılım we run disaster recovery projects within the Acronis solution family across scoping, runbook design, drills and managed operations.

What is the difference between Acronis Disaster Recovery and classic backup?

Short answer: with backup, data is stored and written back when recovery is requested; with disaster recovery, a ready-to-run copy of the workload waits in the cloud and is brought online with a failover command. Backup improves RPO, while disaster recovery primarily improves RTO. The two are not alternatives to each other; Disaster Recovery is built on top of an already active Acronis Cyber Protect subscription and the backups you have taken.

There is one more layer in between: Instant Restore. A virtual machine is started directly from a disk-level backup containing an operating system; its disks are emulated from the backup while the machine runs, and storage space is needed only for the changes that accumulate. Acronis recommends keeping this temporary machine for no more than three days and then deleting it or converting it into a permanent virtual machine (Acronis Cyber Protect Cloud User Guide). Instant Restore uses your own hypervisor resources; Disaster Recovery draws its resources from the Acronis Cloud, which makes it the only option that works in scenarios where the production site is completely unreachable.

This distinction also clarifies the purchasing decision. For organisations that only want protection against data loss, the backup core on the Acronis Cyber Backup side is enough. For workloads where downtime translates directly into lost revenue or lost service, failover capability is required. In practice, organisations classify their workloads: the critical ones are brought into the Disaster Recovery scope, and the rest are protected with backup and Instant Restore.

What are the real RTO and RPO figures, and what do they depend on?

Short answer: the official target is an RPO and RTO of under 15 minutes (Acronis Advanced Disaster Recovery data sheet, 2022), but that value depends on three variables. The first is replication frequency: the more often the recovery point is refreshed, the narrower the RPO. The second is runbook design: how many servers come up, in what order and with which dependencies determines the RTO. The third is the network: if you have not worked out how users and integrated systems will reach the copy in the cloud, the service is not really up even when the servers are running.

That is why we carry out the target-setting exercise workload by workload. For each application we look for written answers to three questions: how many minutes of data loss are acceptable, within how many minutes the service must be back up, and which manual workflow takes over during that period. Although an upper bound in the form of "an RPO between 15 minutes and 1 hour" occasionally circulates in the market, no such upper bound appears in the official Acronis data sheet; the only target stated is under 15 minutes. For that reason we treat the target not as a promise but as an operating point that must be verified by drills.

Another important point is which recovery point the failover will use. Among the capabilities the Advanced Disaster Recovery pack officially adds is "failover to a malware-free recovery point". In a ransomware scenario this is decisive: the most recent recovery point may correspond to a moment when the attacker was already inside the system. For this control to work effectively, backups must be scanned; that capability comes with the Acronis Advanced Security + EDR add-on. In addition, since September 2024, immutable storage in Governance mode with a 14-day retention period has been enabled by default on all Acronis-hosted storage (Acronis Cyber Protect 16 Web Help), which means the recovery point you fail over to has some resistance to deletion.

How does failover in the cloud work, and how is network connectivity established?

Short answer: the backup of the protected workload is replicated to the Acronis Cloud, a failover command starts that copy as a virtual machine in the cloud, and it serves over the connection between your network and the cloud. On the network side there are two basic models: extending the local network into the cloud through a secure VPN tunnel, or cloud-only mode, which works without deploying a VPN appliance. According to the official documentation, up to 23 local networks can be extended into the cloud over a secure VPN tunnel (Acronis Cyber Protect Cloud User Guide).

The choice of network model depends on the application architecture. Site-to-site VPN is preferred in environments where the cloud servers must appear in the same IP block as the production network and where integrations are tied to fixed IP addresses. If only a handful of independent servers need to come up, cloud-only mode is both faster to set up and requires fewer components. The tunnel termination point on the customer side is usually the existing firewall; if an IPsec tunnel is being built with a device such as a Fortinet FortiGate, how routing, NAT and DNS rules will behave in a failover scenario must be tested in advance.

According to the official data sheet for the Advanced Disaster Recovery pack, standard Cyber Protect Cloud protection includes file, image and application backup, local recovery with Instant Restore, test failover and cloud-only VPN connectivity; on top of that, the pack adds production and test failover to the Acronis Cloud, a VPN-less deployment option, IPsec multi-site VPN together with L2 site-to-site OpenVPN, multiple runbook templates, custom DNS configuration, disaster recovery for DHCP servers and failover to a malware-free recovery point.

The distinction in the table is based on the "already included" and "added by the pack" lists in the Acronis Advanced Disaster Recovery data sheet itself (Acronis Advanced Disaster Recovery data sheet, 2022). In practice, the item most often overlooked is DNS: even if the copy in the cloud comes up, the service will not reach users if name resolution keeps pointing at the old address. That is why custom DNS configuration and TTL values are an inseparable part of runbook design.

How are test failover and disaster recovery drills carried out?

Short answer: test failover means running the copies in the cloud on an isolated network without touching the production environment. The aim is not to see whether the servers boot, but whether the service can be delivered end to end: does the application open, does it connect to the database, can users log in, do the integrations respond? The official data sheet lists test failover among the capabilities included in Cyber Protect Cloud; production and test failover to the Acronis Cloud, along with automated test failover that can be scheduled monthly or weekly, come with the Advanced Disaster Recovery pack.

What makes a drill meaningful is a realistic scenario. The structure we use is this: first a starting scenario is written (for example, complete loss of access to the primary data centre), then the runbook is executed against that scenario, then the measured duration of each step is compared with the target, and finally the deviations are turned into a remediation list. The drill report is presented to the business units, because the RTO target is set by the business owner, not by the technical team.

A practical constraint on drill frequency also comes from licensing. A Disaster Recovery subscription includes a certain volume of compute points, and both failover and test failover draw from that pool; according to the official licensing knowledge base, a one-year subscription per workload includes 2,000 compute points, and 2,000 points correspond roughly to two weeks of failover or test usage per year (Acronis Support KB 73387, 2026). That is a comfortable budget for running a few serious drills a year, but it is not designed for test environments left permanently switched on.

The scope of a drill must cover not only the servers but the people too. Who decides to fail over, who handles communications, which suppliers are informed and by what criteria the failback (return to production) decision is made must all be written down. For organisations that want to mature this side, our DevOps and infrastructure services step in around automation, monitoring and infrastructure standardisation.

How is Acronis Disaster Recovery licensed and what are its prerequisites?

Short answer: the add-on is licensed per workload and requires an active Acronis Cyber Protect subscription and cloud deployment. Depending on the subscription term, it includes a specific pool of compute points: per workload, a one-year subscription provides 2,000, a three-year subscription 6,000 and a five-year subscription 10,000 compute points, and disaster recovery storage is unlimited (Acronis Support KB 73387, 2026).

The cloud deployment requirement is not a technical detail but an architectural constraint. In the official Acronis documentation, disaster recovery as a service appears in the list of capabilities available only in cloud deployment; the same list also includes Microsoft 365 and Google Workspace cloud-to-cloud backup, backup to public cloud, EDR, Cyber Scripting, remote desktop and hardware inventory (Acronis Cyber Protect 16 Web Help). Consequently, if you operate an on-premises management server with Acronis Cyber Protect 16 only, you will need to move to Acronis Cyber Protect Cloud for disaster recovery, or design a hybrid model.

Which capabilities on-premises and cloud management each cover is listed item by item in the Acronis comparison knowledge base; some capabilities such as tape destinations, Acronis Storage Node, PXE server and Forensic Mode exist only on the on-premises side, while others such as EDR and DLP Device Control exist only on the cloud side (Acronis Support KB 73376, 2025). In hybrid designs we use this table as the basis for deciding which workload is managed from which console. We prefer to talk about scope rather than price: once the number of workloads, the target RTO and the drill frequency are clear, we prepare a proposal.

What data and what decisions should a business continuity plan rest on?

Short answer: business impact analysis comes before technology selection. Unless you have determined how many hours each process can be down, the hourly cost of that downtime, the applications each process depends on and the dependency order between those applications, RTO and RPO targets remain arbitrary numbers. The most common mistake we see in disaster recovery projects is assigning the same target to every server, which drives up both cost and complexity unnecessarily.

The threat data also underpins the rationale for the plan. The Verizon 2025 Data Breach Investigations Report analysed 22,052 security incidents and 12,195 confirmed data breaches across 139 countries; ransomware was present in 44% of the breaches analysed, appearing in 88% of SMB breaches while remaining at 39% for large organisations. The median ransom payment fell to USD 115,000, and 64% of victim organisations did not pay the ransom (Verizon DBIR 2025). Not paying is only a viable option when there is a directly restorable copy and a recovery plan that works.

Three controls stand together in the technical backbone of the plan. Immutable storage prevents the backup from being deleted and thereby preserves the point you can roll back to. Encryption prevents the copy from being read: in Acronis backup encryption, the AES algorithm runs in Galois/Counter (GCM) mode with a randomly generated 256-bit key; the key is encrypted with AES-256 using the SHA-2 (256-bit) hash of the password, and the password is never stored anywhere on disk or in the backups (Acronis Cyber Protect 16 Web Help). The third control is failover, which keeps the service running. If any leg of this trio is missing, the value of the other two drops.

The written output of the plan must be concrete too: a workload inventory with criticality classes, an RTO/RPO target per workload, runbook steps and their sequence, a network and DNS change plan, decision and communication responsibilities, a drill calendar and a failback procedure. We produce this document together with the project and update it after every drill.

What should you watch out for regarding KVKK, data residency and the Turkish context?

Short answer: KVKK (Turkey's data protection law) does not mandate a specific product, but it clearly expects rapid resumption of operations after an outage. The "Backing Up Personal Data" section of the Personal Data Security Guide published by the Turkish Personal Data Protection Authority states that, where data is damaged, destroyed or stolen, the data controller must resume operations as quickly as possible using the backed-up data; that backup strategies against ransomware should be developed; that only the system administrator should be able to access backed-up personal data; and that data set backups must be kept off the network (KVKK Personal Data Security Guide).

The measurable equivalent of "resume operations as quickly as possible" is the RTO target; the equivalent of "keep off the network" is the copy in the cloud. Disaster recovery is the single control that satisfies both clauses at once. Where the data and the failover resources physically reside is, however, a separate question. Istanbul appears in the official Acronis data centre list under the "Acronis Cloud DC" heading; the list spans the Americas, Europe and the Middle East, Asia-Pacific and Africa, and Acronis additionally lists Google Cloud Platform and Microsoft Azure locations (Acronis Cyber Cloud Data Centers). At the start of every project we confirm with Acronis which region can be assigned to your tenant and whether the disaster recovery service is offered in that region.

In regulated sectors one further preparation is required: drill records must be auditable. Reporting test failover results, measured durations and corrective actions lets you answer audit questions with "we ran our plan on this date and measured this duration" rather than "we have a plan". This is one of the most tangible returns on a disaster recovery investment.

It is worth remembering that the copy in the cloud needs protecting too. Because the servers running after failover become production workloads, endpoint and server security controls are expected to apply there as well; in organisations using server-focused protection solutions such as Trend Micro Deep Security, how that product behaves in terms of licensing and policy during a failover scenario should be planned in advance. For organisations that also want to consolidate patch and inventory management into the same console, we evaluate the Acronis Advanced Management add-on alongside it.

Share the list of your critical workloads, your acceptable downtime windows and your current Acronis deployment, and we will determine together which workloads the Acronis Disaster Recovery scope should cover, which network model suits you and what the drill calendar should look like. Let us prepare a proposal covering scope, runbook design and deployment steps. Get in touch via our contact page — we work with local technical support in Turkish, disaster recovery drills and post-deployment operational support included.