Backup and Recovery Plan: What Your Business Actually Needs

A backup and recovery plan is a written record of how your business copies its important data and how it gets that data and its systems working again after something goes wrong. It names what is protected, where the copies live, how often they are made and how long they are kept, how quickly each system needs to be back, who owns the plan, and how recovery is tested. For a small business the summary can fit on one page, with links to any detailed recovery steps.

 

It is easy to leave a backup and recovery plan until the worst possible day. A file vanishes, a laptop is stolen, or an email arrives saying your systems are locked, and the only question that matters becomes: do we have a copy, and can we get it back?

Answering that before the emergency is the entire point of a backup and recovery plan. Much of the writing on the subject is aimed at IT professionals. This page is not. It is the plain-language starting point for an owner or manager who wants to know what they need, which decisions they can make themselves, and which ones need technical help.

What is a backup and recovery plan?

A backup and recovery plan is two ideas joined together and written down. Backup is making copies of your important data so you still have it if the original is lost. Recovery is getting that data and your systems working again afterwards. The backup and recovery plan records how both happen and who is responsible for making sure they do.

It does not have to be a thick technical document, and length is not a measure of quality. What matters is that it exists, that someone owns it, and that the recovery it describes has been tested before you need it.

The New Zealand government makes the ownership point plainly. The NCSC’s guidance for businesses states that as the owner you are responsible for managing your data, including making sure it is backed up, and that regardless of who actually runs the backups you need to understand what is being backed up, how often, how long copies are kept, and where the offline copies are stored. Those four questions are a fair test of whether you have a backup and recovery plan or just a service.

How does it fit with disaster recovery and business continuity?

Backup, recovery and business continuity answer related questions, and they are best worked on together rather than one after another. Knowing how quickly the business needs a system back is what tells you which backup and recovery arrangements it needs, so the recovery requirement shapes the backup design from the start.

Topic What it covers
Backup arrangements What is copied, where the copies are stored, how often they run and how long they are kept.
Backup and recovery plan How those copies support recovery: who acts, the recovery targets, and how the approach is checked.
Disaster recovery plan Detailed recovery of IT services, including dependencies, access, infrastructure and supplier actions.
Business continuity plan How the business keeps essential work going while systems or other resources are unavailable, including manual workarounds that do not depend on a restore.

 

You can keep your backup and recovery plan and the related plans in one document or in several linked ones, depending on the size and complexity of the business. A concise plan can point to detailed recovery instructions held elsewhere, but those instructions still need to exist where the environment calls for them. Our guide to business continuity and disaster recovery covers how the two fit together.

What should your backup and recovery plan include?

Start your backup and recovery plan with one entry for each important system or group of data. Record what the business needs, check what the current setup can deliver, and name the person responsible for closing any gap.

What to record Questions to answer
What you are protecting Which files, mailboxes, databases, settings and cloud services are included, and what is deliberately left out?
Where the copies live Where are copies stored, and how are they protected from the same failure, or from someone who has compromised access to the originals?
How often, and how far back How often are usable recovery points created, how much recent work could you afford to lose, and how far back can you restore?
Who is responsible Who owns the priorities, who deputises when they are away, and who monitors failures, authorises a restore and carries it out?
How you get it back How quickly must each system be usable again, where are the steps, supplier contacts and secure access instructions, and when was recovery last tested?

 

Keep passwords and encryption keys out of a widely shared backup and recovery plan. Reference an approved way of reaching them instead, including how the people responsible get in if the normal sign-in system is down.

What are recovery targets?

Set two targets for each important system. The recovery time objective, or RTO, is the target time to restore the agreed service after a disruption. The recovery point objective, or RPO, is the most recent work you could afford to lose, measured in time. They are requirements to design and test against, not promises a backup product meets on its own.

As an illustration rather than a suggested target, a business might need its job system usable within four hours and be able to recreate no more than one hour of entries. Meeting that means recovering the access and supporting systems the application depends on as well, not only its data.

How often backups run follows from the RPO and from how often the data changes. The NCSC’s guidance gives both ends: a business taking in customer data through the day that would be impossible to recreate should back up a few times a day, while a website that is rarely updated can be backed up weekly or monthly.

On where the copies live, our data backup strategy guide sets out the 3-2-1-1 rule in full: three copies, two media types, one offsite and one offline or air-gapped. The offline copy matters because it cannot be reached through the same network or administrator account as the originals, but it works alongside retention, physical separation, access controls, encryption and a tested restore rather than replacing them. The useful question is how your copies would stay usable if the main environment, or the account that manages it, were compromised.

 

The five things a backup and recovery plan records, from what you protect through to how you get it back

Who should own the plan?

Name a business owner for the backup and recovery plan who approves the recovery priorities, and a deputy who can act when they are away. The owner does not need to be technical. The accountability for the data sits with the business even when a provider runs the backups, because the business decides what matters most and what risk it will accept.

Then record who does the technical work: who maintains the backup setup, investigates failures, approves a restore and checks that the recovered service works. If a provider handles those tasks, write the responsibilities and support arrangements into the backup and recovery plan so nobody is guessing during an incident.

Review the plan on a schedule that suits how important the systems are and how often they change. Once a year is a reasonable starting point, and the affected parts need updating after a new system, a new site, a change of supplier, or a staff member leaving with knowledge only they held.

There is a compliance reason to name an owner for the backup and recovery plan as well. Under the Privacy Act 2020 you must take reasonable steps to protect the personal information you hold, and a privacy breach that has caused or is likely to cause serious harm must be notified to the Office of the Privacy Commissioner and, unless an exception applies, to the people affected. The Commissioner asks to be told within 72 hours of the business becoming aware of a notifiable breach. Not every failed restore is a notifiable breach, but losing access to personal information you are responsible for can be one.

What changes if it is a cyber attack?

Recovering an accidentally deleted file and recovering after a suspected compromise are different jobs, and a backup and recovery plan should cover both. If an attack is suspected, follow your incident response plan before restoring anything. The technical team needs to contain the incident, choose a recovery point from before the compromise, and check the recovery environment before reconnecting it. Restoring data does not undo information that has already been taken, and it does not fix an account that is still compromised.

Where should a small business start if it has nothing in place?

Start a backup and recovery plan by listing what you cannot lose, then find out what is already covered, then close the gap and write it down. The first step is one an owner can begin today. Confirming coverage and putting protection in place may need your provider’s help, and closing a gap can involve both budget and technical work.

List what you cannot lose. Before any technology, write down the data and systems the business could not operate without, and roughly how long it could manage without each one. This list is the foundation of the whole backup and recovery plan.

Find out what you already have. You may already have something running without being clear on what it covers. If you are on Microsoft 365, start with our guide to what Microsoft 365 keeps, because its recovery windows are the gap we find most often.

Close the gap and write it down. Put protection in place for anything important that is not covered, name the owner and deputy, and fill in the five rows of your backup and recovery plan above in plain language. A simple document everyone understands beats a sophisticated one nobody opens.

Prove it. Start with a small restore, then test the recovery that matters to the business. Can someone authorised open the application, reach the right information and complete a normal task? Check how old the recovered data is and how long the whole thing took, including access, dependencies and checking the result. A successful backup job tells you a process ran, and only a recovery test tells you the result is usable. The NCSC’s guidance draws the same line between restoring an entire system and restoring a single database to test part of the backup. Repeat the tests on a schedule that reflects how important each system is, and again after significant changes.

Frequently Asked Questions

What is a backup and recovery plan?

A written record of how your business copies its important data and how it restores that data and its systems afterwards. Backup is the copies, recovery is getting back up and running, and the plan records how both happen, how quickly each system needs to be back and who is responsible. For a small business one page can be a useful overview, provided it points to any detailed recovery steps and the recovery has been tested.

What is the difference between a backup and recovery plan and a disaster recovery plan?

A backup and recovery plan covers how your data is copied and how those copies support recovery: what is protected, how often, how far back, who acts and how it is tested. A disaster recovery plan covers the detailed restoration of IT services, including dependencies, access, infrastructure, supplier actions and the order systems come back in. The two are best worked on together, because knowing how quickly a system must return shapes what backup it needs.

Do small businesses really need a backup and recovery plan?

Yes. A smaller business has less cushion to absorb a long disruption, and is less likely to have someone watching the backups every day. Data loss through ransomware, accidental deletion, hardware failure or a stolen laptop affects businesses of every size. A short plan that has been tested gives the owner a clear answer to the question that matters on the day: can we get it back, and how quickly.

Is my data already backed up by Microsoft 365 or Google?

Not in the way many people assume. Both platforms include retention and recovery features that depend on the service, the licence and the settings: in Microsoft 365, deleted email is recoverable for 14 days by default and up to 30 if an administrator extends it, and deleted SharePoint and OneDrive files are kept for 93 days from deletion, a period that cannot be changed. Retention policies can hold content longer where they have been set up, but none of this is the same as an independent backup you control. It is the single most common gap we find, and Exodesk offers Microsoft 365 backup for businesses that need the extra protection.

How often should backups run?

Set the schedule around how much recent work the business can afford to lose and how often the data changes. The NCSC guidance suggests a few backups a day for customer data coming in through the day that would be impossible to recreate, and weekly or monthly for something that rarely changes, such as a website that is seldom updated. Whatever the schedule, check that backups complete and that they meet the recovery point the business has agreed.

How do I know my backup actually works?

Restore data and check that it can be used. For an important application, also test the systems and access it depends on, then have someone complete a normal task in the recovered service. A single file restore checks the recovery path for that file, not the recovery of the whole business, so build up from small restores to the recoveries that matter.

Who should own the plan, us or our IT provider?

The business, through a named owner and a deputy. The owner approves the recovery priorities and does not need to be technical, while a provider can maintain the backups and run recovery under an agreement. The plan should record who investigates failures, who approves a restore and who checks the recovered service, so the responsibilities are clear before anything goes wrong.

What is the 3-2-1-1 rule?

Three copies of your data, on two different media types, with one kept offsite and one kept offline or air-gapped. The offline copy matters because backups that can be reached over the network can be deleted or encrypted by an attacker who gets in. It works alongside retention, access controls, encryption and a tested restore rather than replacing them, and our data backup strategy guide covers how to build it.

How long should a backup and recovery plan be?

A small business may be able to summarise the plan on one page, with links to any detailed recovery instructions. It needs enough information for the responsible people to act, including when the main systems are unavailable and without relying on somebody remembering how it works. Page count alone does not tell you whether the plan will work.

Does the Privacy Act require a backup and recovery plan?

The Act does not name a specific technology. It requires you to take reasonable steps to protect the personal information you hold, and to notify the Office of the Privacy Commissioner and, unless an exception applies, the people affected, of a privacy breach that has caused or is likely to cause serious harm, with the Commissioner asking to be told within 72 hours of the business becoming aware. Losing access to personal information can itself be a privacy breach, so being able to recover it is a practical part of meeting the duty rather than a stated requirement.

How often should the plan be reviewed?

Agree a review schedule based on how important the systems are and how often they change. Once a year is a reasonable starting point, with the affected parts updated after changes to systems, suppliers, key staff or recovery requirements. Review the plan after every test and every incident as well, because that is when the gaps show.

NEXT STEP

Not sure your backups cover what the business depends on?

Talk to Exodesk about your backup and recovery plan, or request an IT assessment for a wider picture of what you are running. We work with businesses across Christchurch, Dunedin and the rest of New Zealand.

Or read more about our managed IT services.

Start typing and press Enter to search

Business systems modernising in stages, from an ageing tower server through to cloudA staff member raising an IT helpdesk request and an engineer already responding to it Call Us Now