How to create a website disaster recovery plan?

You create a website disaster recovery plan by listing what could take your site down, deciding how quickly you need to be back online (your recovery time objective) and how much data you can afford to lose (your recovery point objective), putting backups and redundancy in place that meet those targets, and then writing clear step-by-step recovery instructions that anyone on your team could follow under pressure. The final, essential step is testing the plan regularly, because a recovery process that has never been rehearsed usually fails when you need it most.

Websites go down for all sorts of reasons: a hacked plugin, a failed update, an expired domain, a hosting outage, or a single mistaken click that deletes a database. Most small businesses only think about recovery in the middle of a crisis, which is the worst possible time. This guide walks you through creating a practical disaster recovery plan, from assessing risks to documenting procedures and running drills, in a way that works for a small business website as well as a larger online operation.

What Is a Website Disaster Recovery Plan?

A disaster recovery (DR) plan is a written document that explains how you'll restore your website and its data after a serious incident. It answers questions like:

• What can go wrong, and how bad would it be?
• Where are the backups, and how do we restore them?
• Who is responsible for what, and how do we contact them?
• How long should recovery take?
• How do we communicate with customers while the site is down?

A disaster recovery plan is related to, but narrower than, a business continuity plan. Business continuity covers how the whole business keeps running, while disaster recovery focuses on getting systems and data back.

Step 1: Identify What Could Go Wrong

Start by listing the realistic scenarios that could take your website down or corrupt its data. Common ones include:

1. Security incidents: Malware, defacement, ransomware, or an attacker deleting content.
2. Human error: Accidentally deleting pages, running a bad database query, or pushing broken code.
3. Failed updates: A plugin, theme, or core update that breaks the site or causes a fatal error.
4. Hosting failures: Server hardware failure, data centre outages, or a host going out of business.
5. Domain and DNS problems: An expired domain, a registrar account takeover, or DNS misconfiguration.
6. Account lockouts: Losing access to your hosting, registrar, or email account.
7. Third-party failures: A payment gateway, email service, or CDN outage.
8. Legal or billing problems: A suspended hosting account due to an unpaid invoice or a complaint.

For each scenario, estimate how likely it is and how much damage it would cause. You don't need a complex formula; "high, medium, low" is enough to decide where to focus.

Step 2: Set Your RTO and RPO

Two numbers shape the whole plan:

• Recovery Time Objective (RTO): The maximum acceptable time your site can be down. If your online shop takes most of your orders, maybe that's one to four hours. For a brochure site, a day might be fine.
• Recovery Point Objective (RPO): The maximum amount of data you can afford to lose, measured in time. If you take backups daily, you could lose up to 24 hours of orders, comments, or form entries.

Think about each part of your site separately:

System	Example RTO	Example RPO
Online shop and orders	2 hours	15 minutes to 1 hour
Blog content	24 hours	24 hours
Customer accounts	4 hours	1 hour
Marketing landing pages	24 hours	1 week

These targets determine how often you back up, whether you need real-time replication, and how much you should spend on redundancy. Tighter targets generally mean higher costs, so be realistic.

Step 3: Inventory Everything You'd Need to Rebuild

When disaster strikes, you need to know exactly what makes up your website. Document:

• Domain registrar: Which company, which account, and when the domain renews.
• DNS provider: Where records are hosted, plus an exported copy of your DNS zone.
• Hosting: Provider, plan, server details, PHP and database versions.
• Application: CMS version, theme, plugins and their licences, and any custom code repositories.
• Database: Name, size, and location.
• Third-party services: Email delivery, payments, CDN, analytics, forms, search, and anything else the site depends on.
• Credentials: Where each login is stored (ideally a password manager), including two-factor recovery codes.
• Licences: Premium plugin and theme licence keys and the accounts they belong to.

An exported DNS zone file is particularly valuable. If your DNS provider fails or your account is compromised, you'll want every record at hand. Many providers, including Cloudflare, let you export the zone in standard BIND format.

Step 4: Put the Right Backups in Place

Backups are the foundation of any recovery plan. We cover WordPress backups in detail in a separate guide, so here's the disaster recovery view.

Follow the 3-2-1 Rule

• 3 copies of your data: the live site plus two backups.
• 2 different storage types: For example, your host's backups and a cloud storage service.
• 1 copy off-site: Stored with a different provider from your hosting, so a single account or data centre failure can't take out everything.

Many teams now extend this to 3-2-1-1-0: one copy that's immutable or offline, and zero errors when you verify restores.

Match Backup Frequency to Your RPO

• Daily backups suit most blogs and brochure sites.
• Hourly or real-time backups suit busy shops and membership sites. Services like BlogVault, Jetpack VaultPress Backup, and some managed hosts offer incremental or real-time backups for WordPress.
• Database replication or point-in-time recovery suits high-traffic applications with strict RPOs, and is available on managed database services.

Back Up Beyond Files and Databases

Don't forget:

• DNS zone exports.
• Server configuration: Nginx or Apache configs, PHP settings, cron jobs, SSL setup.
• Code repositories: Your Git hosting is a backup of code, but not of uploads or data.
• Email: If your email is hosted with your website, it needs its own backup plan.

A Simple Automated Backup Script

If you manage your own server, a script like this creates a dated backup of a WordPress site and pushes it to off-site storage with rclone. Run it from cron as a user with read access to the site:

#!/usr/bin/env bash
set -euo pipefail

SITE_DIR="/var/www/example.com"
BACKUP_DIR="/var/backups/example.com"
REMOTE="offsite:example-backups"
STAMP="$(date +%Y-%m-%d_%H%M)"

mkdir -p "$BACKUP_DIR"

# Database export using WP-CLI
wp --path="$SITE_DIR" db export "$BACKUP_DIR/db-$STAMP.sql" --quiet
gzip "$BACKUP_DIR/db-$STAMP.sql"

# Files, excluding caches
tar -czf "$BACKUP_DIR/files-$STAMP.tar.gz" \
    --exclude="wp-content/cache" \
    -C "$SITE_DIR" .

# Copy off-site
rclone copy "$BACKUP_DIR" "$REMOTE" --include "*-$STAMP.*"

# Keep 14 days locally
find "$BACKUP_DIR" -type f -mtime +14 -delete

Configure the offsite remote with rclone config first, pointing to storage like Backblaze B2, Amazon S3, or Wasabi, and use credentials that can write but not delete where your provider supports it. Consider encrypting backups using rclone's crypt remote.

Step 5: Write Recovery Runbooks

A runbook is a step-by-step checklist for a specific scenario. It should be clear enough that someone other than you could follow it at 3am. Write one for each of your top scenarios.

Example Runbook: Restore After a Failed Update

1. Confirm the problem: Check the site from a different network and note any error messages.
2. Put up a maintenance notice if customers are affected.
3. Check for a quick fix: If a single plugin caused the problem, disable it via SFTP by renaming its folder in wp-content/plugins, or with WP-CLI.
4. If that fails, restore the latest backup from before the update, using your host's restore tool or backup plugin.
5. Verify: Test the home page, key pages, logins, forms, and checkout.
6. Record what happened and delay the update until the issue is understood.

With WP-CLI, the quick fix looks like this:

wp plugin deactivate problem-plugin --skip-plugins --skip-themes

Example Runbook: Full Rebuild on New Hosting

This is the scenario where your host is gone or completely compromised:

1. Provision new hosting with matching PHP and database versions.
2. Restore files from the most recent clean off-site backup.
3. Create a new database and user, then import the database backup.
4. Update configuration: Database credentials in wp-config.php, and new authentication keys and salts.
5. Install SSL certificates.
6. Test using a hosts file entry or temporary URL before switching DNS.
7. Update DNS to point to the new server. Lowering your DNS TTL in advance, such as to 300 seconds, makes switching faster.
8. Verify email, payments, forms, and integrations.
9. Rotate credentials if the old host was compromised.

The database portion might look like this:

mysql -u root -p -e "CREATE DATABASE example_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'example_wp'@'localhost' IDENTIFIED BY 'a-new-strong-password';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON example_wp.* TO 'example_wp'@'localhost';"
gunzip -c db-2026-09-25_0300.sql.gz | mysql -u root -p example_wp

Example Runbook: Security Incident

For a hacked site, the priority is containment before restoration. The steps usually involve taking the site offline or into maintenance mode, preserving evidence such as logs, identifying how the attacker got in, restoring from a backup taken before the compromise, patching the vulnerability, and rotating every credential. We have a separate, detailed guide on recovering a hacked WordPress site, which your runbook can link to.

Step 6: Define Roles and Contacts

In a real incident, confusion about who does what wastes time. Your plan should list:

• Incident lead: The person who makes decisions and coordinates.
• Technical responder: Whoever performs the restore. This might be you, a developer, or an agency.
• Communications: Who updates customers, social media, and staff.
• Backup contacts: Someone to step in if the primary person is unavailable.

Also include support contacts and account details for your host, registrar, DNS provider, payment gateway, and any agency you work with. Store the plan somewhere you can reach even if your website and email are down, such as a shared cloud document, a password manager note, and a printed copy.

Step 7: Plan Your Communications

Customers are much more forgiving when they know what's happening. Prepare:

1. A simple maintenance page you can put up quickly.
2. Template messages for email and social media explaining that the site is temporarily unavailable.
3. A status page for larger sites, using a service like Instatus, Better Stack, or Atlassian Statuspage.
4. Guidance on data breaches: If personal data may be affected, you may have legal obligations to notify authorities and customers within specific timeframes, depending on your region.

Step 8: Test the Plan Regularly

An untested backup is only a hope. Schedule regular tests:

• Monthly: Restore a backup to a staging site and check that it works.
• Quarterly: Walk through one runbook with the people named in it, as a tabletop exercise.
• Yearly: Run a full rebuild drill on fresh hosting and time how long it takes compared to your RTO.

After each test, update the plan with anything you learned, such as a missing licence key, an outdated password, or a step that took much longer than expected.

Step 9: Keep the Plan Up to Date

Websites change constantly. Review the plan whenever you:

• Change hosting, DNS, or registrar.
• Add or remove major plugins or integrations.
• Change who's responsible for the website.
• Have an incident or a near miss.

A quick review every six months keeps it relevant.

Prevention Reduces the Need for Recovery

A good recovery plan pairs well with measures that make disasters less likely:

• Keep software updated and test major updates on staging first.
• Use uptime monitoring so you find out about outages before customers do.
• Enable auto-renewal and registrar lock on your domain.
• Protect key accounts with two-factor authentication.
• Limit admin access to the people who really need it.

---

FAQ: Website Disaster Recovery Plans

---

Conclusion

A website disaster recovery plan turns a potential catastrophe into a checklist. By identifying your biggest risks, setting realistic recovery targets, keeping backups that match those targets, and writing clear runbooks, you give yourself a calm, repeatable way to get back online when something goes wrong.

The plan doesn't need to be long or complicated to be useful. What matters most is that your backups are off-site and restorable, your key information is documented somewhere reachable, and you've actually practised a restore. Set aside time to test it, update it after every change or incident, and you'll be ready for the day you hope never comes.