Architecture pattern: platform, security and operations

Backup and disaster recovery: copies, failover and a tested plan

Backup keeps copies of your data so you can go back in time. Disaster recovery keeps a way to run somewhere else when a site, a region or your data is lost. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and how much to spend on each.

Quick answer

Backup and disaster recovery combine regular, protected copies of your data with a way to restart systems elsewhere. A backup service takes scheduled copies and keeps one in a separate, locked place, while replication keeps a standby ready to start. Your recovery point and recovery time targets decide how much you spend.

Best forAny business system whose loss would stop work, cost money or break a rule, including protection against ransomware
Less suited whenThrowaway test data you can recreate, where the storage's own redundancy is enough
Start withDaily backups with a locked copy in another region, a written recovery order and one tested restore
Main services on AWSAWS Backup, Amazon S3 Glacier storage classes, AWS Elastic Disaster Recovery, Amazon EC2, Amazon Route 53
Main services on AzureAzure Backup, Azure Blob Storage Archive tier, Azure Site Recovery, Azure Virtual Machines, Azure DNS
Main services on Google CloudBackup and DR Service, Cloud Storage Archive and Coldline classes, Compute Engine, Cloud DNS

The idea in plain words

Backups answer one question: can we get the data back as it was yesterday, or last week? They protect against deletion by mistake, corruption and ransomware. Disaster recovery answers a different one: how fast can we run again if a data centre, a region or the whole environment is gone? Both matter, and they cost different amounts.

Two numbers set the design. The recovery point objective (RPO) counts the work you can afford to lose in minutes or hours: with an RPO of 15 minutes, a restore may drop the last 15 minutes of changes. The recovery time objective (RTO) is the longest the system may stay offline before the business is hurt. Tight numbers need continuous replication and a warm standby, while loose numbers are met with nightly backups. Give each system its own targets, because most do not need the tightest.

Treat any backup you have not restored as unproven. Schedule restore tests, write the recovery order down, and keep one copy where an attacker who steals your admin credentials cannot reach it.

The architecture

Boxes show the job each part does. Pick a cloud to see the service for each job.

Backup and disaster recovery: architecture diagramTwo rows of boxes. The numbered steps below describe the same flow in words.replicationrestore from herefail back when fixed1. Protect: copy your data on a scheduleLive systemsServers, databases andfilesBackup policyScheduled copies, keptfor set periodsAWS BackupAzure BackupBackup and DRServiceLocked second copyIn another region,safe from deletionAWS BackupAzure BackupBackup and DRServiceLong-term archiveCheap storage for oldcopiesAmazon S3 Glacierstorage classesAzure Blob StorageArchive tierCloud StorageArchive andColdline classes2. Recover when a site failsOutage or attackA site, a region oryour data is lostFailover serviceKeeps a ready copy andstarts it on demandAWS ElasticDisaster RecoveryAzure SiteRecoveryBackup and DRServiceRecovery siteServers started inanother regionAmazon EC2Azure VirtualMachinesCompute EngineSwitch trafficSends users to therecovery siteAmazon Route 53Azure DNSCloud DNSBackup and disaster recovery: architecture diagramBoxes from top to bottom. The numbered steps below describe the same flow in words.replicationrestore from here1. Protect: copy your data on ascheduleLive systemsServers, databases and filesBackup policyScheduled copies, kept for setperiodsAWS BackupAzure BackupBackup and DR ServiceLocked second copyIn another region, safe fromdeletionAWS BackupAzure BackupBackup and DR ServiceLong-term archiveCheap storage for old copiesAmazon S3 Glacier storageclassesAzure Blob Storage ArchivetierCloud Storage Archive andColdline classes2. Recover when a site failsOutage or attackA site, a region or your data islostFailover serviceKeeps a ready copy and starts iton demandAWS Elastic DisasterRecoveryAzure Site RecoveryBackup and DR ServiceRecovery siteServers started in another regionAmazon EC2Azure Virtual MachinesCompute EngineSwitch trafficSends users to the recovery siteAmazon Route 53Azure DNSCloud DNS↩ fail back when fixed, back to failover service
Arrows show the direction of the flow, and dashed lines connect the rows. Each box names the main service for that job, taken from CloudBrum's service suggester.

Step by step

  1. Set recovery targetsFor each system, agree the most data you can lose (the recovery point) and the longest you can be down (the recovery time). Rank systems so the critical ones are restored first.
  2. Back up on a scheduleA backup service takes copies of servers, databases and files by policy, keeps each for a chosen period and tags them, so nothing is forgotten when new systems appear.
  3. Keep a locked second copyStore a copy in another region and, ideally, another account, in storage that cannot be changed or deleted before its time is up. Ransomware and stolen admin passwords cannot reach it.
  4. Move old copies to cheap storageKeep recent copies close for quick restores and move older ones to archive storage, at a much lower price, for rules that demand years of history.
  5. Replicate what must come back fastFor systems with tight targets, replicate data continuously to a second region. Keep the standby small and idle, or fully running, depending on how fast it must take over.
  6. Fail over and switch trafficWhen the primary is lost, start the recovery servers from the replicated data, then change the DNS entry or the load balancer so users reach the new site. Follow a written order of steps.
  7. Test, then fail backRestore real data on a schedule and rehearse a failover at least once a year. When the primary returns, move back in a planned way and record what you learned.

Services side by side

The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.

JobAWSAzureGoogle Cloud
Backup and restore
  • AWS BackupCentral, policy-based backup for EC2, EBS, RDS, S3, DynamoDB and more
  • Azure BackupBacks up VMs, SQL, files and other Azure services to a vault
  • Backup and DR ServiceCentralised, application-consistent backup and recovery
Cold archive and long-term storage
  • Amazon S3 Glacier storage classesLowest-cost S3 classes for archives; retrieval from minutes to hours
  • Azure Blob Storage Archive tierLowest-cost tier for rarely accessed data; hours to retrieve
  • Cloud Storage Archive and Coldline classesLow-cost classes for data you rarely read
Disaster recovery and failover
  • AWS Elastic Disaster RecoveryContinuous replication and fast recovery of servers into AWS
  • Azure Site RecoveryReplicates VMs between regions or from on-premises and fails over
  • Backup and DR ServiceRecovery for VMs, databases and file systems
Virtual servers (VMs)
  • Amazon EC2Resizable virtual servers, Linux or Windows, in many sizes
  • Azure Virtual MachinesLinux or Windows VMs; Azure Hybrid Benefit lets you reuse Windows and SQL Server licences
  • Compute EngineVirtual machines, including custom machine sizes
DNS and domain names
  • Amazon Route 53DNS, health checks, routing policies and domain registration
  • Azure DNSHosts your DNS zones on Azure
  • App Service Domains
  • Cloud DNSReliable, low-latency authoritative DNS
Connect your office or data centre (VPN or dedicated line)Optional
  • AWS Site-to-Site VPNEncrypted tunnels between your network and AWS
  • AWS Direct Connect
  • Azure VPN GatewaySite-to-site and point-to-site VPN
  • Azure ExpressRoute
  • Cloud VPNIPsec VPN to Google Cloud
  • Cloud Interconnect

On some clouds one service does both jobs, backup and disaster recovery. Keep the two ideas separate when you plan: going back in time is not the same as running somewhere else.

Common variations

  • Ransomware is your top worry. Add immutable (write-once) backups, a separate recovery account and a clean-room restore, where you check a copy for infection before bringing it back.
  • The business needs near-zero downtime. Run in two regions at once behind a global entry point and replicate data both ways. It costs the most and takes the most design, so reserve it for systems that earn it.
  • On-premises servers to protect. Use a VPN or a dedicated link to back up on-premises servers into the cloud, or replicate them to a cloud recovery site.
  • Data with long retention rules. Move monthly and yearly copies to archive storage, and lock them for the retention period your rules require.

Try this in the service suggester

Cloud-native backup or a third-party backup product?

Each cloud has its own backup and recovery service that protects that cloud's resources. Many organisations also run a third-party backup product that covers on-premises systems and several clouds from one console.

Cloud-native services

Good

  • Know the cloud's resources and settings
  • Simple to turn on by policy
  • No extra licence to buy

Watch out

  • Each cloud works differently
  • Usually cover that cloud only
  • Reports and rules are separate per cloud

Third-party backup product

Good

  • One console and one policy across environments
  • Covers on-premises, several clouds and software-as-a-service data
  • May fit your existing skills and contracts

Watch out

  • An extra licence and extra servers to run
  • Its own security to look after
  • Can lag behind new cloud services
A common path. Use the cloud-native service for workloads in one cloud. Consider a third-party product when you must protect several clouds, on-premises systems and software-as-a-service data together.

Keep in mind

  • Two numbers decide the cost. The tighter your recovery point and recovery time, the more you pay. Ask the business for each system's real tolerance, and avoid giving every system the strictest target.
  • Test restores. Restore a real copy on a schedule and time it. Untested backups fail often, and you do not want to find that out during an outage.
  • The 3-2-1 rule, and a stronger one. A classic guide keeps three copies on two kinds of storage with one off site. Many teams add one copy that cannot be changed and restores that are checked and found error-free.
  • Protect the backup itself. Attackers delete backups first. Use a separate backup account, require multi-factor sign-in and a second approver for deletions, and turn on locks that stop early deletion.
  • Dependencies in the plan. Recovery needs identity, DNS, network and keys as well as data. Include them in the plan, and keep a copy of the plan itself where you can read it during an outage.
  • Data location and rules. Backups and replicas may leave the region of the original. Make sure the second region is allowed under your data-location rules, and encrypt copies with keys you control.
  • Cost. Storage grows with every copy and every retention period, and a warm standby costs money even when idle. Expire copies you no longer need, use archive tiers and size standbys to the target.
A starting point, not a design review. This is a general pattern. Your documents, users, rules and budget decide the real design. Confirm features, limits, pricing and regions on each provider's own pages. CloudBrum is independent of AWS, Microsoft and Google.

Words used on this page

Sources and further reading

Check details such as features, limits, prices and regions in the providers' own documentation.

Frequently asked questions

What is the difference between backup and disaster recovery?

A backup is a copy of data you can restore from, for example after deletion or ransomware. Disaster recovery is the plan and technology to run systems again somewhere else after a major failure. You need both: backups for going back, recovery for getting running quickly.

What are RPO and RTO?

RPO (recovery point objective) is how far back in time a restore may land, for example 15 minutes before the failure. RTO (recovery time objective) is how long the system may be offline, for example 2 hours. Together they decide how often you copy data and what kind of standby you need.

What are the main disaster recovery strategies?

From cheapest to most costly: backup and restore, a pilot light with only core parts running, a warm standby at reduced size, and active-active in two regions. Slower, cheaper options suit relaxed targets, and costlier options suit tight ones.

What is an immutable backup?

An immutable backup cannot be changed or deleted until its retention period ends, even by an administrator. It protects against ransomware and malicious deletion, because an attacker who takes over your account still cannot erase the copy.

How often should I test disaster recovery?

Test restores of important data at least monthly or quarterly, and rehearse a full failover at least once a year and after big changes. Record how long each step took, and fix anything that was missing or out of date.

Want this reviewed for your case?

CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.

Building something else?

Describe it in plain words and get matching services on all three clouds.

Service suggester → Cloud consulting →