Quick answer: A website disaster recovery plan is a short, written document that explains how you will get your site back online after a serious failure: a server crash, a hack, a bad update, an expired domain or a host going out of business. It sets how long you can afford to be down and how much data you can afford to lose, lists where backups live and who has access to what, and gives step by step recovery instructions for the most likely scenarios. The plan only counts if you test it by actually restoring the site.
Why you need a plan, not just backups
Most businesses have some kind of backup. Far fewer know how long a restore takes, who can do it, where the latest copy really is, or whether it works. In the middle of an outage, with customers calling, that uncertainty costs hours.
A plan turns panic into a checklist. It also exposes gaps while there is still time to fix them, like backups stored on the same server as the site, or a domain registered to a former employee’s personal email.
Step 1: set your recovery targets
Two numbers shape everything else.
Recovery time objective (RTO): how long the site can be down before it seriously hurts the business. A brochure site might tolerate a day. An online store or booking system might need to be back within an hour or two.
Recovery point objective (RPO): how much data you can afford to lose, measured in time. If your site takes orders all day, losing 24 hours of orders is a big problem, so you need more frequent database backups. If content changes once a month, a weekly backup may be fine.
Write both numbers down and get agreement from whoever owns the budget. Tighter targets cost more.
Step 2: list what you need to recover
A website is more than files. Make an inventory:
- Code: theme, templates, custom plugins or modules, application code
- Database: content, users, orders, settings
- Uploads: images, PDFs and other media
- Configuration: server settings, environment variables, cron jobs, SSL certificates
- Domain and DNS: registrar account, DNS records, email records (MX, SPF, DKIM)
- Third party services: payment gateway, email delivery, CDN, analytics, forms and integrations
Note where each item lives today and how it can be restored.
Step 3: back up properly
A simple rule many teams follow is three copies of your data, on two different types of storage, with at least one copy off-site.
Checklist:
- Automated backups of the database at a frequency that meets your RPO
- Automated backups of uploads and files
- Code stored in version control, separate from the server (see website version control)
- At least one backup copy stored with a different provider from your host
- Backups encrypted, and access limited to a few people
- Backup retention long enough to go back before a hack that was noticed late (several weeks, not just a few days)
- Alerts if a backup job fails
Your host’s backups are useful, but if the host account is compromised, suspended or the host goes down, those backups may go with it.
Step 4: document access
Recovery stalls when nobody can log in. Keep a secure, shared record (in a password manager, not a spreadsheet emailed around) of:
- Domain registrar login, with two factor authentication enabled
- DNS provider login, if different from the registrar
- Hosting control panel and server access (SSH keys or passwords)
- CMS administrator accounts
- Backup storage accounts
- CDN or firewall service
- Payment gateway and other critical services
- Contact details for your developer, host support and any agency
Make sure at least two trusted people can reach these. Our guide to domain security explains how to lock down the registrar side, which is often the weakest link.
Step 5: write runbooks for likely scenarios
A runbook is a short set of steps for a specific problem. Keep each one to a page.
Server or hosting failure
- Confirm the problem with the host’s status page and support.
- Decide, based on your RTO, whether to wait or move.
- If moving, set up a new server or hosting account.
- Deploy code from version control, restore the database and uploads.
- Update DNS to point to the new server (keep DNS TTLs low enough in advance to make this quick).
- Test key pages, forms and checkout before announcing you are back.
Hacked site
- Take the site offline or show a maintenance page if it is serving malware or spam.
- Change all passwords and keys: hosting, CMS users, database, API keys.
- Restore from a clean backup taken before the infection, or clean the site with professional help.
- Patch the hole that let the attacker in (outdated software, weak password, vulnerable plugin).
- Check for search engine and browser warnings. Our guide to the Google Safe Browsing warning covers requesting a review.
Bad update or deployment
- Roll back the code to the last working version.
- If the database changed, restore it from the backup taken just before the update.
- Find the cause on a staging site, not on production.
Domain or DNS problems
- Check whether the domain has expired, been transferred or had DNS changed.
- Renew or recover it through the registrar.
- Restore DNS records from your documented copy.
Keep a current export of all DNS records in your plan. Rebuilding email records from memory is painful.
Accidental deletion
- Identify exactly what was deleted and when.
- Restore only that content from backup, if your backup tool allows it, to avoid overwriting newer changes.
Step 6: plan communication
Decide in advance:
- Who declares an incident and coordinates the response
- How the team talks during an outage (phone, chat group)
- What customers see: a simple maintenance page with contact details
- How you update customers through email or social media
- Who handles payment, privacy or legal questions if data might be exposed
Step 7: reduce the chance of disaster
Recovery is the safety net. Prevention lowers how often you need it.
- Keep software, plugins and server packages updated
- Use strong passwords and two factor authentication
- Use a staging site for updates and testing
- Add a web application firewall or security service
- Monitor uptime and get alerts quickly
- Choose hosting with redundancy that matches your RTO (see cloud hosting for websites)
Step 8: test the plan
This step is skipped most often, and it matters most.
- Restore a full backup to a separate server at least twice a year
- Time how long it takes and compare with your RTO
- Check that the restored site works: logins, forms, checkout, integrations
- Note anything missing from the backups or the documentation
- Update the plan after every real incident and every test
A backup that has never been restored is a hope, not a plan.
FAQ
How often should I back up my website?
As often as your RPO requires. Many stores back up the database several times a day. Mostly static sites can back up daily or weekly.
Is my host’s backup enough?
It is a good start but should not be your only copy. Keep at least one backup with a separate provider.
How long should I keep backups?
Long enough to restore from before a problem that was not noticed right away. Several weeks of history is common.
Who should own the disaster recovery plan?
Someone in the business, with your developer or host supporting them. The plan should not depend on one outside person.
Be ready before you need it
A website disaster recovery plan does not have to be long. It has to be written down, kept up to date and tested. Set your targets, back up off-site, document access and practice a restore. If you would like help building a site that is easy to recover and maintain, see Turn visitors into customers.
