The Backup & Disaster Recovery Checklist

This is the checklist we work from when we review or build a backup. It is written so you can use it with any provider, including one that isn't us.

Almost every backup failure we are called to has the same shape: the backup was running, and nobody had ever restored from it. Green ticks every night for two years, and on the one morning it matters, the data is incomplete, the restore takes four days instead of four hours, or the encryption key is on the server that just died.

Backup is not a product you buy. It is a promise about how much work you are willing to lose and how long you can be down — and those two numbers should be decided by you, not by whatever the software defaults to.

• How much work can you afford to lose? An hour, a day, a week. This sets how often backups run. Nightly backups mean you can lose a full day
• How long can you be down? An hour, a day, a week. This sets how you recover, and it is usually the expensive number
• Both agreed with the people who run the business, not decided by IT alone
• Both written down, so there is no argument about expectations on the day
• Different systems can have different answers — the accounting system and the marketing folder do not need the same promise
• The cost of meeting them understood before anyone commits to a number

• Servers, and whether that is the whole machine or only the data on it
• Cloud mail and files. Microsoft and Google replicate your data; that is not a backup. If someone deletes a mailbox and nobody notices for 60 days, replication will faithfully replicate the deletion
• Line-of-business applications, and their databases specifically
• The accounting system, which is often the thing nobody can operate without
• Laptops and desktops — or a stated decision that they are not backed up and staff know it
• Network device configurations: firewall, switches, phone system, access points
• Anything on a NAS or a share that grew organically and never got listed
• A written inventory of what is in scope and out of scope, so nobody discovers the gap during a recovery

• More than one copy, and not all in the same building
• At least one copy offline or immutable, so that ransomware which reaches your network cannot encrypt the backups too
• Backup storage not reachable with everyday administrator credentials
• Separate credentials for the backup system, with MFA
• If backups go to a cloud account, that account is in your company's name
• Data residency understood if your bank, auditor or parent company cares where it sits
• Retention: how far back you can go, decided deliberately. Some problems are discovered months later
• What happens to the data if you stop paying the provider

This is the section that separates a real backup from a comfortable one.

• When was a restore last actually performed? Ask for the date. "It runs successfully every night" is not an answer to this question
• A single file restored, end to end, by someone other than the person who built it
• A full system or server restored at least once, and the time it took recorded
• A mailbox restored, including an individual message
• The restore tested from the offline copy, not just the convenient one
• Restore tested by someone who would plausibly be available at 2am, not only by the one expert
• Failures actually alerting to a person, and someone confirming those alerts still arrive
• A calendar entry for the next test, not an intention to do one

• Written down and stored somewhere reachable when the systems are down — not only inside the system that has failed
• Order of recovery decided: what comes back first, and what can wait a day
• Who declares an incident, and who has authority to spend money at 3am
• Contact list with real mobile numbers: staff, provider, carrier, landlord, insurer
• Encryption keys and recovery codes stored somewhere that survives the failure
• How the business operates manually for a day, if it has to
• How you will communicate with customers if email is down
• Who talks to staff, and what they are told
• Reporting obligations understood before the day, not looked up during it

UAE organisations should confirm any incident-reporting obligations with the UAE Cyber Security Council and their sector regulator. Requirements as of August 2026 and subject to change. Ontrac is an IT provider, not a legal or compliance adviser.

An hour, once a year, with the people who would actually be involved. It does not need to be a full failover to be worth doing.

• Pick a plausible scenario: the file server is encrypted on a Sunday night
• Walk through it out loud. Who is called, in what order
• Actually open the recovery document. If nobody can find it, that is the finding
• Actually restore something, even one folder
• Time it, and compare with the number you agreed in section 1
• Write down what did not work and fix those things
• Book the next one before everyone leaves the room

• The backup account and its credentials, in your company's name
• The written scope: what is backed up, what is not, how often, kept how long
• The two numbers from section 1, agreed and recorded
• The recovery plan, in a form you can read on a phone
• Evidence of the last successful restore test, with a date
• Encryption keys and where they are held
• The support arrangement, including who to call out of hours

The backup that only ran. Green every night, never restored, unusable on the day. The single most common finding.

Cloud mail assumed to be backed up. It is replicated, not backed up. Deletions replicate perfectly.

Backups on the same network with the same admin password. Ransomware finds them, and then there is nothing to come back to.

The encryption key on the dead server. The backups are intact and unreadable.

The database that was backed up as files. Copied while running, restores to nothing usable.

Recovery time nobody measured. Everyone assumed hours. It was four days, over a weekend, on a slow line.

The plan inside the system that failed. A recovery document on the file server you are trying to recover.

We design and run backup and recovery, and we test restores rather than reporting on jobs. If your existing backup is sound and only needs a restore test and a written plan, we will tell you that — it happens, and it is a much smaller piece of work than replacing everything.