Backup & Disaster Recovery in the Cloud: What Mid-Sized Companies Actually Need

Friday afternoon, just before the weekend: a ransom note appears on every screen, and every file is encrypted. The IT lead reaches for the backup - and discovers the external drive hasn’t been connected in three weeks, because the colleague responsible for it has been on holiday. Moments like this decide whether a cyberattack stays an unpleasant footnote or shuts the business down for weeks.

Backup and disaster recovery sound like IT fine print. In reality they’re business decisions with a clear price tag: how much downtime can your company absorb, how much data loss is acceptable, and what is a reliable answer to those two questions actually worth to you? This guide walks through the key terms, updates the classic 3-2-1 rule for the cloud era, and gives you a checklist to verify your backups would actually work when it counts.

RTO and RPO: the two numbers everything else depends on

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two most important figures in disaster planning - and yet few executives could state them for their own systems if asked on the spot.

RTO answers one question: how long can a system stay down before the damage becomes unacceptable? For an ERP system that orders and shipments run through, an acceptable limit is often two to four hours. For an internal reporting archive, three days might be entirely fine.

RPO answers a different question: how much data can you afford to lose, measured as time since the last backup? If a system backs up once a night, its RPO is up to 24 hours - in the worst case, you lose an entire day’s worth of orders, invoices, and customer records.

Typical values by system type

System	Typical RTO	Typical RPO	Criticality
ERP / inventory management	2-4 hours	15 minutes	Revenue-critical
Email / communication	4-8 hours	1 hour	Important, workaround possible
File server / documents	24 hours	24 hours	Painful, rarely urgent
Archive / reporting	3-5 days	7 days	No immediate pressure

Why these numbers should come from the business, not IT

A common mistake: IT sets RTO and RPO on its own, without asking the business side. The result is either inflated requirements that get unnecessarily expensive, or values that are too lax and only become a problem once it’s too late. Sit down with sales, operations, and finance instead, and ask directly: what happens if this system is down for four hours? What if it’s 24? Those answers produce defensible targets - and a budget you can justify to leadership.

The 3-2-1 rule, updated for the cloud

The classic 3-2-1 rule is more than fifteen years old and is still the right starting point: three copies of your data, on two different types of storage, with one copy kept off-site. On its own, that’s no longer enough in the cloud era, because modern ransomware specifically targets backup systems before the actual encryption even begins.

That’s why the rule has grown two extra clauses, usually written as 3-2-1-1-0: one copy must be immutable or physically air-gapped, and every copy must be verifiably restorable with zero open errors. For a mid-sized company, that looks like this in practice:

• Production data lives on the primary system.
• A first copy sits on a separate storage target, either on-premises or in your own data center.
• A second copy lives in a cloud region, ideally with a different provider or at least under a fully separate account.
• At least one of these copies is stored immutably - more on that below.

The separate-account point gets overlooked constantly: if the same administrator account controls both the production environment and the backup system, a single compromised login is enough to take down both layers at once. Separate backup access technically and organisationally from the rest of IT administration - its own credentials, its own permission model, ideally its own multi-factor authentication.

Immutable backups: the single most effective lever against ransomware

Immutable backups, often stored on WORM media (Write Once, Read Many), cannot be deleted, overwritten, or encrypted for a defined retention period - not even by an administrator with full rights. The major cloud providers implement this through object locking: AWS S3 Object Lock, Azure Immutable Blob Storage, or comparable features from smaller providers such as Wasabi or Backblaze.

The reason this has become non-negotiable is simple: attackers who gain access to a network actively search for backup repositories and try to delete or tamper with them before triggering the actual encryption. Once the backup is gone, the pressure to pay the ransom rises sharply.

For the retention period, a simple rule of thumb applies: it should be longer than the time an attacker typically spends undetected inside a network before striking - usually several weeks. Many companies settle on a minimum of 14 to 30 days of immutability for routine backups, and 90 days or more for business-critical systems.

In practice, that means checking whether your current backup software has immutability actually configured - not merely available as a feature. Veeam, Acronis, Cohesity, and most established platforms support this out of the box today. The gap between “the feature exists” and “the feature is switched on” is one of the most common findings we see in audits.

Why an untested restore is worth nothing

Backup software almost always reports “job successful.” What it doesn’t tell you is whether that backup would actually produce a working system on restore. Corrupted database files, missing dependencies, or the wrong restore sequence usually surface only when it’s too late - in the middle of a real incident, under time pressure, with leadership on the phone.

A restore happens in stages, and the sequence determines whether it succeeds. In most environments, network and identity infrastructure - Active Directory, DNS - has to come back first, before databases can be restored, and only then the applications themselves. If that sequence hasn’t been rehearsed in advance, simply figuring it out during a real incident burns hours you don’t have - hours that count directly against your RTO.

Test-restore checklist

• Run the restore in an isolated test environment, never directly in production
• Test a full system restore at least once per quarter, not just individual files
• Time the process from start to a working application and compare it against your defined RTO
• Document the dependency order and verify it on every test
• After restoring, actually open the application and exercise a core function
• Involve a backup person who could perform the restore without the primary owner present
• Record the result, duration, and any issues in writing
• Fix the root cause of any deviation and rerun the test promptly
• Run one larger exercise per year that simulates a realistic incident, including customer communication
• Keep test records on file - cyber insurers and auditors increasingly ask for them

If this is the first time you’re reading this list in full: schedule your next test restore for the coming four weeks, not for “sometime this year.”

What backup and disaster recovery actually cost

Costs depend heavily on data volume, the number of systems involved, and the RTO/RPO values you’re targeting. As a rough guide for 2026:

Company size	Typical setup	Monthly cost
Small (10-30 employees)	Cloud backup for servers and endpoints, daily backup, basic immutability	€150-500
Mid-market (30-150 employees)	Managed backup service, multiple sites, hourly RPO for core systems, annually supervised DR test	€800-3,000
Larger mid-market (150-500 employees)	Geo-redundant replication, dedicated DR failover, quarterly tests	€3,000-12,000

These figures look steep to many executives at first glance. The counter-calculation puts it in perspective: depending on industry and value chain, an unplanned production outage typically costs mid-sized businesses somewhere between €1,000 and €10,000 per hour. If an outage following a ransomware incident stretches over several days, six-figure totals add up quickly - without a single euro of ransom ever being paid.

A sensible order of investment follows from that: secure immutability and tested restores first, then invest in tighter RTO values or additional sites. The first step costs comparatively little and closes off the biggest risk in one move.

Conclusion: three questions that decide the outcome of a real incident

A solid backup strategy doesn’t start with software - it starts with three questions: how long can a system stay down, how much data loss is acceptable, and when did you last actually restore something instead of just backing it up? A company that can answer all three honestly is already ahead of most mid-sized businesses we encounter during audits.

We help mid-market companies build backup and disaster recovery setups that match their real risk exposure - including immutable storage configuration and supervised restore testing, as part of our managed operations services. If you’re not sure your current setup would actually hold up in a real incident, a short conversation is usually enough to find out.