Cloud, Backup & Recovery
Backup and disaster recovery you have actually tested
An untested backup is a rumor. We give you immutable off-site copies, documented recovery objectives, and scheduled restore tests that produce written evidence.
The question is not whether you have backups. It is how long recovery takes.
Almost every business we assess has something they call a backup. Far fewer can answer the questions that matter: when was the last successful restore test, how long would a full recovery actually take, and can ransomware reach the backup itself. That last one has become the decisive question, because modern ransomware operators specifically hunt for and destroy backups before they encrypt anything.
Immutability is the answer. Once written, a backup copy cannot be altered or deleted, by us, by you, or by an attacker holding stolen domain administrator credentials, until its retention period expires. That single property is the difference between an expensive weekend and an existential event.
Then there is the part nobody enjoys: testing. We restore on a schedule, document what we restored and how long it took, and give you the evidence. This turns your recovery time from an assumption into a number, which is exactly what your insurer, your auditor, and your own peace of mind require.
You probably need this if
- Nobody has tested a full restore in the last 90 days
- Your backup is reachable with the same credentials that run your network
- You could not state your recovery time objective if asked
- Backup is a local drive or a USB disk somebody swaps
- Microsoft 365 data has no backup outside Microsoft's own retention
- Your cyber policy or an audit is about to ask for restore evidence
What is included
Deliverables
What you actually get, in writing
Not a vague promise of support. Specific artifacts you can point at, hand to an auditor, or take with you if you ever leave.
Recovery objectives on paper
A specific recovery time and recovery point objective for every critical system, agreed in advance rather than discovered during an outage.
Restore test evidence
Dated records of what was restored, how long it took, and whether it validated. This is what an auditor or insurer wants to see.
Disaster recovery runbook
Step-by-step recovery procedure written so a competent technician who has never seen your environment could execute it.
Immutability confirmation
Documented proof that your backup copies cannot be deleted by an attacker who has compromised your domain administrator account.
Annual DR exercise report
A real rehearsal of a significant failure, with findings and corrections, not a checkbox on a compliance form.
Monthly health reporting
Success rates, storage growth, and any job that failed, surfaced before it becomes the reason a recovery does not work.
Questions
Questions about this service
How is this different from the backup we have now?
Three things, usually. Immutability, so ransomware cannot destroy the backup along with everything else. Testing, so your recovery time is measured rather than assumed. And documented objectives, so there is an agreed answer to how much data loss and downtime is acceptable for each system instead of an implicit hope that it will not come up.
What are RTO and RPO, in plain English?
Recovery time objective is how long you can be down. Recovery point objective is how much recent work you can afford to lose. A dental practice mid-schedule might need a two-hour RTO and a one-hour RPO for practice management, while the file server holding old marketing material could tolerate a day of each. Setting these per system is what keeps costs sane, because protecting everything at the highest tier is how backup budgets get out of hand.
How often do you actually test restores?
Quarterly for critical systems on the Pro and Elite plans, with a full disaster recovery exercise annually. You get written evidence each time. If a test fails, that is genuinely good news, because we found it on a Tuesday afternoon instead of during a real incident.
Can ransomware reach our backups?
With most setups we inherit, yes, and that is the whole problem. A backup drive attached to the server, or cloud storage reachable with domain credentials, is exactly what attackers target first. Immutable storage removes that path. Once a copy is written it cannot be modified or deleted until retention expires, regardless of whose credentials the attacker is holding.
Do you back up our practice management or tax software?
Yes, and this needs handling specifically. Databases used by Dentrix, Eaglesoft, Open Dental, Lacerte, UltraTax, Drake, Clio, and similar platforms often require application-aware backup or a quiesced state to restore cleanly. Copying the files while the database is live can produce a backup that appears fine and will not restore. We configure and verify these per application.
Want to know where you stand right now?
The assessment documents your environment, scores it against a modern baseline, and hands you a written report you keep either way.
No pressure, no obligation. If we are not the right fit we will tell you and point you somewhere better.