What If the Server Dies Tonight?

The short answer

You do not have a backup until you have restored one. Most businesses that believe they are backed up have an automated job nobody has watched in a year, writing to a place nobody has tested, in a format nobody has opened.

Two numbers decide everything else. How much data can you afford to lose, and how long can you be down. Write both down, then build to them.

The two numbers

If you can lose at most a day of orders, a nightly backup is enough. If losing an afternoon of transactions would be a serious problem, nightly is not enough and you need something continuous.

If you can be down for a day while someone rebuilds a server, a copy of the database is sufficient. If you need to be back in an hour, you need the server configuration captured too, because provisioning a machine from memory under pressure takes longer than anyone estimates.

Most small businesses, asked honestly, land on a day of data and a day of downtime. That is a cheap target. The expensive mistake is assuming a much stricter target without paying for it, then discovering the gap during the outage.

What a real backup looks like

• Somewhere else. A backup on the same server is a copy, not a backup. It dies with the thing it was protecting.
• More than one generation. If corruption or a bad deployment went unnoticed for three days, a single overwritten nightly file contains the problem rather than the solution.
• Everything, not just the database. Uploaded files, images and documents usually live outside the database and are usually the thing nobody included.
• Restorable by someone other than one person. Written down, in enough detail that a competent stranger can follow it.
• Monitored. A backup job that has silently failed for six weeks is the normal way this goes wrong, because nothing alerts when nothing happens.

Restore drills

Once a quarter, restore to a scratch environment and actually look at it. Does the application start? Is last week's data there? Do the uploaded images resolve, or do they point at paths that no longer exist?

That last one catches people constantly. The database restores perfectly and every product photo is a broken link, because the files were never in the backup and nobody checked. You find that in a drill in twenty minutes, or in a real outage over two days.

Write down how long the drill took. That number is your honest recovery time, and it is usually longer than the one in the plan.

Ransomware changes the shape

If your backups are reachable from the same credentials as the live system, an attacker encrypts both. Keep at least one copy that the production system cannot write to or delete, whether that is object storage with retention locks, an account with different credentials, or something genuinely offline.

This is the one part of a small business backup plan that is worth paying extra for, because it is the one failure mode where having backups and not having them look identical.

If the system in question was built by someone you can no longer reach, read what to do when a vendor disappears first, because the backup question becomes urgent rather than theoretical. The wider baseline is in security basics for a small business.

Frequently asked questions

How often should I back up?

As often as the amount of work you are willing to redo. Nightly suits most small businesses. If a lost afternoon of orders would be serious, you need better than nightly.

Is my hosting provider backing up?

Possibly, on their terms, for their retention period, recoverable at their speed. Read what you are actually entitled to, and keep your own copy regardless. Their backup protects their platform; yours protects your business.

Do I need offsite backups?

Yes. Same building, same provider and same account all share failure modes with the thing you are protecting.

How do I know my backup works?

Restore it. There is no other way to know, and a backup that has never been restored is a belief rather than a fact.

What should I back up besides the database?

Uploaded files, configuration, environment variables and any certificates. The database is the part people remember. The uploads are the part that breaks the restore.