An untested backup is a rumour
The most common failure we see isn't an absence of backups. It's backups that have been silently failing for months, or that nobody has ever tried to restore from. The first attempt at a restore should never happen during an actual emergency, and yet for a great many businesses that's exactly when it does.
So the testing matters as much as the backing up. We restore from your backups on a quarterly schedule and give you written confirmation of what was restored and how long it took. That document is also the thing insurers and auditors ask to see.
What's protected
- Servers: full image backups, so a failed machine can be rebuilt rather than reassembled by hand
- Endpoints: laptops and desktops, including the files people keep locally despite being told not to
- Microsoft 365: mail, OneDrive, SharePoint and Teams, which Microsoft does not back up for you
- Databases and line-of-business systems: backed up consistently rather than mid-write
Why immutability matters now
Modern ransomware looks for backups first. If your only copy sits on a network share the encrypted server can reach, you don't have a backup. You have a second casualty. Immutable backups can't be altered or deleted for a set retention period, even by someone holding admin credentials. Combined with an offsite copy, that's what turns a ransom demand into an inconvenience.
Two numbers worth agreeing before anything goes wrong. Your recovery point objective is how much data you can afford to lose, measured in time. Hourly snapshots mean at most an hour's work. Your recovery time objective is how long you can afford to be down. Most people have never been asked either question, and the answers change what the right solution costs.
When something does go wrong
Recovery follows a documented runbook rather than improvisation: what gets restored first, in what order, and who needs telling. For a single deleted file that's a few minutes. For a failed server it's a rebuild from image. For a serious incident it means standing systems back up in a clean environment and verifying them before anyone reconnects.
The runbook is written in advance and kept with your documentation, because the middle of a crisis is a terrible time to be working out the order of operations.
Common questions
How often are backups taken?
Typically hourly for critical systems and daily for the rest, though it depends on how much data you can afford to lose. We agree that with you rather than applying a default.
How long is data kept?
Retention is configurable and often driven by your sector's requirements. Long retention is useful when a problem is discovered months after it started, such as slow data corruption.
Where is the data stored?
In UK data centres, with an offsite copy kept separate from your live environment so a single incident can't take out both.
Can you restore a single file, or is it all or nothing?
Individual files, mailboxes, or entire systems. Day to day, single-file restores are by far the most common request.