Testing a restore before you need it — why and how

Testing a restore before you need it

Every business we look after has a backup. Far fewer have ever seen one come back. That gap is worth closing, because the two are not the same thing.

An untested backup is a hope, not a plan

A backup job that reports success every night is reassuring, and most of the time it is telling the truth. But a green tick only confirms that the job ran. It does not confirm that the right things were included, that the data is readable, that anyone still has the password or key needed to unlock it, or that the restored files actually open in the software your business uses.

The failures we see are almost never dramatic. They are quiet and specific:

  • A new folder or a new server was added a year ago and never included in the backup.
  • The backup covers the file server but not the line-of-business database, because the database was locked open when the job ran.
  • Mail was moved to a new platform and the old backup kept running against something that no longer mattered.
  • The data is intact but nobody has tried to restore it, so nobody knows the restore takes considerably longer than the business assumed.

Every one of those is easy to fix in advance and painful to discover on the worst morning of your year.

What a test restore actually involves

Less than people expect. A test restore is deliberately undramatic:

  1. We agree what to test. Usually a representative sample rather than everything: a few documents from the shared drive, something from the accounting or job-management system, a mailbox item, and whatever else genuinely matters to your business.
  2. We restore it to a separate location — never over the top of your live data. Nothing you are working on is touched or replaced.
  3. We open the restored files to confirm they are readable and complete, not just present.
  4. Someone from your side checks one or two of them. This part matters. We can confirm a file opens. Only you can confirm it is the right file with the right content in it.
  5. We record what worked, what took how long, and anything that needs fixing, and send you that in writing.

How disruptive is it

For your staff, usually not at all. The work happens against backup storage and a separate location, so people keep using their computers normally. The main call on your time is the few minutes at the end when someone who knows the data confirms it looks right.

If we need to test something heavier — restoring a full server to prove it can be done — we will schedule that deliberately and tell you in advance what to expect. That is a bigger exercise, and we would only suggest it where the business genuinely depends on that server.

When to do one

Our suggestion is simple:

  • Once a year as a matter of course. Pick a quiet month and make it a standing item so it does not depend on anyone remembering.
  • Before anything big. A server replacement, a move to new premises, a change of accounting or job-management software, an office relocation, or bringing on a much larger client. Any of those is a good moment to know your safety net works.
  • After any significant change to what you store or where. New system, new share, new cloud service — confirm it is actually being backed up rather than assuming it was picked up automatically.
  • If a tender, an insurer or a client asks. Increasingly they do, and being able to point at a dated test result is a much better answer than describing your intentions.

What you get out of it

Three things. Confidence that the backup covers what you think it covers. A realistic sense of how long a recovery would take, so nobody is inventing a number during an actual outage. And a written record you can show to anyone who asks.

It also tends to surface useful business questions. Once people see how long a full recovery would take, the conversation about what would be needed first, and what could wait a day, happens calmly and in advance — which is the only sensible time to have it.

Talk to us

To arrange a test restore, or to ask what your current backup actually covers, email support@yougrowit.com.au or log a ticket at portal.yougrowit.com.au. For scope and pricing of a larger recovery test, email admin@yougrowit.com.au and we will quote it in writing.

Support hours are Monday to Friday, 8:30am to 5:30pm Melbourne time, excluding Victorian public holidays.

    • Related Articles

    • What we back up, how often, and how a restore works

      Most people only think about backups on the day they need one. This article explains, in plain terms, what a backup actually is, what it is not, and what you can reasonably expect when you ask us to get something back. A sync is not a backup This is ...
    • Storage is nearly full: what to do and what not to delete

      A warning appears saying the shared drive or the NAS is nearly full, or people start getting errors when they try to save. This is one of the most common tickets we see, and it is not a sign anyone has done anything wrong. Business data grows, and ...
    • Connecting to your Synology NAS from outside the office

      Your NAS is the storage box in the office that holds your shared files. Most of the time it only answers to computers sitting on the office network, which is exactly what you want. QuickConnect is Synology's way of letting you reach those same files ...
    • A drive or a server has failed: what happens now

      A drive has failed, or a server will not start. This is one of the few genuinely bad days in small business IT, and it is worth knowing in advance how it is handled, because knowing the shape of it makes the day much less frightening. First, the calm ...
    • A mapped network drive keeps disconnecting

      You click the shared drive, the one that might be S: or Z: or P:, and Windows tells you the network path cannot be found. Or the drive shows a small red cross beside it and nothing opens. This happens with every brand of storage, whether your files ...