Tested restores, not just backups that exist.
A backup job that reports success tells you the write happened. It doesn't tell you the archive still opens, the encryption key hasn't rotated out from under it, or the restore finishes before the business does. We test the restore on a schedule, not just the backup.
What this is
Most setups that say they have backups have written to them for years and restored from them never. The backup log says success right up until the day it actually matters, and that's the first time anyone finds out the archive is corrupt, the encryption key expired two rotations ago, or the schema is too old for the current restore tooling to open. The work here is closing that gap directly: a restore gets tested on a schedule, onto a clean environment, before it's the only copy left.
RPO and RTO aren't marketing terms, they're the two numbers that decide the entire design. RPO is how much data you can afford to lose, the gap since the last usable backup; RTO is how long you can be down before the outage costs more than fixing it would. An RPO near zero needs continuous replication, not a nightly snapshot job. An RTO measured in minutes needs a warm standby ready to take traffic, not a restore-from-cold-storage plan where the download alone takes six hours. We size the backup to numbers you actually state, not to a generic 'daily backup' default that happens to be what the platform ships with.
The pattern underneath is 3-2-1 with one addition that matters against ransomware specifically: three copies, on two kinds of media, one of them offsite, and at least one copy the production account cannot delete or overwrite even with valid credentials, using object lock or equivalent write-once storage. That last part is the one setups skip. If an attacker who compromises production can reach the backups with the same stolen credentials, the backups were never actually a second copy, they were the same copy with a different label.
The last piece is the runbook: the order of operations for a declared disaster, decided in advance rather than argued out loud during it. Database before the application that reads it, DNS considered before anything else goes live, and a named person with the authority to actually call it. Writing that down before 3am beats discovering it during.
What you get
A backup design sized to RPO and RTO
Built against numbers you state, not a generic daily-backup default that happens to be the platform's out-of-the-box setting.
3-2-1 with an immutable copy
An offsite copy, and at least one the production account can't delete or overwrite even with valid credentials.
Automated backup jobs
Databases, file storage and configuration covered, based on what actually needs to survive, not just what was easy to script first.
A scheduled restore drill
Backups actually restored onto a clean, isolated environment on a real cadence, with the result written down.
A disaster recovery runbook
The exact order of operations, who's authorized to declare a disaster, and who does what in the first hour.
Monitoring and alerting on the jobs
A failed backup gets caught the next morning by an alert, not the next disaster by a person who needed it.
A retention policy that matches reality
Sized to actual legal and operational requirements, not an arbitrary 'keep everything forever' default that costs money for no benefit.
Handover documentation
The restore procedure written down well enough to work even if we're not the ones running it.
When this fits, and when it does not
A good fit
- You have backups today and have genuinely never restored from them, so you don't actually know if they work.
- Ransomware is a real concern, and the current backups sit in the same account and credentials as production, meaning they'd be deleted along with everything else.
- Downtime has a cost you can put a number on, and the current setup was never designed against an actual RTO.
- A compliance or insurance requirement specifies a tested recovery plan, not just backups existing as a checkbox.
- Nobody currently on the team could run the recovery tonight if it were needed, because it's never been written down.
Not a good fit
- What you actually want is faster releases with an easy rollback for a bad deploy. That's DevOps and CI/CD; a deploy rollback and a disaster recovery plan solve different kinds of failure.
- You're moving providers or off on-premise entirely. That's cloud migration, and disaster recovery for the new environment is worth designing once it exists, not mid-move.
- What worries you is whether someone could break in, not whether you could recover afterward. That's penetration testing and security review.
- It's a personal project or a low-value prototype where losing everything and starting over is a genuinely acceptable outcome. A scheduled cloud snapshot and a free afternoon covers that; this is more than it needs.
- You want us to promise zero data loss and zero downtime. Nobody can promise that honestly; we size RPO and RTO to a number you can actually defend instead.
How it runs
- 01
Define RPO and RTO
How much data loss and how much downtime the business can actually absorb, in writing, before anything gets designed.
- 02
Design the backup
What gets copied, how often, and where the immutable offsite copy actually lives.
- 03
Build and automate
Backup jobs wired in, monitored, and alerting the moment one fails.
- 04
Run the restore drill
A real restore onto a clean environment, on a schedule, with the result recorded rather than assumed.
- 05
Hand over the runbook
The recovery order of operations and who's authorized to call it, documented for your team.
Questions we get
How is this different from just turning on our cloud provider's automatic backups?
The provider's default usually satisfies 'a backup exists' and stops there. We size it to a stated RPO and RTO, add an immutable copy the production account can't delete, and most importantly test the restore on a schedule. The default rarely includes any of those three.
How often do you actually test a restore?
On a defined cadence, typically quarterly, onto an isolated environment that never touches production. The point is finding a broken backup while it's an inconvenience, not while it's the only copy left.
Is this only about ransomware?
No. A deleted database, a botched migration, a provider region outage, a ransomware attack, and someone's mistaken production delete all end the same way: you need a restore that works. The plan doesn't change much by cause.
Do you manage the backups ongoing, or hand it over after setup?
Either. Some clients want it running and monitored by us on an ongoing basis, others want it fully documented and handed to their own team from day one. We agree which one before the engagement starts.
Not sure your backups would actually restore?
Tell us what you're protecting and how long you could afford to be down. An engineer gives you a straight answer, including whether what you already have is close enough.