Home / IT Security / Backup & Disaster Recovery
“We have backups” is a belief. A tested restore is a fact.
Backups an attacker cannot delete, a recovery you have actually rehearsed, and an RPO and RTO your leadership has agreed to in advance.
The control that decides whether a ransomware incident is a bad week or the end of the company.
Ransomware crews delete backups first. If yours can be reached from the network that got encrypted, you do not have backups — you have a second copy of the problem.
Modern attackers hunt backups deliberately, because a company that can restore does not pay. So the question is never “do you have backups” — it is whether a copy exists that the attacker could not reach, whether you have proven you can restore from it, and how long that restore actually takes.
We build to a simple, old rule and one modern addition: 3-2-1 — three copies, on two types of media, one off-site — plus at least one copy that is offline or immutable, so it cannot be encrypted or deleted even by someone with domain admin. Then we test the restore, because an untested backup is a hypothesis.
Every recovery plan reduces to these. Most companies have never set them.
RPO — Recovery Point Objective
How much data can you afford to lose, measured in time? An RPO of one hour means backups every hour; an RPO of 24 hours means a bad day could cost you a day of work. This decides backup frequency — and its cost.
RTO — Recovery Time Objective
How long can you be down before the damage is serious? An RTO of four hours demands a very different design from one measured in days. This decides architecture — hot standby, warm spare, or restore-from-cold.
We help you set both against what the business can actually tolerate, then build to hit them — and, critically, prove we hit them in a test rather than promise it in a document.
Design, implement, and — the part that counts — rehearse.
- Backup design
- 3-2-1 across servers, endpoints, cloud workloads and SaaS (yes, Microsoft 365 and Google Workspace need their own backup — the provider is not it).
- Immutable / offline copy
- At least one copy the attacker cannot alter: object-lock immutability, or genuinely offline media. This is the copy that saves you.
- Encryption
- Backups encrypted in transit and at rest, with key management that does not defeat the point.
- Restore testing
- Scheduled, documented test restores — file-level and full-system — with the actual time-to-recover recorded against your RTO.
- DR runbook
- The written, step-by-step recovery procedure: order of restoration, dependencies, who does what. Usable by an engineer who was not there when it was written.
- DR rehearsal
- A recovery exercise against a realistic scenario, so the first full restore is not during the real thing.
Where this connects.
Incident response
A tested restore is the backbone of ransomware recovery. The IR plan assumes the backups it names actually work.
Server management
If we run your servers, restore-tested backups are already in the baseline, not a separate purchase.
Compliance
Auditors and insurers increasingly require proof of tested recovery. The test records feed straight into GRC.
When did you last restore from your backups — for real?
If the honest answer is “never” or “I'm not sure,” that is the engagement. Tell us what you are protecting and we will design the recovery around it.
Contact us- info@bstedge.com
- Response
- Within one business day
- Standard
- 3-2-1 plus an immutable copy