Backup vs disaster recovery vs high availability is the comparison that quietly decides how bad your worst day is going to be. Most organisations have opinions about all three, budget for one of them, and discover during an incident that the one they bought does not do what they assumed. The three terms get used as though they were interchangeable. They are not, and the differences are the whole point.
The short version: a backup is a copy of your data you can go back to. Disaster recovery is the plan and the environment that get a service running again somewhere else. High availability is the redundancy that stops a component failure from becoming an outage at all. They solve different problems, they cost wildly different amounts, and buying the wrong one is how a business ends up with a beautiful clustered database and no way to recover a file somebody deleted three weeks ago.
This guide sets out what each layer actually does, where backup vs disaster recovery genuinely diverge, how recovery time and recovery point objectives drive the whole decision, what the three approaches cost a UK business in practice, and how ransomware has changed the arithmetic. There are comparison tables you can lift into a design document, indicative costs, and a five-step framework for deciding which workload deserves which layer. If you already run a plan and want to sharpen it, our guide to enterprise disaster recovery solutions goes deeper on the delivery side.
One framing note before the detail. None of this is really an infrastructure conversation. Backup vs disaster recovery is a question about how much money an hour of downtime costs you and how much data you can afford to lose, and every technical decision below falls out of those two numbers. Teams that start with the technology buy layers they do not need and skip the one they do.
Table of contents
- Backup vs disaster recovery vs high availability: the short answer
- What a backup actually is
- What disaster recovery actually is
- What high availability actually is
- Backup vs disaster recovery: the differences that matter
- RTO and RPO: the two numbers that decide everything
- Where high availability fits alongside backup vs disaster recovery
- What backup, disaster recovery and high availability cost
- Backup vs disaster recovery in the cloud and in Microsoft 365
- How ransomware changed the backup vs disaster recovery calculation
- How to choose: a five-step framework
- Testing: the part everyone skips
- Backup vs disaster recovery: the common mistakes
- Backup vs disaster recovery FAQ
- References
Backup vs disaster recovery vs high availability: the short answer
If you take nothing else from this article, take the distinction in this section. Getting backup vs disaster recovery straight in one paragraph each is what stops expensive mistakes further down.
Backup protects the data
A backup is a point-in-time copy stored somewhere separate from the original, kept for a defined retention period, and restorable on demand. Its job is to answer the question “can we get that back?” — whether “that” is a single spreadsheet, a mailbox, a database table, or an entire file server. Backup is fundamentally about going backwards in time, which is exactly the capability the other two layers do not give you, and it is the cleanest line in the whole backup vs disaster recovery comparison.
Disaster recovery restores the service
Disaster recovery is what happens when the thing you would normally restore to is also gone. It is the plan, the documented runbook, the secondary environment and the tested process for bringing a business service back up somewhere else within an agreed time. Disaster recovery assumes a site, a region or a platform has been lost, and it is measured in how long the business waits, not in whether the bytes survived.
High availability prevents the outage being noticed
High availability is redundancy engineered inside a single system so that a failed component does not take the service down. Two nodes instead of one, three availability zones instead of one data centre, a load balancer that stops sending traffic to the sick instance. Nobody files a ticket. High availability is a design property of the running system, not a recovery process, and it is the only one of the three that costs you money continuously whether or not anything ever fails.
The three are layers, not alternatives
The framing that causes the most damage is treating backup vs disaster recovery as an either-or purchase. They stack. High availability handles the common, boring failures — a dead disk, a rebooting host, a bad deployment in one zone. Disaster recovery handles the rare, severe ones. Backup handles the ones that are neither: deletion, corruption, ransomware, and the auditor who wants last April’s data. Remove any layer and there is a class of incident you simply cannot survive, which is why backup vs disaster recovery should be read as a sequencing question rather than a shortlist.
| Dimension | Backup | Disaster recovery | High availability |
|---|---|---|---|
| Core question | Can we get the data back? | Can we run the service elsewhere? | Will anyone notice the failure? |
| Protects against | Deletion, corruption, ransomware | Site, region or platform loss | Component and node failure |
| Typical recovery time | Hours to days | Minutes to hours | Seconds, automatic |
| Typical data loss window | 1 to 24 hours | Seconds to 1 hour | Effectively zero |
| Goes back in time | Yes, that is the point | Rarely, only to last replica | No, never |
| Cost profile | Low, storage-driven | Medium, scales with warmth | High, continuous duplication |
| Usual owner | IT operations | IT leadership and business | Architecture and engineering |
| Failure mode if skipped | Permanent data loss | Weeks of outage | Frequent short outages |
What a backup actually is
Backup is the oldest layer in the backup vs disaster recovery stack and the one most often assumed to be handled. It usually is handled — right up until somebody tries a restore.
A point-in-time copy you can return to
The defining property of a backup is immutability of the past. Monday’s copy still shows Monday even after Tuesday goes wrong. Replication, snapshots on the same array, and synchronised cloud folders all fail this test to some degree, because they are designed to make the copy match the original. When the original is encrypted or emptied, a faithful copy is the last thing you want.
The 3-2-1 rule, and why it grew two extra digits
The classic rule is three copies of the data, on two different media types, with one copy off-site. It has aged well, and it has been extended for the ransomware era: one copy immutable or offline, and zero errors on restore verification. That extended form is worth adopting deliberately rather than by accident, and our guide to the immutable backup 3-2-1-1-0 strategy works through what each digit costs to implement.
Retention is a separate decision from frequency
How often you take a backup determines how much data you lose. How long you keep it determines whether you can answer a legal request or recover from slow-burn corruption nobody noticed for a month. These are different questions and they get conflated constantly. Hourly backups kept for seven days are useless against a compromise that started in March, and no amount of disaster recovery tooling closes that gap.
Backup does not test itself
A green dashboard reports that a job completed, not that the data inside it is restorable. The National Institute of Standards and Technology’s contingency planning guidance is blunt about this: the restore is the control, not the copy. Organisations that discover a corrupt backup chain do so during an incident roughly as often as they do during a test, which tells you how many are testing.
Where backup alone is genuinely enough
Not everything needs three layers. An internal reporting tool that the business can live without for two days, a development environment, an archive nobody queries — these need a reliable restore path and nothing more. Deciding that explicitly is good engineering, and it is where most of the backup vs disaster recovery budget is saved. Deciding it by omission is not, and the difference between the two is whether it is written down.
What disaster recovery actually is
If backup is a technology, disaster recovery is a capability. That distinction is the heart of backup vs disaster recovery, and it explains why so many organisations own backup software and still have no recovery capability at all.
A plan plus an environment, in that order
Disaster recovery is a documented, tested process for restoring a business service in a different location within an agreed time, plus whatever infrastructure that process depends on. The plan comes first. A replicated environment with no runbook, no decision authority and no communications plan is an expensive standby that nobody will dare to fail over to at 3am.
The four cloud recovery patterns
Public cloud has standardised the design space into four patterns, set out clearly in the AWS guidance on disaster recovery options in the cloud. Backup and restore is the cheapest and slowest. Pilot light keeps core data replicated with the compute switched off. Warm standby runs a scaled-down copy continuously. Multi-site active-active runs full capacity in both places. Cost rises and recovery time falls as you move down that list, and the first two patterns are where most of the backup vs disaster recovery overlap lives.
A recovery site is useless without a runbook
The failure most disaster recovery tests expose is not technical. It is that three people each believed someone else had authority to declare a disaster, the DNS change needed a password nobody had, and the runbook referenced a server decommissioned last year. Disaster recovery is an operational discipline that happens to involve infrastructure, and treating backup vs disaster recovery as two shopping decisions misses that entirely.
It covers people and process, not just kit
Where do staff work if the office is unreachable? Who talks to customers? Which supplier contract obliges someone to answer the phone at the weekend? A recovery plan that only covers systems is half a plan, which is why a business continuity plan for outages sits above the technical layer rather than beside it.
| Pattern | What runs at the second site | Typical RTO | Typical RPO | Relative cost |
|---|---|---|---|---|
| Backup and restore | Nothing, data only | 12 to 48 hours | 1 to 24 hours | Lowest |
| Pilot light | Data replicated, compute off | 1 to 4 hours | Minutes | Low to medium |
| Warm standby | Scaled-down live copy | 10 to 60 minutes | Seconds to minutes | Medium to high |
| Multi-site active-active | Full production capacity | Near zero | Near zero | Highest |
What high availability actually is
High availability is the layer people most enjoy building and most often misapply. It is genuine engineering, and it solves a narrower problem than its reputation suggests — narrower, in particular, than either side of the backup vs disaster recovery pairing.
Redundancy inside a single system boundary
A high availability design removes single points of failure within one service: clustered database nodes, multiple application instances behind a load balancer, resources spread across availability zones so a single data centre outage is absorbed. The system stays up because a healthy component takes over from a sick one, usually within seconds and without human involvement.
Clusters, zones and load balancers do different jobs
A cluster protects a stateful service such as a database. A load balancer protects a stateless tier by removing failed instances from rotation. Availability zones protect against a facility-level event — power, cooling, network — within one region. Mixing them up produces designs that look redundant on a diagram and share a dependency underneath, which is the classic way a “highly available” system takes a single-component outage. None of the three protects data, so the backup vs disaster recovery layers still have to sit underneath.
The nines, and what each one costs
Availability targets are expressed as percentages, and the jump between them is exponential in cost while the benefit is measured in minutes. Google’s Site Reliability Engineering book publishes the canonical availability table; the practical version is below. Most business systems sit comfortably at three nines, and the honest question for any target above that is whether the business genuinely loses more than the extra engineering costs. In most estates the answer is no, and the money is better spent on the backup vs disaster recovery layers below.
High availability replicates your mistakes instantly
This is the sentence worth pinning above the architecture board. A clustered, replicated, zone-redundant system propagates a bad delete, a schema corruption or an encryption event to every node in milliseconds. Redundancy is indifferent to whether the change was wanted. That is precisely why the high-availability architecture conversation must never be allowed to end with “so we do not need backups”.
Backup vs disaster recovery: the differences that matter
Plenty of vendors sell “backup and DR” as a single product, which blurs a distinction worth keeping sharp. Here is where backup vs disaster recovery genuinely part company.
Different failure modes
Backup answers logical failure: something was deleted, overwritten, corrupted or encrypted, and the infrastructure is fine. Disaster recovery answers physical or platform failure: the infrastructure is not fine, and the data may be perfectly intact somewhere you cannot reach. A tool optimised for one is rarely optimised for the other, which is the practical reason backup vs disaster recovery stay separate line items on a budget.
Different recovery points
A backup gives you a menu of restore points spanning weeks or years. Disaster recovery typically gives you one: the state of the replica at the moment of failover. That single difference is why replication is not a backup, and it catches organisations out repeatedly. If your only recovery mechanism is a replica, your recovery point is always “just before the disaster” — including a disaster you caused yourself.
Different owners and different budgets
Backup is usually an IT operations line item, renewed quietly, sized by terabytes. Disaster recovery is a business decision with a board-level risk appetite behind it, because it involves deciding how long the organisation can be closed. When backup vs disaster recovery are funded from the same pot by the same person, disaster recovery is the one that gets deferred, every time.
Different testing regimes
Testing a backup means restoring a sample and verifying it. Testing disaster recovery means running the business on the recovery environment with the people who would actually do it, ideally without the person who designed it in the room. The second is an order of magnitude more disruptive to arrange, which is why it is skipped, and why it is the test that finds real problems. Any honest backup vs disaster recovery review starts by asking when each was last exercised.
| Incident | Backup | Disaster recovery | High availability |
|---|---|---|---|
| Single disk or node fails | Overkill | Not needed | Handles it invisibly |
| User deletes a folder | Handles it | No help | Replicates the deletion |
| Database corruption | Handles it | Partial, if replica is clean | Replicates the corruption |
| Ransomware encryption | Handles it if immutable | Only with clean-room rebuild | Actively spreads it |
| Data centre power loss | Slow recovery | Handles it | Handles it if multi-zone |
| Whole cloud region offline | Slow recovery | Handles it | No help, single region |
| SaaS tenant misconfiguration | Handles it | No help | No help |
| Bad release breaks the app | Data only | No help | No help, deploys everywhere |
RTO and RPO: the two numbers that decide everything
Every argument about backup vs disaster recovery resolves once these two numbers exist. Without them, the debate is aesthetic.
Recovery time objective is a business decision
The recovery time objective is the number that settles most backup vs disaster recovery arguments: the maximum acceptable time between a service going down and being usable again. It is set by the business, not by IT, because it is a statement about revenue, contractual obligation and reputational tolerance. The technology’s job is to meet it at the lowest cost. When IT sets the RTO alone, it is really a guess about what the business will tolerate.
Recovery point objective is how much work you will redo
The recovery point objective is the maximum acceptable data loss, expressed in time. An RPO of four hours means that after a failure you accept re-entering up to four hours of work. Say that sentence out loud to the finance team responsible for re-keying the invoices and the number usually changes. RPO drives backup frequency and replication design directly, which is why it, not preference, decides the backup vs disaster recovery split for a given workload.
Cost an hour of downtime before you shop
Take the affected service, estimate lost revenue, idle staff cost, contractual penalties and recovery labour for one hour, and you have the number that justifies or kills every option below. A business losing £400 an hour cannot rationally spend £40,000 a year on active-active infrastructure. One losing £40,000 an hour cannot rationally rely on a nightly tape.
Tier the workloads instead of buying one number
The most common and most expensive error is applying a single RTO across the estate. Almost no organisation needs four-nines availability for its intranet. Tiering — typically three or four bands from “mission critical” to “can wait a week” — is what makes backup vs disaster recovery spending defensible, because each tier gets the cheapest mechanism that clears its bar.
Where high availability fits alongside backup vs disaster recovery
High availability earns its place in the stack, but only once its boundaries against backup vs disaster recovery are clear.
It is not a backup
No amount of redundancy gives you yesterday’s version of a file. Synchronous replication is designed to make every copy identical as fast as physics allows, and it succeeds at that even when the change is catastrophic. Any architecture review that treats a cluster as a substitute for retained copies has confused durability with recoverability.
It is not disaster recovery either
A cluster spread across three availability zones survives a data centre failure and does nothing at all for a region-wide outage, an account compromise, or a platform-level incident at your provider. Zone redundancy is high availability. Region redundancy is disaster recovery. Cloud marketing blurs the two energetically, and the distinction is exactly what your recovery plan depends on.
The three-layer model in practice
A mature design looks like this: high availability absorbs component failures continuously; disaster recovery handles the loss of a site or region on a tested runbook; backup, ideally with an immutable copy, covers deletion, corruption and ransomware across a long retention window. Each layer has a defined trigger, a defined owner and a defined test schedule, and the backup vs disaster recovery boundary is written into the runbook rather than assumed.
When to skip high availability entirely
Plenty of workloads should not have it. If a two-hour outage costs less than the annual premium for redundancy, buy the outage. Single-instance services with good backup and a documented rebuild are a perfectly respectable answer for internal tooling, and choosing that deliberately frees budget for the tier that genuinely cannot stop.
What backup, disaster recovery and high availability cost
Prices vary enormously by estate, but the shape of the backup vs disaster recovery cost curve is consistent, and the shape is what drives the decision.
Backup is the cheapest layer by a wide margin
For most SMEs, protecting the whole estate — servers, endpoints, Microsoft 365 — lands in the low thousands of pounds a year, dominated by storage volume and retention length. It is the highest-value security spend available per pound, and it is routinely the first thing trimmed when a budget is squeezed — which is the wrong end of the backup vs disaster recovery ledger to economise on.
Disaster recovery scales with how warm you keep it
Pilot light is cheap because compute is switched off and you pay mainly for replicated storage. Warm standby costs real money because a scaled-down environment runs continuously. The cost driver is not the software licence; it is how much idle capacity you are prepared to fund for an event that may never happen.
High availability roughly doubles the infrastructure bill
Redundancy means paying for capacity you are not using. Doubling nodes, spreading across zones, and licensing the second copy of commercial database software typically lands somewhere between 1.7x and 2.2x the single-instance cost. Managed platform services soften this by bundling zone redundancy into the price, which is one of the better arguments for platform-as-a-service.
The costs that surprise people
Egress charges when you restore a large dataset out of cloud storage. Licensing for standby servers. The staff days consumed by a proper failover test. Retention growth, which compounds silently until an invoice doubles. Budget these explicitly — they are the line items that turn a sound backup vs disaster recovery business case into an awkward conversation twelve months later.
| Layer | Indicative annual cost, 50-user UK business | Main cost driver | Buy it when |
|---|---|---|---|
| Backup, servers and endpoints | £1,500 to £4,000 | Data volume and retention | Always |
| Microsoft 365 backup | £1,200 to £2,400 | Per-user licensing | Always |
| Immutable or offline copy | £600 to £2,000 | Locked storage tier | Almost always |
| Disaster recovery, pilot light | £3,000 to £9,000 | Replicated storage | RTO under 8 hours |
| Disaster recovery, warm standby | £12,000 to £35,000 | Idle running capacity | RTO under 1 hour |
| High availability, single region | £8,000 to £30,000 | Duplicate nodes and licences | Downtime costs per minute |
| Annual testing and rehearsal | £2,000 to £6,000 | Staff time | Always |
Backup vs disaster recovery in the cloud and in Microsoft 365
Moving to cloud changes who operates the infrastructure. It does not change who is accountable for the data, and that gap is where most modern data loss happens. Cloud also rearranges the backup vs disaster recovery boundary rather than removing it.
Shared responsibility does not include your data
Every major provider draws the same line: they are responsible for the resilience of the cloud, you are responsible for resilience in it. Platform durability protects against their disks failing. It does not protect against your administrator deleting a container, an integration writing garbage, or an attacker with valid credentials. The NCSC’s cloud security guidance is explicit that the customer retains this responsibility.
Availability zones are high availability, not disaster recovery
Spreading a workload across zones is one of the best-value resilience decisions available, and it is high availability. It protects against a facility event inside one region. A regional outage, a subscription-level compromise or a misconfiguration applied estate-wide are all outside its scope, which is why cloud-native architectures still need a documented recovery plan and a cloud adoption strategy that names the recovery region.
Microsoft 365 retention is not a backup
Retention policies, litigation hold and the recycle bin are compliance and convenience features with time limits and coverage gaps. They are not a restore path for a tenant-wide incident, and the distinction between Microsoft 365 data retention and backup is one of the most consequential misunderstandings in small-business IT. Treat the tenant as a system you are responsible for protecting.
Cloud removes the racking, not the planning
Failover between regions still needs somebody to decide, DNS to change, dependencies to be ready and staff to know what to do. Microsoft’s own disaster recovery guidance in the Well-Architected Framework treats the plan as the deliverable, with the infrastructure as an implementation detail. Cloud makes the environment cheap to build and does nothing about the process, which is the part of backup vs disaster recovery no provider will ever sell you.
How ransomware changed the backup vs disaster recovery calculation
Ransomware is the reason the backup vs disaster recovery comparison has been rewritten across the industry in the last five years. It attacks the assumptions all three layers were built on.
Attackers target the backups first
Modern intrusions look for backup infrastructure early, because encrypting production while leaving a restore path intact does not generate payment. Backup servers, management consoles and cloud storage credentials are primary objectives. A backup system reachable with ordinary domain credentials is not a recovery capability; it is another production system waiting to be encrypted.
Immutability is the control that matters now
Write-once storage that cannot be altered or deleted before its retention expires — S3 Object Lock, Azure immutable vaults, or genuinely offline media — is what converts a backup into a recovery guarantee. The NCSC’s guidance on offline backups in an online world has been making this argument since well before it became a vendor slogan.
Recovery is a rebuild, not a restore
Restoring encrypted systems into the same compromised environment reinfects them. Real ransomware recovery means a clean environment, forensic confidence about the intrusion timeline, staged restoration and identity rebuilt from a known-good state. This is why the exercise routinely takes weeks rather than the hours a backup RTO implies, and it is the single biggest reason to rehearse the backup vs disaster recovery handover before you need it.
High availability makes this failure worse
Synchronous replication distributes encryption to every replica as fast as the network allows. Zone-redundant storage stores encrypted blocks redundantly and reliably. In a ransomware scenario the high availability layer is not neutral — it is an accelerant, and the only layers that help are immutable copies and a rehearsed rebuild. Broader security controls reduce the odds of getting there in the first place.
How to choose: a five-step framework
This is the sequence that turns the backup vs disaster recovery debate into a short, defensible decision, and it takes an afternoon rather than a consulting engagement.
Step 1: inventory business services, not servers
List what the business does — take orders, pay staff, answer the phone, invoice — and map the systems each one depends on. Recovery planning organised by server produces a list nobody can prioritise. Organised by service, the priorities are obvious within an hour, the dependencies you had forgotten become visible, and the backup vs disaster recovery choice per service almost makes itself.
Step 2: put a pound figure on an hour of downtime
For each service, estimate the hourly cost of it being unavailable, including idle staff, lost transactions, penalties and the labour of catching up afterwards. Rough numbers are fine; the ranking matters more than the precision. This single column does more to settle architecture arguments than any technical analysis.
Step 3: assign every service to a tier
Three or four tiers is enough. Tier 1 might be an RTO under an hour with near-zero data loss; tier 3 might be a working day with a day of loss. Every service goes in a tier, including the ones nobody wants to demote, and the tier is signed off by someone with budget authority rather than by IT alone.
Step 4: buy the cheapest mechanism that clears the tier
Match each tier to the least expensive option in the pattern table above that meets its numbers. This is where the layered view of backup vs disaster recovery pays: most estates end up with everything backed up, a minority replicated for recovery, and a small handful genuinely engineered for high availability. That distribution is healthy, not a gap.
Step 5: write down what you chose not to protect
Every plan has accepted risk. Recording it — “the reporting warehouse has a 72-hour RTO and we accept that” — converts an omission into a decision, gives the next auditor a clean answer, and stops the same argument recurring annually. It also gives the board something concrete to overrule if their appetite differs, which is the whole point of IT governance.
Testing: the part everyone skips
An untested recovery capability is a belief, not a control. Testing is where backup vs disaster recovery plans stop being documents.
A restore test is not a backup report
Restore a real file, a real mailbox and a real database to a usable state, and time it. That measurement is the only honest input to a backup vs disaster recovery review; job-completion reports merely tell you a process ran. They say nothing about whether the chain is intact, the encryption keys are available or the retention you assumed is actually configured.
Test the plan with the people who will run it
Run the failover with the on-call team, not the architect. If the runbook only works when its author is available, it does not work — that person will be on a plane, and the gap between “documented” and “executable by a tired colleague at 4am” is where recovery plans fail.
Break something on purpose
The only honest test of high availability is to remove a node, drain a zone or kill an instance and watch what happens. Planned, in hours, with a rollback. The alternative is discovering during a real event that the failover was configured but never exercised, and that a dependency you forgot lives on the failed node.
Record actual numbers against the objectives
Every test should end with a measured RTO and RPO written next to the target. That comparison is the only evidence that the backup vs disaster recovery money is buying what it promised, and a trend across two or three tests tells you more about your resilience than any architecture diagram. Where in-house capacity for this is thin, it is a natural fit for managed IT services with contractual test obligations.
Backup vs disaster recovery: the common mistakes
These backup vs disaster recovery mistakes recur across almost every review, in businesses of every size.
Assuming replication is a backup
The most expensive misunderstanding in the field. Replication has no time dimension, so it cannot recover from anything that was written on purpose by something with permission.
Buying high availability to solve a data loss problem
An organisation that has just lost a database to corruption often responds by clustering it. The cluster would have replicated the corruption. The correct answer was a shorter RPO and a verified restore path.
Setting one recovery objective for everything
A single estate-wide RTO either over-protects the intranet or under-protects the finance system. Usually both, simultaneously, at considerable expense.
Never testing the restore path
Backups that have never been restored have an uncomfortably high failure rate at the moment of need. The test is the control; the job report is marketing.
Letting the plan go stale
A recovery plan written two years ago references systems that no longer exist and omits the three SaaS platforms the business now depends on. Review it when the estate changes, not annually by calendar.
Protecting servers but not identity
If the directory is compromised or lost, restoring servers gets you nowhere. Identity recovery belongs in the plan alongside data, and it is the dependency most often discovered late in a backup vs disaster recovery exercise.
Backup vs disaster recovery FAQ
Do I really need all three layers?
Most organisations need backup universally, disaster recovery for the services that cannot wait a day, and high availability for the handful where minutes matter. Very few need all three everywhere, and settling backup vs disaster recovery per tier rather than per estate is the point of the framework above.
Is replication a backup?
No. Replication keeps a second copy identical to the first, including deletions, corruption and encryption. It is excellent for availability and useless for going back in time, which is the defining property of a backup and the single most important line in the backup vs disaster recovery comparison.
What RTO should a small business aim for?
For core operational systems, four to eight hours is a realistic and affordable target with pilot-light recovery. Anything under an hour means continuously running standby capacity, and that cost should be justified by a measured hourly downtime figure.
Does Microsoft 365 back up my data?
Microsoft protects the platform and provides retention features with defined limits. It does not provide a customer-controlled, long-retention restore path, which is why third-party protection for the tenant is standard practice.
Is high availability worth it for a 30-person business?
Usually not as a general policy, and sometimes yes for one specific system such as a phone platform or an e-commerce front end. Apply it per service against the hourly cost of that service being down.
How often should we test?
Restore tests monthly and a full recovery rehearsal annually is a reasonable baseline, with an extra rehearsal after any significant change to the estate. Frequency matters less than the tests being real and the results being recorded against your stated backup vs disaster recovery objectives.
References
NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events
NIST SP 800-209, Security Guidelines for Storage Infrastructure
Mitigating malware and ransomware attacks — NCSC
Offline backups in an online world — NCSC
Incident management collection — NCSC
Cloud security guidance — NCSC
Disaster recovery options in the cloud — AWS Whitepapers
AWS Well-Architected Framework, Reliability Pillar
Using S3 Object Lock — Amazon S3 User Guide
Recommendations for designing a disaster recovery strategy — Azure Well-Architected Framework
What are availability zones? — Azure reliability documentation
Immutable vaults for Azure Backup — Microsoft Learn
About Azure Site Recovery — Microsoft Learn
Disaster recovery planning guide — Google Cloud Architecture Center
Availability table — Google Site Reliability Engineering
