Everyone has backups. Ask around any office and someone will say the server backs up every night, the laptops go to the cloud, and the email is "in Microsoft" or "in Google." Then ask one question: when did you last restore something from it?

The room goes quiet. That silence is the gap between having backups and having a recovery.

What a real setup looks like

Four parts. Miss any one and you have a hope, not a plan.

Copies away from the source. A backup on the same machine, or reachable with the same password, dies with the machine or the password. Real backups land somewhere the source cannot touch. Off-site, in a separate account, with separate credentials.

A locked copy where ransomware is the worry. Modern attacks go for the backups first, because an attacker who deletes your backups gets paid. An immutable copy is one that nobody, including an attacker holding your admin password, can change or delete inside the lock window. Thirty days is a common window.

Everything that holds company data. The file server, yes. But also the documents folder on the sales manager's laptop, the accounting database, and the mailboxes. Microsoft and Google keep their services running. They do not keep your deleted mailbox for you. Mail, OneDrive, SharePoint, Drive and shared drives need their own backup, outside the provider.

Restores on a schedule, with results written down. Restore a real file. Restore a whole system. Time it. Note what worked and what did not. A backup nobody has restored is a backup nobody knows works.

Two numbers to agree before anything else

How much data can you afford to lose? If the answer is a day, nightly backups are fine. If it is an hour, you need something more frequent for that system.

How long can you be down? If the answer is a week, a slow restore is acceptable. If it is two hours, the design has to be built for that, and tested against it.

These are business decisions, not technical ones. Decide them per system. The accounting database and the shared drive of old photos do not need the same answer.

Write the two numbers next to each system on one page. That page is what you hand to a provider, and it is how you judge the design they come back with. A backup that runs once a night cannot meet a one-hour loss target, however good the software, and no number of green ticks changes that.

Then write the steps down

A recovery runbook is a page per system: what to restore, in what order, from which copy, with whose credentials, and who makes the call. It lives somewhere you can read it when the office is dark and the server is the thing that broke. A plan in someone's head is a plan that leaves when they do.

The afternoon you will be glad of it

What the cloud does and does not do

Keeping email and files in Microsoft 365 or Google Workspace does not remove the need. Both will bring back a deleted file for a while. Neither will bring back a mailbox an attacker emptied before anyone noticed, or a shared drive wiped by a sync error six weeks ago. The platform's job is to keep the service up. Keeping your copy is yours.

A disk dies. A laptop is stolen from a car. Someone deletes the wrong folder at 4:55 on a Friday. A fake invoice attachment encrypts the shared drive. None of these are rare. Each one is a phone call, a restore and a short wait when the setup above exists. Each one is a very long week when it does not.

What ALCO does

Every site and application we host is backed up nightly and the copies kept off-site, as standard. For client systems, we rank what must come back first, agree the two numbers above per system, set up off-site and locked copies, back up Microsoft 365 and Google Workspace outside the provider, back up laptops in the background, and restore real files and systems on a schedule with the results recorded. The runbook is kept where you and we can both read it. Deleted the wrong folder? Call the help desk. A restore is a request, not a project.

The full scope is at https://alcohq.com/services/backup-and-disaster-recovery

One thing to do this week

Pick one file. Ask for it to be restored from last week's backup. Time how long it takes and write down the date. That single test tells you more than any dashboard.