Backup and Recovery: A Strategy You Can Actually Trust

A backup you have never restored is a hypothesis. Decide how much data you can lose and how long you can be down, keep at least one copy somewhere an attacker with your admin password cannot delete, and restore something real every quarter with a stopwatch running. That is the whole strategy. Everything else is tooling preference.

Confidence is not the same as recovery

Veeam’s 2026 research is uncomfortable reading because it measures the gap between belief and outcome. Ninety per cent of the leaders surveyed said they were confident in their ability to recover from a cyber incident. Fewer than one in three ransomware victims actually recovered all of their data, and the average organisation got back 72% of what was affected. Veeam’s own summary of the findings reports that of those hit, 56% faced encryption or exfiltration and 44% recovered less than three quarters of the affected data.

Downtime has a price even when the data comes back. The Uptime Institute’s 2026 annual outage analysis found 57% of respondents put the cost of their most recent major outage above $100,000, and one in five above $1 million. Your numbers will be smaller. The ratio will not be: a day of lost trading nearly always costs more than a year of doing backups properly.

Write down two numbers: RPO and RTO

Two numbers drive every technical decision that follows, and they are business decisions, not IT ones. Recovery point objective is how much data you are willing to lose, measured in time. Recovery time objective is how long you can be down. Ask the person who answers the phone when customers complain, not the person who runs the server.

The copies that survive a bad week

The old three-two-one rule still holds up: three copies of the data, on two different kinds of storage, with one of them offsite. In a cloud-first estate that usually means the live data, a snapshot or backup in the same provider, and a copy in a different provider or region that uses different credentials.

• Different credentials matter more than different buildings. If one compromised administrator account can delete the live data and the backup, you have one copy with extra steps.
• Snapshots are not backups. They usually live in the same account, often in the same region, and they are deleted by the same API call an attacker would use.
• SaaS data needs its own plan. Microsoft 365 and Google Workspace replicate for availability, not for your mistakes. Retention windows are finite and a deliberate mass deletion survives them.
• Include the configuration. DNS records, firewall rules, infrastructure code, CI secrets and runbooks. Data without configuration takes days longer to recover.

Durability of the storage itself is rarely the weak link. AWS states that S3 is designed for 99.999999999% durability, eleven nines, with 99.99% availability by default. The failures we actually see are a backup job that silently stopped three months ago, a retention policy that overwrote the only good copy, and a restore nobody had practised.

Make one copy immutable

Immutability is the single biggest improvement most small estates can make this quarter. Object lock applies a write-once-read-many model: AWS documents that S3 Object Lock can prevent objects being deleted or overwritten for a fixed period, a variable period or indefinitely, using retention periods and legal holds. Azure and Google Cloud offer equivalent controls on their object storage.

Set a retention period that matches your longest plausible undetected compromise, not your shortest. Thirty days is a reasonable starting point for operational backups, with quarterly or annual copies kept for compliance. Lock the bucket policy too, and keep the account that owns the backups separate from the account that runs production.

What a year of backups actually costs

Backup storage is cheap, which removes the last excuse. These are AWS list prices for US East (N. Virginia), read in October 2026, with 1 TB taken as 1,024 GB.

The sensible pattern is tiered: the last 14 days in a fast tier so an operational restore is quick, monthly copies in flexible archive, and annual compliance copies in deep archive under object lock. The whole thing for a small business usually lands somewhere between the cost of a mobile phone contract and a cheap laptop per year.

Test the restore, on a date, with a stopwatch

A restore test is a diary entry, not a feeling. Put it in the calendar quarterly, assign it to a named person, and record three things: what you restored, how long it took from decision to working, and what went wrong. The third column is the valuable one.

1. Pick a real target. A database to a scratch environment, or ten files a user asked for last month. Not a test file you created this morning.
2. Start the clock when you decide, not when the download starts. Finding credentials and the right snapshot is part of your real recovery time.
3. Verify the data, not the job status. Open the records. Check row counts, check a recent transaction, check the file opens.
4. Write the actual time next to your RTO target. If it took six hours against a four-hour target, you have a decision to make about budget or expectations.
5. Fix one thing before the next test. Shorter restore path, better documentation, pre-staged credentials. One improvement per quarter compounds fast.

We run this cycle for international clients remotely: backup design, immutable offsite copies, documented runbooks and a quarterly restore test you receive a report on, as part of our cloud solutions work. If you are deciding where those copies should live, single cloud versus multi-cloud is the relevant trade-off, and the cost guide explains the storage tiers in more detail. It also helps to be clear about which parts of backup your provider is responsible for, which is covered in the shared responsibility model.

Not sure your backups would survive a bad Monday? Ask us for a restore test and an honest assessment. Get in touch with Eudora Technology to talk about your project.