Backup and Disaster Recovery Services That Get Tested

Usually the answer to one question: when was the last time someone restored from them. Backup software reporting a successful job is not evidence that the data is usable, that the right systems are included, or that anyone knows the sequence to bring the business back. We have found jobs running successfully against a server that was decommissioned, backups of a database that were unusable because the application was never quiescing writes, and complete backup sets sitting on a share the ransomware would have encrypted along with everything else. Testing is what converts a backup into a recovery capability.

Recovery point objective is how much data you can afford to lose, measured in time: if backups run nightly, a failure at 4pm loses a day of work. Recovery time objective is how long the business can operate without the system. You decide both, per system, because they are business judgments rather than technical ones. Our role is to tell you honestly what each target costs to achieve and to design to the targets you choose, then write them down so expectations are explicit before an incident rather than contested during one.

It generally does, and this catches organizations out. Microsoft operates the platform reliably and provides retention and recycle-bin features, but those are limited in duration and are not a customer-controlled backup you can restore from after a deletion goes unnoticed, an account is compromised, or a departing employee cleans up their mailbox and files. Under the shared responsibility model, your data remains your responsibility. A separate backup of Exchange Online, SharePoint, OneDrive, and Teams data closes that gap.

By being unreachable from the environment that gets encrypted. Modern ransomware operators specifically hunt for backup infrastructure and delete or encrypt it before triggering the payload, because destroyed backups are what forces payment. The countermeasures are immutability, so stored copies cannot be altered or deleted within their retention window; separation of credentials, so domain administrator access does not grant backup access; and an offsite copy outside the blast radius. A backup server joined to the same domain with the same credentials is one compromised account away from being worthless.

Backup is a copy of data. Disaster recovery is the documented, tested ability to resume operating. That needs the copy plus somewhere to run, the order in which systems must come back, the network and access to reach them, and people who know the procedure. Organizations with excellent backups still suffer long outages because nobody had planned where a restored server would run or which system had to come up first. We plan for the recovery, not just the copy.

Our technical scope is systems and data. Full business continuity planning extends further (alternate premises, staff communication, manual workarounds, and customer notification) and works best when the technical recovery plan feeds into it. We produce the technical component and the documented recovery sequence, and we will happily participate in a broader continuity exercise with whoever owns it. If a compliance framework requires contingency planning, our compliance practice covers that documentation requirement.