Datto BCDR
Continuity is measured in minutes, not in copies held
Datto's BCDR model pairs an on-site appliance with a purpose-built cloud. When a server fails, the protected system is booted from the appliance and the business continues while the underlying problem is addressed. Backup is the mechanism; continuity is the product.
The distinction that decides the purchase
Backup answers the question of whether the data still exists. Continuity answers the question of whether the business can operate this afternoon. They are related but they are not the same product, and organizations routinely buy the first while believing they have bought the second.
The gap becomes visible at the worst moment. A file-level backup to cloud storage is genuinely protective of the data and completely inadequate when a server has failed, because restoring a full system across an internet connection takes as long as it takes, and the business is stopped for the duration.
A continuity appliance removes that wait by holding a recoverable image locally and being able to run it. The failed server is replaced by a virtual copy in minutes, and the restore happens afterwards without anybody waiting on it.
What each component contributes
| Component | Function | What it protects against |
|---|---|---|
| On-site appliance | Holds recent images, boots them locally | Hardware failure, fast recovery |
| Cloud replication | Copies images off site automatically | Fire, flood, theft of the site |
| Cloud virtualization | Runs the workload in the cloud | Loss of the premises entirely |
| Screenshot verification | Boots each backup and photographs the result | Backups that never actually worked |
| Ransomware detection | Flags encryption patterns between snapshots | Restoring an already infected image |
| Combined effect | Recovery time measured in minutes | Days of stopped trading |
Recovery time compared
The chart sets out elapsed time from failure to a working system under three approaches. The differences are not marginal, and they are what a continuity product is actually sold on.
Screenshot verification, and why it matters more than it sounds
Each backup is booted automatically in an isolated environment and photographed at the login screen. The result is a dated image proving the system came up.
This addresses the most expensive failure in the field, which is a backup job reporting success while producing an image that cannot boot. Job status reflects whether the copy completed, not whether the copy is usable, and the difference is only discovered under pressure unless something tests it deliberately.
| Assurance | Backup job status | Boot verification |
|---|---|---|
| Data was copied | Yes | Yes |
| Image is not corrupt | No | Yes |
| System will start | No | Yes |
| Evidence for an insurer | A log entry | A dated screenshot |
Qualification, stated plainly
This suits organizations that still run servers on their own premises and would lose money by the hour if one stopped: practices, manufacturers, professional firms with line-of-business applications that cannot simply move. The local appliance is the whole point, and it is why the model persists in an otherwise cloud-first market.
It suits an all-cloud organization considerably less. If the workloads already run in a cloud platform with no on-premises servers, the appliance protects little and a cloud-native backup is the more sensible fit. Hardware also means capital or a longer term commitment, which is worth costing against that alternative honestly.
Book the continuity review
A short session establishing which systems would stop the business if they failed this week, and how long each would take to bring back with what is in place today.
Book the reviewGet in touch with Your Company
Questions about this solution? Reach us directly.