Disaster recovery is the planning and the systems used to restore data and keep an organisation working after an attack or a disaster, such as a fire, flood or theft.
Before an organisation chooses a cloud service, it should read the provider's disaster recovery policy. This policy should show how often data is backed up, where those backups are kept, and how quickly the service and the data can be restored after a failure. The organisation then has to judge whether those arrangements suit its own needs. A business that could cope with losing a day of orders has different needs from one that must be taking orders every minute, so the backup frequency and recovery times in the policy matter.
Cloud backups are normally kept in the provider's data centres, well away from the organisation's own buildings. If the organisation's premises are damaged, the backups are not destroyed with them. For example, Harbour Lane Bakery stores its customer orders in a cloud service. A burst pipe ruins the office and its computers, but the order records are still held in a data centre 200 miles away, so the bakery can carry on trading as soon as replacement equipment arrives. Cloud services therefore reduce the harm to an organisation's data when its own premises are hit by an attack or disaster.
The organisation still needs its own disaster recovery policy. That policy explains how staff keep working and how data is recovered if the cloud service becomes unavailable. Who backs up which data, and who restores it afterwards, should be agreed with the provider before the service is chosen, so that each side knows exactly what it must do when something goes wrong.
A disaster recovery policy should state who is responsible for each recovery action, so every task has a clear owner. This is more than saying “IT will deal with it”: the policy names the role that must carry out each action.
Responsibilities should be linked to job roles, such as systems administrator or network technician, rather than named individuals. The responsibility stays in the policy when someone leaves or changes job, and whoever takes over the role can see what they must do. If a policy names one person, it can quickly become out of date and leave a recovery action with no clear owner.
A small online shop selling board games could set out responsibilities like this:
| Job role | Recovery responsibility |
|---|---|
| Systems administrator | Restore the stock database and check that product records open correctly. |
| Network technician | Reconnect the card payment terminals and test one payment. |
| Operations manager | Check that each recovery task has been completed and record any gaps. |
Assigning each task to a specific role makes someone accountable. It also prevents the same action being duplicated by several staff or forgotten because everyone assumes another person is handling it. With vague responsibilities, staff may all try to restore the same database while nobody checks the payment system.
Staff instructions are the part of a disaster recovery policy that tells everyone what to do, and what not to do, as soon as a serious incident happens. Clear instructions stop people acting on guesswork and reduce the risk of making the situation worse.
The policy should give simple, specific steps, so nobody has to decide for themselves what to do. Staff should not switch off or restart equipment, because data may still be in memory, an automatic backup may be running, or the recovery team may need to see the equipment exactly as it is. Staff should contact the named job role, such as the network manager, so there is no doubt about who to get hold of.
Staff should then report to the stated meeting point and sign in, so the recovery team knows who is on site and who is safe. Other dos and don'ts should be listed too, for example 'do keep clear of the affected area' and 'do not attempt repairs yourself'.
All staff need to know the procedures, even cleaners, receptionists and teachers with no recovery tasks of their own. They may need to get out safely, stay out of the way of recovery work, or follow instructions from the recovery team. For example, if a power failure shuts down the main building, a receptionist still needs to know where to report and who to contact, even though they will not restore any systems.
Training and regular reminders, such as an induction session and a yearly briefing, help make sure everyone remembers what to do under pressure. People forget detail when they are panicking, so a short checklist kept with the emergency contacts supports this.
A backup is a copy of data stored separately from the original, so that the original can be restored if it is lost, corrupted or damaged. Recovery is the process of restoring that data from the backup.
Backups matter after a major system failure — a hard drive that stops working, a ransomware attack, a fire in the room where the server stood, or a folder someone deleted by mistake. Once the fault is fixed, the backup is copied back and people can carry on working.
Many systems back up automatically on a schedule, such as every evening at 11pm. Nobody has to remember to do it, and at worst the work done since the last backup is lost. A manual backup is started by a person at a chosen moment, often just before a software update or a hardware change. Changes like these can go wrong and leave a system unusable, so a fresh copy taken beforehand means you can put everything back as it was.
A backup should be kept securely and separately from the original data — on a different drive, in another building, or with a cloud service — and access to it should be limited to the people who need to restore it. A copy stored on the same disk as the original is no help at all: one failure destroys both. Backups should also be tested by carrying out a practice recovery, because a backup that turns out to be incomplete or corrupted is only discovered when you desperately need it.
scores = {"Amara": 12, "Ben": 9, "Cerys": 15}
backup = scores.copy() # a separate copy kept safe
scores.clear() # the original data is lost
print("Original now:", scores)
scores = backup.copy() # recovery: restore from the backup
print("Restored:", scores)Output:
Original now: {}
Restored: {'Amara': 12, 'Ben': 9, 'Cerys': 15}A backup does not prevent a threat from happening. Malware will still infect a machine that is backed up every night, and a thief can still steal a laptop. What the backup does is let you get the data back afterwards.
The disaster recovery policy defines the backup process in detail, so everyone knows exactly what happens and when. It should list the critical software applications, the critical data and the hardware needed to run them. Critical data is the information the organisation cannot function without, such as online shop orders or cinema ticket bookings, so it is backed up most often.
Different systems need different frequencies. A system that changes constantly and matters most should be backed up more often than one used only occasionally — a busy till system might be copied every 15 minutes, while archived records might be copied every three months. The policy must give these exact frequencies, not just say backups happen regularly, because staff need to know how much work could be lost. It should also give the schedule: the set time and day when each backup runs, such as 07:00 and 19:00 on weekdays or Saturday at 03:00, so backups do not clash with busy periods.
The policy should name the media or platform used, such as a dedicated backup server, and state where backups are stored, such as a secure data centre in another town, so a problem at the main site cannot destroy the copies too. It should also name the designated person or people responsible for backups, usually by job role such as the network manager, so the policy still works when staff change.
A recovery timeline is the part of a disaster recovery policy that states when each system and its data must be working again after a disaster. It turns recovery into a priority order, so staff know what to bring back first instead of treating every system as equally urgent.
The timeline gives each system a target time for being back up and running. It also records how long the organisation can manage without that system. These are not the same: a system can be important but still be missed for a day, while another stops work almost immediately. The target time should be shorter than the longest time the organisation could cope, so there is a margin for error.
Riverside Music Tuition lists its systems in order. Pupil records come first because tutors need contact and medical details before lessons can run safely. The public website comes last because nobody needs it to teach.
| System | Longest time without it | Target time back | Order |
|---|---|---|---|
| Pupil records | 4 hours | 1 hour | 1 |
| Card payment system | 2 working days | 1 working day | 2 |
| Staff rota | 3 working days | 2 working days | 3 |
| Public website | 7 days | 5 days | 4 |
Critical systems are the ones the organisation cannot manage without for long. They are recovered first. A timeline that marks everything as urgent is useless because it gives no real priority.
The timeline should also list the recovery actions in the order staff should carry them out, with a time or trigger for each. For Riverside, the first actions might be to check that pupil records are available, then bring back card payments, then rebuild the rota, and finally update the website. Setting out the actions like this means staff know what to do and when, rather than wasting time deciding what to do next while under pressure.
If the main site cannot be used, the organisation still needs to keep working. The disaster recovery policy should identify an alternative location where operations can continue.
That location needs the right resources, not just empty desks. Alternative hardware must be able to run critical systems, alternative software and licences must let staff do their jobs, and alternative personnel (people with the necessary skills) must be available. Copies of the backups must also be on hand so data can be restored. If any one of these is missing, the organisation cannot function again quickly.
Contingency plans for the alternative location should be made in advance. A key part is guaranteed access to the site: staff must be able to get in and start work without delay. For example, a group of music rehearsal studios names a partner studio across the city as its alternative location; the written agreement reserves two live rooms, and every member of staff's key fob already opens the partner building, with the fobs checked each year. Without this arrangement, staff could arrive and find themselves locked out.
Using standardised hardware - the same makes and models throughout the organisation - makes it easier to replicate or reimage equipment at the alternative location. One standard image can be rebuilt onto any machine, so it behaves like every other one. Staff recognise the system straight away and parts can be swapped between machines, which is much faster than setting up lots of different models from scratch.
Specific policy wording means every instruction in a disaster recovery policy names the exact role, action, time and place it applies to, so staff never have to work it out for themselves. A policy that covers the right topics but words them vaguely looks complete, yet it is unusable at the moment it is needed.
| What must be pinned down | Vague wording | Specific wording |
|---|---|---|
| Who | Someone senior will sort it out. | The duty manager decides whether to stop taking online bookings and tells the reception supervisor. |
| What | Staff should use their judgement. | Receptionists write down every phone booking on the paper pad at the desk. |
| When | Staff will be updated in due course. | The reception supervisor briefs every member of staff at 9:00am on the next working day. |
| Where | Work carries on somewhere suitable. | Phone bookings are written on the paper pad kept in the top drawer of the reception desk. |
| How quickly | Paper bookings will be caught up with when it quietens down. | Every paper booking is typed into the booking system within three hours of being taken. |
Vague wording causes two problems. Staff working under pressure take longer to decide what to do, and different people guess differently: one member of staff waits for instructions while another starts unplugging equipment, so recovery work is delayed or undone. Vague wording also cannot be checked, because nobody can say afterwards whether a paper booking was caught up with soon enough.
A specific instruction is a standard you can measure against, so the policy can be rehearsed, reviewed and improved, and any member of staff can be held accountable for their part of it. Words such as appropriate, promptly and suitable hide a decision that somebody has already had to make, so write that decision into the policy instead. A separate note covers the recovery timeline.