Backup & Disaster Recovery
A backup that's never been restored is a hope, not a plan. We define recovery objectives in writing, build to them, and prove them on a schedule.
Start from the objectives, not the software
Two numbers drive every design decision, and they're agreed with you in writing before anything is installed:
- RTO, recovery time objective. How long the business can be down. An hour? A day? The answer changes the architecture and the cost, and it's your call to make with real numbers in front of you.
- RPO, recovery point objective. How much work you can afford to lose. Fifteen minutes of a deal pipeline is different from a day of archived scans.
Different systems get different targets. The file server that runs the business is not the intern's laptop. The resulting document becomes the contract your backup infrastructure is measured against.
Coverage that matches how firms actually lose data
Microsoft 365 is backed up separately. Microsoft replicates your data for their availability, not your recovery: a deleted mailbox, a ransomware-encrypted SharePoint library, or a malicious insider is your problem, and native retention windows are shorter than most firms assume. Managed clients get independent, restorable backup of Exchange, SharePoint, OneDrive, and Teams.
Servers and workstations are imaged locally, typically to a Synology NAS, for fast restores, then replicated offsite so a fire, theft, or site-wide ransomware event can't take the backups down with the originals. The 3-2-1 shape (three copies, two media, one offsite) is the floor, not the aspiration.
Drills, because untested backups fail
Restores are drilled on a schedule: individual files, full mailboxes, and, periodically, a full server recovery into an isolated environment, timed against the written RTO. Every drill produces a short report: what was restored, how long it took, what failed, and what changed as a result. That report stack is also exactly what a cyber-insurance underwriter wants to see.
Ransomware assumptions built in
The design assumes the attacker gets in and goes for the backups first, because that's what modern ransomware does. Backup repositories use separate credentials that domain admins don't hold, offsite copies are immutable or air-gapped from production identity, and alerting fires on backup deletion and anomalous change rates, not just on job failures.
What's included
- Written RTO/RPO targets per system, reviewed annually
- Workstation, server, and Microsoft 365 backup
- NAS-based local restore tier plus offsite replication
- Immutable or isolated copies with separated credentials
- Scheduled restore drills with written results
- Nightly verification feeding the ops board. "Verified nightly" means verified.
FAQ
When was your last successful restore?
If you don't know the answer, your backups are a hypothesis. The assessment tests it.