Can you restore your data from backup?
Almost every business we ask says the same thing: “yes, we have backups”. It is the second question that changes faces: “when did you last check that they restore?”. Often the answer is never. A backup that has never been tested is not protection, it is an assumption.
This article explains what to check, without technical jargon, so you know whether your business would survive a bad day.
Three questions that reveal the real situation
Before anyone talks about technology, three answers need to be clear. If one is missing, that is where the problem is.
- What exactly is being backed up? Often the main server is covered, but not cloud email, not the database behind the invoicing software, not the files on staff computers. List your systems and mark which ones are covered.
- Where is the copy kept? If the copy sits on the same server or in the same office, a fire, a theft or a ransomware attack takes both at once.
- How long would it take to get back to work? A copy that takes three days to restore may be useless for a clinic, but perfectly acceptable for an archive.
The 3-2-1 rule, explained simply
It is the best-known standard and it is easy to remember: three copies of your data, on two different types of media, with one of them off-site.
- Three copies — the original plus two backups. If one is damaged, the other remains.
- Two media — for example the server disk and a NAS, or a NAS and the cloud. You are not relying on a single type of device.
- One off-site — in another location or in the cloud. This is the copy that saves you from fire, flood or theft.
Many now extend it to 3-2-1-1-0: one immutable or offline copy, and zero errors on verification. The immutable copy matters particularly against ransomware, because attackers today deliberately look for backups before they encrypt anything.
Backups used to protect against a failing disk. Today they protect against someone with access to your network who will deliberately delete your copies. That is why a backup permanently connected to the same network, with the same credentials, is no longer enough.
Two numbers to settle before buying anything
These are business decisions, not technical ones. You answer them, not your technicians.
- How much data can you afford to lose? If the backup runs once a night, you can lose a full day's work. If that is unacceptable, you need a higher frequency.
- How long can you be without the system? Two hours, a day, three days? The answer decides whether you simply need a copy, or a standby server ready to switch on.
Without these two numbers, any solution is either needlessly expensive or insufficient at exactly the wrong moment.
Testing: the part that always gets skipped
Monitoring tells you whether a backup ran. It does not tell you whether it restores. These are two different things, and only the second one matters.
What to test
- Restoring a single file — the quickest and most frequent test.
- Restoring a database and opening it from the program that uses it.
- Restoring a full server into a test environment, to measure how long it really takes.
- Restoring email, if you use Microsoft 365 or Google Workspace.
How often
A small test every month and a full test twice a year is a reasonable rhythm for most small businesses. What matters is not the perfect frequency, but that the test happens and the result is written down somewhere.
- Which systems are covered, and which are not?
- Where are the copies stored, and is there one outside the office?
- Can the copies be deleted by someone with network access?
- When was a restore last tested, and how long did it take?
- Who is notified if a backup fails?
- Is there a written recovery procedure, and where is it kept?
The four mistakes we see most often
- Backups on the same server. When the server fails, the copy fails with it.
- Nobody reads the alerts. Backups have been failing for months and the error emails go to an address nobody opens.
- Only one person knows the procedure. If they are on holiday the day of the incident, the business waits.
- New systems get forgotten. A server or an application is added and nobody includes it in the plan.
In conclusion
A backup is not measured by the fact that it exists, but by the time it takes you to get back to work. If you don't know that time today, that is the first question to settle — and it is settled with a test, not with a promise.
Would you like to check where you stand?
In the free initial consultation we look at what is covered today, where the copies are kept and how long a restore would take.
Request a free consultation