A Disaster Recovery Plan Is More Than a Backup
Having backups is important.
But a backup by itself is not a disaster recovery plan.
A disaster recovery plan explains how your business will restore technology and data after a serious disruption, including:
- hardware failure,
- ransomware,
- cyberattack,
- power outage,
- Internet outage,
- fire,
- flood,
- building loss,
- cloud-service disruption,
- accidental deletion,
- or another event that prevents normal operations.
The goal is not simply to recover files.
The goal is to restore the systems your business depends on in the correct order, within a timeframe the organization can tolerate.
That requires planning before the disruption happens.
Start by Identifying What the Business Cannot Operate Without
Not every system is equally important.
A good disaster recovery plan begins by identifying the technology that is critical to business operations.
That may include:
- servers,
- Microsoft 365,
- email,
- ERP systems,
- accounting software,
- CRM platforms,
- file storage,
- databases,
- cloud applications,
- Internet connectivity,
- firewalls,
- phone systems,
- production systems,
- remote-access services,
- and specialized line-of-business applications.
For each system, ask:
- What business process depends on it?
- Which employees need it?
- What other systems does it depend on?
- What happens if it is unavailable?
- How long can the business reasonably operate without it?
This creates the foundation for recovery priorities.
Perform a Business Impact Analysis
A business impact analysis helps determine what an outage actually means to the organization.
For each critical system or process, consider the effect of downtime on:
- revenue,
- customer service,
- production,
- payroll,
- shipping,
- receiving,
- accounting,
- regulatory obligations,
- employee productivity,
- vendor relationships,
- and customer commitments.
The impact of downtime usually changes over time.
An accounting system being unavailable for 15 minutes may be inconvenient.
Being unavailable for three days could prevent billing, payroll, or financial reporting.
A production system being offline for an hour may have a very different impact than an internal marketing tool being unavailable for the same period.
Recovery priorities should reflect business impact, not simply which server is easiest to restore.
Define Your Recovery Time Objective
One of the most important disaster recovery terms is Recovery Time Objective, or RTO.
RTO answers this question:
How long can this system be unavailable before the impact becomes unacceptable?
For one application, the answer might be:
- 30 minutes,
- 4 hours,
- 8 hours,
- 24 hours,
- or several days.
Different systems can have different RTOs.
A company may need email restored quickly but be able to tolerate a longer outage for an archive server.
The shorter the required RTO, the more planning and infrastructure may be required to meet it.
Define Your Recovery Point Objective
The second important term is Recovery Point Objective, or RPO.
RPO answers:
How much recent data can the business afford to lose?
If your RPO is 24 hours and the system fails late in the afternoon, you may lose an entire day's work.
If your RPO is one hour, backups or replication must occur frequently enough to support that objective.
For some systems, losing a few hours of data may be acceptable.
For others, even a few minutes of lost transactions could create significant problems.
RTO and RPO should be defined based on business requirements, not simply whatever the current backup software happens to provide.
Understand the Difference Between Backup, Disaster Recovery, and Business Continuity
These terms are related, but they are not interchangeable.
Backup protects copies of data.
Disaster recovery focuses on restoring IT systems and data after a disruption.
Business continuity addresses how the organization keeps operating during and after the disruption.
For example:
A backup may contain your accounting database.
A disaster recovery plan explains how that database will be restored.
A business continuity plan explains how accounting continues operating if the system cannot be restored immediately.
Our article on the Difference Between Business Continuity and Disaster Recovery explains this distinction in more detail.
Create an Inventory of Critical Technology
You cannot recover what you do not know exists.
Maintain an inventory of critical technology, including:
- physical servers,
- virtual servers,
- cloud servers,
- storage systems,
- network equipment,
- firewalls,
- switches,
- wireless infrastructure,
- Internet circuits,
- workstations,
- Microsoft 365,
- cloud applications,
- databases,
- line-of-business software,
- backup systems,
- security tools,
- phone systems,
- and key vendor services.
The inventory should also identify:
- where each system is located,
- who owns or manages it,
- what it depends on,
- and how it is backed up.
This documentation becomes extremely valuable during an emergency.
Map System Dependencies
One of the most common recovery mistakes is restoring a system without realizing it depends on something else.
For example:
An ERP application may depend on:
- a database server,
- Active Directory,
- DNS,
- a file server,
- a license server,
- Internet connectivity,
- and a third-party vendor service.
Restoring the ERP application first may accomplish nothing if those dependencies are still unavailable.
Document which systems depend on:
- identity services,
- networking,
- storage,
- Internet access,
- databases,
- cloud providers,
- authentication,
- and other infrastructure.
Recovery order should follow those dependencies.
Prioritize the Recovery Order
Once critical systems and dependencies are known, create a recovery sequence.
A simplified recovery order might look something like:
- Internet and network connectivity
- Firewall and core network infrastructure
- Identity and authentication
- Core servers and storage
- Critical databases
- ERP or line-of-business applications
- File services
- Email and collaboration
- Secondary applications
- Nonessential systems
Your environment may be very different.
The point is to decide the order before the outage.
During an emergency is the wrong time to debate which system should come back first.
Design a Backup Strategy Around Business Requirements
Backups should support the RTO and RPO requirements defined earlier.
That may require different backup schedules for different systems.
A modern backup strategy may include:
- local backup,
- cloud backup,
- offsite backup,
- immutable backup,
- snapshots,
- replication,
- SaaS backup,
- and long-term retention.
The right mix depends on:
- the importance of the system,
- recovery objectives,
- data volume,
- compliance requirements,
- available bandwidth,
- and cost.
There is no universal backup design that fits every business.
Keep Backup Copies Separate From Production Systems
A backup that can be destroyed by the same event affecting production is not enough protection.
For example, ransomware may attempt to encrypt:
- production servers,
- network storage,
- attached backup repositories,
- and administrative accounts.
That is why modern recovery planning often includes backup copies that are:
- offsite,
- logically isolated,
- immutable,
- offline,
- or otherwise protected from routine production access.
The specific technology varies.
The important principle is that a compromise of the production environment should not automatically compromise every recovery copy.
Don't Assume Cloud Services Eliminate Backup Requirements
Businesses increasingly depend on cloud platforms such as:
- Microsoft 365,
- SharePoint,
- OneDrive,
- SaaS applications,
- cloud databases,
- and hosted business systems.
Cloud hosting provides many availability advantages, but that does not automatically mean every type of data-loss event is covered.
You still need to understand:
- what the provider backs up,
- what administrators can restore,
- retention periods,
- deleted-item recovery,
- version history,
- ransomware recovery,
- and whether independent backup is appropriate.
The question should be:
If this data disappeared or was corrupted, how would we recover it?
Plan for Ransomware Recovery
Disaster recovery used to focus heavily on hardware failure, fire, and natural disasters.
Today, ransomware and other cyber incidents must be part of the plan.
A ransomware recovery plan should account for the possibility that:
- production servers are compromised,
- administrator credentials are compromised,
- backup systems are targeted,
- user accounts are affected,
- endpoints are infected,
- and the attacker may have been inside the environment for some time.
Recovery may require more than restoring files.
You may need to:
- isolate systems,
- reset credentials,
- rebuild servers,
- verify backups,
- investigate the source of compromise,
- remove persistence,
- restore clean systems,
- and monitor the environment after recovery.
Restoring infected systems too quickly can recreate the problem.
Protect the Credentials Needed for Recovery
Recovery often requires access to:
- administrator accounts,
- backup systems,
- firewall credentials,
- domain accounts,
- cloud portals,
- encryption keys,
- vendor portals,
- and emergency recovery codes.
If those credentials are available only inside the systems that are currently down, recovery becomes much harder.
Maintain secure emergency access to the credentials necessary to recover the environment.
That access should itself be protected.
The goal is not to create an insecure master-password document.
It is to ensure authorized responders can access critical recovery information even if normal systems are unavailable.
Document Vendor and Support Contacts
Many businesses depend on outside vendors during recovery.
Your disaster recovery documentation should include contact information for critical providers such as:
- IT support,
- Internet service providers,
- cloud providers,
- software vendors,
- phone providers,
- cybersecurity vendors,
- insurance contacts,
- hardware vendors,
- building management,
- and other key partners.
Include:
- account numbers where appropriate,
- support phone numbers,
- escalation contacts,
- contract information,
- and service identifiers.
Do not assume someone will be able to search an email inbox for this information during an outage.
Email may be one of the systems that is unavailable.
Assign Clear Disaster Recovery Roles
Someone needs to own the recovery process.
The plan should identify responsibilities for areas such as:
- incident coordination,
- technical recovery,
- management communication,
- employee communication,
- customer communication,
- vendor coordination,
- insurance notification,
- legal or compliance response,
- and operational decision-making.
Also identify backups for key roles.
The primary person may be:
- unavailable,
- traveling,
- affected by the incident,
- or unable to access communication systems.
A plan should not depend on one person being reachable.
Define Who Can Declare a Disaster
Not every outage requires full disaster recovery.
Your plan should explain who has the authority to declare a disaster and activate recovery procedures.
That person or group may consider factors such as:
- estimated outage duration,
- affected systems,
- employee impact,
- customer impact,
- production impact,
- safety,
- and whether normal repair procedures are sufficient.
This prevents confusion about when the organization should move from troubleshooting into formal recovery.
Plan for Communication When Normal Systems Are Down
If email, Teams, phones, or the office network are unavailable, how will everyone communicate?
Your plan may need alternate communication methods for:
- executives,
- IT,
- employees,
- vendors,
- customers,
- and emergency responders.
Examples could include:
- mobile phones,
- alternate email accounts used specifically for emergencies,
- emergency notification systems,
- predefined conference bridges,
- or another approved method.
The plan should not rely entirely on the systems that may be unavailable.
Maintain an Offline or Independently Accessible Copy of the Plan
A disaster recovery document stored only on the file server you are trying to recover is not very useful.
Keep a current copy of the plan somewhere authorized responders can access independently of the primary environment.
That could include:
- a secure cloud location,
- protected documentation platform,
- approved offline copy,
- or another controlled repository.
Access should be secure, but availability matters too.
Plan for Internet Failure
Many modern businesses depend heavily on Internet connectivity.
An Internet outage can affect:
- Microsoft 365,
- cloud applications,
- VoIP phones,
- remote users,
- credit-card processing,
- ERP systems,
- customer portals,
- and vendor connectivity.
Ask:
- How long can the business operate without Internet access?
- Is there a secondary Internet connection?
- Can critical traffic fail over automatically?
- Are both circuits dependent on the same physical path?
- Which applications stop functioning during an outage?
A second Internet connection may be worthwhile for businesses where connectivity is operationally critical.
Plan for Power Failure
Power interruptions can affect more than desktop computers.
They can take down:
- servers,
- network switches,
- firewalls,
- wireless access points,
- storage,
- phone systems,
- and Internet equipment.
UPS systems can provide temporary protection, but they are not permanent power sources.
The disaster recovery plan should account for:
- safe shutdown,
- generator availability,
- expected battery runtime,
- and what happens during extended outages.
Plan for Loss of the Building
One of the most useful disaster recovery exercises is to assume:
We cannot enter the building tomorrow. What happens next?
Could employees still:
- access email,
- communicate,
- reach business applications,
- retrieve critical files,
- support customers,
- process payroll,
- and continue essential operations?
This scenario tests much more than backups.
It exposes dependencies on:
- office infrastructure,
- physical servers,
- Internet circuits,
- phones,
- paper records,
- local applications,
- and equipment that employees may need.
Don't Forget Network Infrastructure
Servers are not the only technology that may need recovery.
If a firewall or core switch fails, users may be unable to reach:
- servers,
- the Internet,
- cloud applications,
- printers,
- production equipment,
- or other parts of the network.
Document important network configurations and ensure they can be restored.
That may include:
- firewall configurations,
- switch configurations,
- VLANs,
- VPN settings,
- wireless configurations,
- DNS settings,
- and ISP information.
Replacing hardware is much faster when you already know how it was configured.
Recovery Planning for Manufacturing Can Be More Complex
Manufacturing environments can have additional dependencies.
A production operation may rely on:
- ERP,
- scheduling systems,
- CNC connectivity,
- quality systems,
- barcode systems,
- shipping systems,
- PLC or HMI-related infrastructure,
- vendor-supported equipment,
- and segmented IT/OT networks.
Restoring office email while production remains offline may not meet the business's real recovery objective.
For manufacturers, recovery planning should consider both traditional IT and the technology that supports operations.
Define Manual Workarounds Where Possible
Some systems cannot be restored instantly.
Business continuity may require temporary manual procedures.
For example:
- Can orders be recorded manually?
- Can shipping continue?
- Can employees use an alternate communication method?
- Can customer requests be documented for later entry?
- Can production continue in a limited mode?
- Can payroll be processed through an alternate procedure?
These temporary processes do not replace disaster recovery.
They reduce business impact while technical recovery is underway.
Test Backups by Restoring Data
A successful backup job does not prove that recovery will work.
The only way to know whether data can be restored is to test restoration.
That may include:
- restoring individual files,
- restoring databases,
- recovering a virtual machine,
- starting recovered servers in an isolated environment,
- or performing a broader recovery exercise.
Testing should confirm:
- the backup exists,
- the data is usable,
- required credentials are available,
- recovery instructions are accurate,
- and the actual recovery time is consistent with expectations.
Run Tabletop Exercises
Not every disaster recovery test requires shutting down production systems.
A tabletop exercise walks key people through a hypothetical incident.
For example:
It is Monday at 8:00 a.m. Employees cannot access the ERP system. IT determines that several servers have been encrypted by ransomware. What happens next?
Ask:
- Who is contacted first?
- Who makes decisions?
- Are affected systems isolated?
- How do employees communicate?
- Which backups are used?
- Which system is restored first?
- When is insurance contacted?
- When are customers notified?
- What information is missing?
Tabletop exercises often reveal gaps without creating production risk.
Perform Technical Recovery Tests Too
Tabletop exercises test decision-making.
Technical tests verify that systems can actually be restored.
Depending on the environment, testing may include:
- file restores,
- database restores,
- server recovery,
- cloud recovery,
- alternate-site recovery,
- firewall replacement,
- or complete system restoration.
The frequency and depth of testing should reflect:
- business criticality,
- system changes,
- risk,
- and recovery requirements.
A critical system with a four-hour RTO deserves more rigorous testing than an archival system that can be unavailable for several days.
Measure the Actual Recovery Time
If your documented RTO is four hours but a test takes twelve hours, the plan does not currently meet the business requirement.
That does not necessarily mean the backup solution is bad.
It means the recovery expectation and recovery capability are not aligned.
You then have two choices:
- improve the recovery capability,
- or revise the business expectation.
Either way, you now have useful information.
Update the Plan When Technology Changes
Disaster recovery plans become outdated quickly if they are ignored.
Review the plan when significant changes occur, such as:
- replacing a server,
- migrating to the cloud,
- changing backup platforms,
- replacing a firewall,
- adopting a new ERP,
- opening another location,
- changing Internet providers,
- adding remote employees,
- or changing key vendors.
Also review it periodically even if no major changes have occurred.
Contact information, credentials, staffing, and application dependencies can change without anyone updating the plan.
Keep the Plan Practical
A disaster recovery plan does not need to be a 200-page document nobody reads.
It needs to be usable during an incident.
A practical plan should make it easy to answer questions such as:
- What happened?
- Who is in charge?
- Who needs to be contacted?
- What systems are critical?
- What gets restored first?
- Where are the backups?
- How do we access them?
- What are our RTOs and RPOs?
- Which vendors do we call?
- How do employees communicate?
- How do we verify recovery?
The document should help people act.
Common Disaster Recovery Planning Mistakes
Several problems appear repeatedly in disaster recovery planning.
Mistake 1: Assuming Backups Equal Recovery
Backups are only one part of the process.
Mistake 2: Never Testing Restores
An untested backup creates uncertainty.
Mistake 3: Keeping Every Backup Connected to Production
A cyberattack may affect both production and backup systems.
Mistake 4: Ignoring Cloud Data
Cloud services still require recovery planning.
Mistake 5: Having No Recovery Priorities
Restoring systems in the wrong order can waste valuable time.
Mistake 6: Depending on One Employee
Critical knowledge should not exist only in one person's head.
Mistake 7: Storing the Recovery Plan on the Failed Network
The plan must remain accessible during the outage.
Mistake 8: Setting Recovery Goals Without Testing Them
RTO and RPO should reflect what the environment can actually achieve.
Build the Plan Before You Need It
A disaster is the worst time to discover:
- nobody knows the administrator credentials,
- backups have never been tested,
- a critical application depends on an undocumented server,
- the Internet circuit has no redundancy,
- the recovery contact left the company,
- or the disaster recovery instructions are stored on the server that just failed.
That is why disaster recovery planning belongs in normal technology management.
Our article Why Your Business Can't Afford to Build an Emergency Plan During a Crisis covers why response plans should be created and tested before an incident occurs.
Review Disaster Recovery as Part of Ongoing IT Planning
Disaster recovery is not a one-time project.
It should evolve with the business.
As systems change, recovery plans should change with them.
As the business becomes more dependent on technology, acceptable downtime may also decrease.
Regular IT planning should include questions such as:
- Which systems are now critical?
- Have our RTO or RPO requirements changed?
- Are backups still appropriate?
- Have restores been tested?
- Are recovery procedures current?
- Are vendor contacts current?
- Have new cloud systems been added?
- Has the network architecture changed?
- Are there new risks we need to address?
Businesses that want help managing infrastructure, backups, recovery planning, system documentation, and ongoing technology strategy can learn more about our Managed IT Services.
A Disaster Recovery Plan Should Answer One Question
At its core, disaster recovery planning comes down to this:
If an important system failed today, do we know exactly how we would restore it and how long recovery would take?
If the answer is uncertain, there is work to do.
A strong disaster recovery plan should define:
- what must be protected,
- how quickly it must be recovered,
- how much data loss is acceptable,
- where recovery data is stored,
- who is responsible,
- what gets restored first,
- how employees communicate,
- and how the organization knows the plan actually works.
Backups are essential.
But tested, documented recovery is what turns backups into business resilience.
