Backup and recovery you have actually tested
A backup nobody has restored from is a hypothesis. Jobs report success every night; nobody has confirmed the data actually comes back, and untested backups fail at the worst possible moment.
What we set up
A 3-2-1 backup pattern: three copies of your data, on two different types of storage, with one copy offsite and immutable so ransomware that reaches your primary systems cannot also encrypt or delete the backup.
Restore testing is not optional
We schedule real restore tests, not just job-success notifications, and document how long a real recovery takes against how long your business can actually tolerate being down.
A recovery plan you can hand to anyone
A written runbook naming which systems come back first, who is authorized to make that call, and what a partial recovery looks like, so a bad day has a checklist instead of a debate.
What's included
Specific deliverables, not a vague promise to "handle IT."
- A 3-2-1 backup architecture: three copies of your data, on two different media types, with one offsite and immutable
- Ransomware-resistant configuration, including an air-gapped or immutable copy that ransomware reaching production cannot also encrypt
- Scheduled real restore tests, not just monitoring that a backup job reported success
- Documented RTO and RPO targets matched to what your business can actually tolerate, discussed case by case rather than assumed
- A written recovery runbook naming system priority order and who is authorized to make the call
- A quarterly restore test report so you have evidence the backups work, not just a claim that they do
How this engagement works
Current backup audit
What exists today, what's actually being tested, and what isn't.
3-2-1 architecture implemented or hardened
Built around what you already have where it's sound, replaced where it isn't.
First real restore test
Run and documented, so you have evidence rather than a job-success notification.
Ongoing scheduled testing
Plus a runbook that's kept current as your systems change.
Questions about backup & recovery
How do you test a restore without disrupting production?
Into an isolated environment, separate from anything live, so testing itself carries no operational risk.
What's a realistic recovery time for a business our size?
Depends on the systems and data volume involved; this gets discussed and documented case by case rather than quoted as a general figure.
Do you handle the actual recovery during a ransomware event?
Yes, that's exactly what the runbook is built for.
Cloud backups, on-prem, or both?
Matched to where your production systems already live; most setups end up as a mix.
Other services
Start with an assessment, not a contract
A short scoping call, then a fixed-price review of your security, cloud and support setup. You keep the findings either way.