Backups That Restore: Test Before You Need Them

The question we actually get

"Our backup software reports success every night, so we are safe, right?" We hear this in Vientiane offices and at provincial sites almost every month. The honest answer: a green tick on the job report only means files were copied somewhere. It says nothing about whether those files can come back as a working system. The only proof is a restore you have watched with your own eyes. This guide shows how to get that proof without disturbing daily work, and how often to repeat each kind of test.

Why backups fail at restore time

A backup can fail you in at least five ways, and we see all of them on real sites.

First, jobs that "succeeded" with warnings. A job can copy 98 percent of files, skip two open database files, and still report success. Months later you discover the missing pieces are exactly the ones you need. Warnings deserve a look every morning, not once a quarter.

Second, the backup gets destroyed along with the original. A NAS sitting next to the server drowns in the same flood, burns in the same fire, and gets encrypted by the same ransomware spreading across the network. A USB drive that was never rotated holds one old copy if it holds anything. Cloud file sync is not a backup either: when ransomware renames your files, the sync tool uploads the renamed versions within minutes. For the difference between sync and backup, see our 3-2-1 backup rule.

Third, database consistency. Copying the files of a running accounting or stock database often produces a set that will not start when restored. Databases need their own backup method, such as a built-in dump or an agent that talks to the database engine, followed by a test login.

Fourth, missing passwords and keys. Encrypted backups nobody can open are common: the admin who set the passphrase left two years ago, and it lives nowhere else. Store backup credentials in two places, one of them offline and sealed.

Fifth, restore speed. A full restore of 2 TB over a 100 Mbps link takes roughly two days of pure transfer time, before you fix anything. If the business cannot wait that long, the plan is wrong no matter how good the copies are. For most offices under 50 people we recommend keeping one full copy on a local device for fast restores plus one copy off site, because the local copy turns a two-day wait into a two-hour job.

RPO and RTO in plain words

Two short terms decide your whole backup design, so let us define them with an example.

RPO, recovery point objective, answers: how much work can we afford to lose? An RPO of one day means last night's backup is enough, and redoing today's entries by hand is acceptable. An RPO of one hour means you need copies every hour, because losing a morning of invoices at a busy shop is painful. Shorter RPO means more frequent backup runs and more storage.

RTO, recovery time objective, answers: how long can we sit idle? An RTO of four hours means the system must be running again, with data loaded and staff logged in, within four hours of the failure. RTO includes everything: finding the fault, fetching the copy, transferring data, starting services, and testing logins. For most small offices we suggest an RTO of half a working day for the main system, because promising one hour sounds brave but requires spare hardware standing ready, which few small firms will pay to keep idle.

Write both numbers down, one line each, and get the owner to agree. Every test in this guide then has a clear pass mark: did we lose less than the RPO, and were we back before the RTO?

The five test types and how often to run them

Not every test needs the same effort. Run cheap tests often and expensive tests once or twice a year. The table below is our standard rhythm for a small to mid-size site.

A few notes on each. For the single-file restore, never restore over the original; use a temp folder so a bad copy cannot hurt live data. For the VM restore, the isolated network matters: a restored domain controller or mail server that touches the live network can cause real damage in seconds. Disconnect first, check twice. For the database test, opening the file is not enough; log in through the application and check a record from the last week, because a database can open yet still miss recent transactions. For the bare-metal test, keep one spare machine or at least a tested boot USB stick ready; the rainy season in Laos brings lightning that kills power supplies, and that is exactly when you will need this. The full drill should run against your written incident response plan, with one person timing each step.

How to measure a restore properly

A restore test without timing is just theatre. Record three numbers every time: when the restore started, when the data finished copying, and when a normal user could log in and work. The gap between the second and third number surprises most teams; installing drivers, rejoining machines, and resetting passwords often take longer than the copy itself.

Do a little arithmetic before the test so you know what to expect. A 500 GB restore over a real-world 1 Gbps office link, which moves about 100 MB per second after overhead, takes around 90 minutes. The same 500 GB over a 50 Mbps internet link takes about a full day. Over an old USB 2.0 drive at 25 MB per second it takes close to six hours. Check these numbers twice against your own link speed before promising the owner a time. If the measured time misses the RTO, fix the design: add a local copy, split priority systems out for faster restore, or keep a standby machine.

Also note who did the restore. If only one engineer knows the steps, the plan fails the day that person is on leave or stuck on a flooded road in the provinces. Rotate the tester at least once a year.

The immutable copy and the restore log

One copy must survive even a full ransomware attack. That means a backup the malware cannot rewrite: an offline drive that is unplugged after each run, or cloud and NAS storage with immutability or object lock switched on so versions cannot be changed for a set number of days. Test this copy too, at least twice a year, by restoring from it specifically. An untested offline drive is just a hope; tapes and old USB drives fail silently. Pair this habit with the checks in our ransomware protection checklist.

Write every test down in a simple log. One row per test with these columns: date, test type, who ran it, which backup set and date was used, start and finish times, whether the RPO and RTO passed, problems found, and fixes with a due date. Keep one page per year where anyone can find it. The log is also where patterns show up: three slow restores in a row mean the design needs money, not another test.

Sign-off is short but real. The person who ran the test signs that the steps above were actually performed, and the owner or department head signs that they accept the result, including any failed RTO. A failed test with a signed fix date is worth more than a claimed success nobody signed. Review the open fixes every quarter until each one is closed and retested.

Quick checklist before you call any system protected:

• Three copies exist, on two kinds of media, with one copy off site or offline.
• Backup jobs show zero warnings for the last seven days.
• Database backups use the database's own tool, and the last test login worked.
• Backup passwords are stored in two places, one offline and sealed.
• The last restore test of each type passed inside the agreed RPO and RTO.
• The test log is up to date and the owner has signed the latest row.

Your next step: test one restore this month

Do not start by buying anything. Pick the single-file restore from the table, run it this week, and write the result in the log. That one small test finds most of the common faults: missing files, forgotten passwords, and copies that were never really there. Then schedule the quarterly VM restore on the calendar before the month ends.

If you want a second pair of eyes on the result, send us a photo of your latest backup job report showing the warnings section, plus the model name on your NAS or backup drive, on WhatsApp, and we will tell you which test to run first and what to watch for.