CloudRUX Logo
    Datacenter 1
    Datacenter 2
    Datacenter 3
    Cost

    How DRaaS Pricing Works: 7 Factors That Drive Disaster Recovery Cost

    CloudRUX Engineering Team
    8 min

    Why is there no single list price for disaster recovery as a service? From the number of protected servers to RPO and RTO targets, replication technology and standby compute, we explain the seven factors that drive DRaaS cost and how to get an accurate quote.

    "How much does DRaaS cost?" is a bit like asking "how much does a house cost?" The answer depends on how many rooms it has, where it is and how quickly you need to move in. Disaster recovery works the same way: no single line item sets the price; several variables affect each other.

    In this article we explain how DRaaS (Disaster Recovery as a Service) pricing is put together, the seven factors that drive cost and how the picture compares with building your own disaster recovery site. The goal is that you know what to look for when a quote lands on your desk.

    What Is DRaaS and What Are You Buying?

    With DRaaS, your critical servers are copied to the provider's data centre, either continuously or at set intervals. When your primary environment is knocked out by fire, hardware failure, ransomware or a long power outage, your servers are brought up on the provider's infrastructure and you carry on working from there.

    So you are not just buying storage. Replication software, the infrastructure that holds the copies, compute that will run during a disaster, network connectivity and the team that operates it all come together. The price is the sum of these components.

    1. Number of Protected Servers and Data Size

    This is the most basic factor. Most DRaaS quotes are shaped by the number of protected virtual machines and the total disk size of those machines. Replication software is usually licensed per virtual machine, while storage for the copies is charged by capacity.

    The biggest saving opportunity is not trying to protect everything. Test servers, temporary environments and systems that are easy to rebuild may not need to be in disaster recovery scope. Deciding which systems are truly critical shrinks the quote directly.

    2. RPO and RTO Targets

    RPO (recovery point objective) is the maximum amount of data loss you can accept in a disaster. RTO (recovery time objective) is how quickly systems must be running again.

    The tighter the targets, the higher the cost. A system that needs an RPO of seconds and an RTO of minutes requires continuous replication, more bandwidth and resources standing ready. A system where going back to yesterday's backup is acceptable can be protected far more economically.

    You do not have to set the same target for every system. Your ERP and e-commerce database can be protected with tight targets and your archive server with relaxed ones. This tiered approach is the key to keeping DR affordable.

    3. Replication Technology

    The technology used determines both the achievable RPO and the cost:

    • Continuous data protection (CDP): solutions such as Zerto send every disk write to the target almost instantly. They offer RPOs measured in seconds and let you return to any point in the recent past. Ideal for critical systems, but licensing and bandwidth costs are higher.
    • Snapshot-based replication: methods such as Veeam replication copy changed blocks to the target at set intervals. RPO is in minutes or hours, which is enough for many workloads. Veeam's own continuous data protection feature is a separate option for tighter targets.
    • Recovery from backup: the most economical method. Servers are restored from backup onto the provider's infrastructure. RTO is longer, but it is a sensible option for less critical systems.

    4. Standby Compute: Reserved or On Demand?

    Your servers need CPU and memory to run during a disaster. That capacity can be planned in two ways:

    • On demand (standby): in normal times you pay only for storing the copies. Compute is used only during a test or a real disaster and is charged for that period. The cost is low.
    • Reserved resources: a set amount of CPU and memory is permanently set aside for you. The risk of capacity not being available in a disaster disappears and RTO is shorter, but you pay for that capacity every month.

    For many organisations the right answer is a mix: reserved resources for the few most critical systems and on-demand capacity for the rest.

    5. Network, Bandwidth and Public IPs

    The network is the most overlooked part of disaster recovery. Bringing servers up in another data centre is not enough; users and customers must be able to reach them.

    • Replication bandwidth: if your data change rate is high, your primary site needs enough internet capacity for continuous replication.
    • Public IP addresses: systems that serve the outside world need public IP addresses at the DR site and a ready DNS change plan.
    • VPN and internal network: branches and remote staff need VPN access to the DR site and, if necessary, a re-IP plan.
    • Security: systems at the DR site must be protected by a firewall too.

    6. Retention and Journal

    With continuous replication, changes are kept in a journal, which lets you return to a specific point in the past. In a ransomware scenario this is extremely valuable: you can go back to the clean state a few minutes before encryption started.

    The longer the journal, the more storage it needs. There is a serious capacity difference between a few hours of history and a few weeks. With snapshot-based replication, the number of restore points you keep affects cost in the same way.

    7. Testing, Runbooks and Managed Service

    An untested disaster recovery plan is a plan on paper. A real service should include:

    • Regular tests: failover tests in an isolated network without affecting production.
    • A runbook: a step-by-step guide to which system is brought up in what order, by whom and how.
    • Monitoring: a team that continuously watches whether replication is lagging and whether the RPO target is being met.
    • Failback: a controlled return of systems to the primary site once the disaster is over.

    Some quotes include only the infrastructure and leave these tasks to you. In a managed DRaaS service they are part of the service. Keep this difference in mind when comparing quotes.

    Compared with Building Your Own DR Site

    Building your own disaster recovery location is also an option. When calculating total cost, remember to include:

    • Server, storage and network hardware for the second site, plus refreshing it every few years,
    • Rack space, power, cooling and data centre connectivity,
    • Replication software licences,
    • Staff time to build, maintain and test the environment.

    Most of this investment sits idle as long as no disaster happens. The core advantage of DRaaS is sharing the cost of that idle capacity and handing the operational load to a specialist team.

    Questions to Ask When Comparing Quotes

    Two DRaaS quotes can show the same figure yet contain very different things. When comparing, clarify:

    • Which RPO and RTO values does the quote commit to, and are they written into the contract?
    • Is disaster compute reserved or provided on demand?
    • How many tests per year are included, and who does what during them?
    • Who writes the runbook and how often is it updated?
    • Who is the team that steps in during a disaster, and how do you reach them?
    • Is failback to the primary site included in the service?

    Preparing for an Accurate Quote

    To get a realistic quote from a provider, prepare the following:

    1. A list of virtual machines to protect, with CPU, memory and disk sizes,
    2. Your current virtualisation platform and backup software,
    3. Your target RPO and RTO for each system,
    4. An estimate of daily data change and your current internet capacity,
    5. Externally facing systems and public IP requirements,
    6. How many tests per year you expect.

    The clearer this information, the more accurate the quote, and the fewer surprise line items later.

    Frequently Asked Questions

    What is the difference between DRaaS and backup?

    Backup protects your data; DRaaS keeps your business running. Restoring from backup can take hours or days, while with DRaaS systems come up much faster on infrastructure that has been prepared in advance. The two complement each other rather than replace each other.

    Do I pay even if no disaster happens?

    Yes, because replication, storage of the copies and monitoring run every day. With the on-demand model, however, you pay for compute only during tests and disasters.

    Do I have to protect all my servers?

    No. The most efficient approach is to identify business-critical systems and protect them with tight targets, while covering the rest with recovery from backup.

    Where is my data kept?

    With CloudRUX DRaaS, copies are kept in data centres in Turkey, which simplifies cross-border transfer questions under KVKK.

    CloudRUX DRaaS

    Anyone can buy infrastructure; what makes the difference on the day of a disaster is an engineer who knows your systems and picks up when you call. With CloudRUX DRaaS, replication setup, runbooks, regular tests and failover are run by our Turkish-speaking team; your data stays in Turkey and your bill is planned as a fixed monthly amount. Pricing is prepared for your environment. See our DRaaS page for details, or contact us for a tailored quote.

    Let's Find the Right Solution for Your Business

    Boutique engineering services tailored for SMBs. Start with a free assessment.

    Get Free Consultation