How Often Should a Small Business Test Its Backups? A Monthly and Quarterly Routine

Most backup products report a green tick when the job finishes. That tick tells you the software ran and wrote something to a destination. It does not tell you the files are readable, the database is consistent, the encryption key is to hand or that anyone remembers how to start a restore.

The failures that surface during a ransomware or hardware incident are usually dull ones: a folder excluded years ago and never added back, a retention period that has already deleted the clean copy, an expired credential on the storage account, or a restore that takes three days when the business can stand one. A scheduled restore test is the only routine that finds these before the incident does.

Once a month, restore a small sample from the backup into a separate location, never over the live data. Pick files that matter to the business, such as a recent customer contract, a spreadsheet from the finance share, a mailbox item and one file from each major system. Choose them at random rather than the same ones each time, otherwise you are only testing a few lucky files.

Open each restored file and confirm it is complete and readable, not just present. Note how long the restore took and which backup date you restored from. This check should take under an hour and can be done by a competent office manager. Its purpose is to prove the chain from backup copy to usable file still works and that the people responsible remember how to use it.

Every three months, restore one complete system or data set to a test environment: a whole file server share, a line-of-business database, or a laptop image. Rotate which system you test so that every critical system is covered at least once a year. Include the system the business could least afford to lose, such as accounting, case management or the customer database.

The aim is to measure two things. The first is whether the restored system starts and behaves correctly, including logins, linked services and recent data. The second is how long the whole process took from the decision to restore to the point staff could work. Compare that figure with the longest outage the business has agreed it can tolerate. If the test takes two days and the business can manage half a day, you have found a gap while it is still cheap to fix.

Follow the same written procedure each time so the test measures the process and not the individual's memory. Keep the procedure short enough that a deputy could follow it without help, and include where the recovery credentials and encryption keys are stored outside the systems being backed up.

The steps below suit a cloud backup console. Adjust the menu names to match your product, since the layout varies between vendors.

A failed or slow test is a useful result, provided it leads to a fix. Record the failure, raise an action with a named owner, and rerun the test once the cause is corrected. Typical causes include an excluded folder, a lapsed licence, a full storage quota, a changed password that broke the job, or a restore method nobody had practised.

Do not wait for the next scheduled date after a significant change. Retest after replacing a server, moving to a new cloud tenancy, changing backup provider, adding a major system or when the person who owned the backups leaves. Those are the moments when the backup scope and credentials most often drift away from reality.

A restore test only helps if at least one copy survives an attack. Keep one copy that is offline, immutable or otherwise out of reach of the accounts used day to day, because ransomware routinely searches for and encrypts or deletes connected backups. Confirm during the quarterly test that this protected copy is the one you can restore from.

Store the test records somewhere that does not depend on the systems being tested, and keep at least the last twelve months. Assessors and cyber insurers commonly ask whether backups are tested and when the last restore took place, and a dated record with a named sign-off answers that directly. It also gives the manager a clear trail if a recovery ever has to be explained to a client or regulator.