Backup & Disaster Recovery

An untested backup is a hope, not a plan. We verify that yours restore, and we tell you how long a real restore takes before you need to know.

The failure is rarely that no backup existed. It is that the backup covered the file server and not the database, or it ran for eleven months and stopped in month twelve, or it restored — slowly — into an environment that no longer had anywhere to put it. None of that is visible until someone tries.

Recovery time and recovery point objectives are the whole design, and most businesses have never been asked for them.

Your recovery point objective is how much data you can afford to lose, measured in time. Backing up nightly means accepting that a Thursday afternoon failure costs you Thursday. Your recovery time objective is how long you can afford to be down. These are business decisions with a cost attached, not technical settings — and the honest version of the conversation is that halving either one roughly doubles what it takes to achieve.

Set them deliberately and everything else follows. Skip them and you end up with whatever the software defaulted to, discovered at the worst possible moment.

The old advice — three copies, two media, one offsite — was written for fire and hardware failure. It assumes your backups are bystanders.

They are not. Modern ransomware looks for backup systems first, because an attacker who encrypts your data and your backups has removed your only alternative to paying. Deleting or encrypting the backup server is a standard step, not an unlucky one.

What answers that is immutability: copies that cannot be altered or deleted for a defined period, by anyone, including someone holding your administrator credentials. If a backup can be deleted by a compromised admin account, it is not protecting you from the thing most likely to happen.

This is the most common and most expensive misconception we meet, and it is entirely understandable — the data is in the cloud, so it feels handled.

Microsoft's responsibility is keeping the service running. Yours is the content in it. Retention policies, the recycle bin and version history are useful, and they are not backup: they expire, they can be changed by an administrator, and they do not help against a deletion nobody noticed for a quarter or a mailbox emptied by an account takeover.

If your business runs on SharePoint, OneDrive, Exchange Online and Teams, that is the data you cannot lose — and it is worth knowing exactly what would happen to it, rather than assuming.

A real recovery has an order, and the order is where unrehearsed plans fall apart. Identity comes back before the applications that authenticate against it. DNS and network routing come back before anyone can reach either. Dependencies nobody documented surface exactly here.

There is also the question nobody plans for: where do people work while this is happening? A recovery that is technically complete in two days is still two days your business did not operate. Continuity — what staff do in the meantime, how customers are told, who decides — is a separate plan from recovery and it is usually the one missing.

The way to find these things out is a rehearsal, on a day you chose, rather than a Tuesday you did not.

Backup and recovery are not an operational nicety for a defense contractor. Media protection, system and information integrity, and incident response are all families of NIST SP 800-171, and an assessor will ask what your plan is and expect evidence rather than intent.

Where the backups themselves hold CUI, they inherit the same boundary as everything else — where they are stored, who can reach them, and under whose control. Our shared responsibility matrix sets out which of those rows typically sit with a provider and which stay with you.