Backup & recovery

Would your backup actually restore?

Only if someone has tried it recently. A backup job reporting success means data was written somewhere. It says nothing about whether the data is complete, whether the system it belongs to can be rebuilt, or how many hours that would take. The restore test is the control. The job status is not.

Four ways backups fail quietly

Incomplete scope. The file server is protected and the line-of-business database is not, because it was added after the backup was configured and nobody revisited it.
No tested restore. The job succeeds for two years, and the first real attempt reveals a corrupt chain or a missing dependency nobody accounted for.
Reachable from the thing you are protecting against. Backups on the same domain with the same credentials get encrypted alongside everything else. Modern ransomware looks for them specifically.
Recovery time nobody costed. The data is fine and restoring it takes four days over your circuit, which is a different problem but the same outage.

RPO and RTO, in hours you can argue about

Two numbers decide what your backup needs to be. Recovery point objective is how much recent work you can afford to lose. Recovery time objective is how long you can be down. Both are business decisions, and technology follows them rather than the other way around.

What the objectives imply

If the business says	The recovery design implies	What usually blocks it
We can lose a day and be down two days	Nightly backup, restore from a copy off-site	Nothing much. This is achievable almost everywhere
We can lose an hour and be down four hours	Frequent snapshots and the ability to run systems from the backup copy	Bandwidth, and whether anyone has practiced the failover
We cannot lose anything and cannot be down	Replication and standby infrastructure, priced accordingly	Cost, and applications that were never built to fail over

Most companies have never stated either number. Asking a leadership team how many hours of downtime is tolerable, and how many hours of lost work, turns a technical argument into a budget decision that can actually be made.

A restore test you can run this quarter

Pick one system that matters and one that people would notice within an hour.
Restore it somewhere isolated, not over the top of production.
Have someone who uses the system daily confirm the data is right, rather than confirming a file count.
Time it, from the request to a usable system, and write the number down.
Compare that number to the recovery time the business said it needed.
Repeat with a different system next quarter, so coverage rotates instead of testing the one thing you know works.

The number you write down is more useful than any status dashboard, because it is the only figure that has been proven rather than assumed.

The ransomware question changes the design

Recovery from ransomware is not the same problem as recovery from a failed disk. You need copies an attacker with domain credentials cannot reach or delete, retention long enough to reach back past the point where they got in, and a way to tell which restore point is clean.

That last part gets underestimated. Attackers often sit in an environment for weeks before encrypting anything, so the most recent backup may already contain their access. Retention and immutability matter for exactly this reason.

Where this sits in an engagement

Backup design, off-site copies, retention, and scheduled restore testing sit in Backup & Disaster Recovery, and restore verification is part of the ongoing work in Managed IT rather than an add-on. If you are not sure what is currently protected, an IT assessment answers that in writing, including whether a restore has ever actually been attempted.

Questions we hear first

How often should we test a restore?

Quarterly for the systems the business cannot work without, and at least annually for everything else. Also test after any material change: a new application, a server migration, or a change to the backup product itself.

Is cloud backup enough on its own?

It covers the off-site copy well. What it does not automatically give you is a fast recovery time, and restoring a large dataset over a business internet connection can take days. That gap is why recovery time gets designed separately from where the copy lives.

Does Microsoft 365 back itself up?

It has retention and recycle bins, which are not the same thing as a backup you control. Retention windows expire, and a deletion or a malicious action inside the window can still lose data permanently. Most companies with compliance obligations add a separate backup for the tenant. See Microsoft 365.

What is immutable backup?

Storage where a copy cannot be changed or deleted for a set period, even by an administrator account. It exists because attackers go after backups first, and it is the difference between having a copy and having a copy they cannot reach.

We do not know what is protected. Where do we start?

With an inventory rather than a product. An IT assessment establishes what exists, what is covered, and what a restore would actually take. Start at Become a Client or call (513) 657-1800.