What Happens When Your Website Disappears? The Backup and Recovery Plan Most Businesses Do Not Have

By Cody Wise, founder of Wise Media, Calgary. Last updated 6 November 2026.

Summary

• Decide two numbers first: RPO, the data you can lose, and RTO, the time you can be down. Everything else follows from those.
• The Canadian Centre for Cyber Security recommends the 3-2-1 rule and says plainly that a backup should be stored offline.
• A backup on the same server as the site is a copy, not a backup. Ransomware and a host failure take both.
• Test the restore quarterly. An untested backup has roughly the reliability of no backup, and you find out on the worst day.
• If the breach involves personal information, Canadian law may require you to report it and to keep a record whether you report or not. Recovery is not the only obligation.

Table Of Contents

• The Two Numbers That Define Your Plan
• The 3-2-1 Rule, And Why Offline Matters
• Why Your Host’s Backup Is Not Enough
• What Actually Needs Backing Up
• Testing The Restore
• The Recovery Runbook
• The Legal Side Most Plans Ignore
• What This Costs
• Common Mistakes
• FAQ

The Two Numbers That Define Your Plan

Everything in disaster recovery collapses into two questions, and answering them honestly takes about ten minutes.

RPO, recovery point objective. How much work can you afford to lose? If your backup runs nightly at 2am and the site dies at 5pm, you lose fifteen hours. For a brochure site that changes monthly, fifteen hours is nothing. For a store taking orders, fifteen hours is a catastrophe.

RTO, recovery time objective. How long can you be offline before the damage is serious? Not how long before it is annoying. How long before you lose revenue you cannot recover, or a customer decides you are out of business.

Write your two numbers down and put them in front of whoever manages your hosting. Most hosting conversations are about disk space and price. This is the conversation that matters, and almost nobody has it.

The 50 Word Version

Set an RPO and an RTO, then build to them. Keep three copies of your site on two types of media with one offline and offsite, per the Cyber Centre’s 3-2-1 guidance. Restore a backup into staging every quarter. Write a one page runbook naming who does what. Test it.

The 3-2-1 Rule, And Why Offline Matters

The Canadian Centre for Cyber Security’s guidance on backing up your information (ITSAP.40.002) is short, free, and the clearest statement of the baseline available from a Canadian source. Its core instruction: “Adopt the 3-2-1 rule for data storage and have 3 copies of your information.” It adds, without hedging, “We recommend having a backup stored offline,” and “Storing backups of critical data in a separate, offsite facility can help your organization prevent data loss.”

Applied to a website, 3-2-1 means:

• Three copies. The live site, plus two backups.
• Two different media or platforms. Not two folders on the same server.
• One offline and offsite. Somewhere a compromise of your hosting account cannot reach.

The offline copy is the part people skip and it is the part that matters. The threat model has changed: modern ransomware looks for connected backups and encrypts them first, precisely because an attacker who leaves your backups intact has no leverage. A backup sitting in the same cloud account, authenticated with the same credentials, is reachable by anyone who gets those credentials.

The Cyber Centre’s baseline cyber security controls for small and medium organizations makes the same point in its backup control, calling for “storing backups offline at a secure offsite location” and stating that “Long term backups (e.g. weekly backups) must be stored offline.” Note the date on that document: version 1.2, last modified 18 February 2020. It is the Cyber Centre’s flagship small business guidance and it has not been revised in six years, which is worth knowing before anyone presents it to you as current best practice. The maintained short-form version is ITSAP.10.035, updated February 2024.

Immutable Storage, In Plain Terms

Most object storage now offers a setting that prevents a file being altered or deleted for a defined retention period, by anyone, including an account administrator. That is the practical modern equivalent of an offline copy, and it is usually a checkbox rather than a product. If your backup provider offers it, turn it on. If your provider does not offer it, that is a reason to look at another one.

Why Your Host’s Backup Is Not Enough

Host backups are real and useful. They are also the single most over-trusted control in small business hosting. Five specific limits:

• They are on the host’s infrastructure. If the account is suspended, the billing card fails, or the host has a platform incident, the backup is behind the same door as the site.
• Retention is often short. Seven to fourteen days is common on shared plans. A defacement or a subtle compromise is frequently discovered weeks later, by which point every retained backup contains the problem.
• Restore is often all or nothing. Many host restores roll the entire account back. If you need one table or one plugin directory, you may be restoring three weeks of other work backwards to get it.
• You usually cannot test it without consequences. If the only restore path is “overwrite production”, nobody tests it, which means nobody knows whether it works.
• The service agreement may disclaim it. Read yours. A meaningful number of hosting agreements describe backups as a courtesy and place responsibility for data squarely on the customer.

Use the host backup as your fast path for the common case, which is a bad plugin update at 10am. Keep an independent backup for the case that actually ends businesses.

What Actually Needs Backing Up

A WordPress site is two things that fail differently, plus a short list of things outside the site that people forget until they need them.

One thing to add to any backup policy: encrypt the backups. The Cyber Centre’s guidance says to “Encrypt sensitive data to protect it,” and a site database holds customer names, email addresses, and often more. A backup file is a copy of all of it sitting somewhere less protected than the live server.

Testing The Restore

The Cyber Centre’s backup guidance ends with the instruction almost everyone ignores: “Test your backups to make sure they work.” Here is what a real test looks like, quarterly, about an hour.

1. Pick a backup at random, not the newest one. You are testing the system, not today’s file.
2. Restore it into a clean staging environment, never over production.
3. Time it. From “we have decided to restore” to “the site is serving pages”. That number is your real RTO, and it is almost always longer than the one you assumed.
4. Log in to the admin. A surprising share of restores produce a site that renders but will not authenticate.
5. Click five key pages and submit a form. Confirm images load, not just that the page returns 200.
6. Check the newest content is present. If the most recent post is three weeks old, the backup is not capturing what you think.
7. Write down the date, the time taken, and anything that broke. Six lines in a document is enough.

The two failures this test catches most often are a backup that silently stopped running months ago, and a backup that includes files but not the database, or the reverse. Both are invisible until you need the thing.

The Recovery Runbook

The Cyber Centre’s baseline puts incident response first, ahead of every technical control, with the deliberately low bar that “Organizations should have a basic plan for how to respond to incidents of varying severity” and that it should be “a written incident response plan that details who is responsible for handling incidents.”

For a website, one page covers it. Keep it somewhere that does not depend on the thing that is down, which means not only on the company intranet and not only in an inbox hosted on the affected domain. Print it.

• Who decides. One named person who can authorise a restore, with one named backup. Not a committee.
• Credentials and where they live. Host, registrar, DNS, backup provider, CDN. Stored in a password manager two named people can reach.
• Contacts. Host support with the account number, your developer or agency with an after-hours route, and your domain registrar.
• Triage order. Is it down, defaced, or compromised? Those are three different responses and conflating them is how people restore a backup that already contains the attacker’s backdoor.
• The restore steps. Numbered, specific to your stack, written by someone who has actually done it.
• The holding page. A static page on a different host, ready to point at, so a long outage shows something other than an error.
• Who tells customers, and what they say. Drafted in advance, because nobody writes well during an incident.

The Compromise Case Is Different

If the site was hacked rather than broken, restoring the most recent backup usually reinstalls the compromise, because the attacker was probably in before you noticed. The sequence is: take the site offline, preserve a forensic copy, find the entry point, restore from a backup predating the intrusion, patch the entry point, then rotate every credential. We wrote the detailed version in our WordPress hacked site cleanup and hardening guide.

This is also the argument for longer retention. If your oldest backup is seven days old and the intrusion is three weeks old, you have no clean restore point at all.

The Legal Side Most Plans Ignore

Getting the site back is an operational problem. If personal information was involved, there is a second obligation running in parallel, and it has deadlines.

Under PIPEDA, section 10.1(1) requires an organization to report to the Privacy Commissioner “any breach of security safeguards involving personal information under its control if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual,” and to do so “as soon as feasible”. Section 10.3(1) is the one more people trip over: an organization “shall keep and maintain a record of every breach of security safeguards involving personal information under its control.” Every breach, not only the reportable ones. The Breach of Security Safeguards Regulations set the retention at 24 months from the day the organization determines the breach occurred.

Section 28 makes knowingly contravening the reporting or record-keeping requirements an offence, with a fine not exceeding $10,000 CAD on summary conviction and not exceeding $100,000 CAD on indictment. Worth noting for accuracy: the Privacy Commissioner does not levy those fines. The OPC can refer possible offences to the Attorney General of Canada, which is a different mechanism from the one most summaries imply.

PIPEDA is the law in force today. A replacement bill was introduced in June 2026 and is at second reading, which means it is not law and nothing in it applies yet. Alberta, British Columbia and Quebec have their own private sector privacy statutes, so which law governs you depends on where you operate. This is general information rather than legal advice, and a breach involving personal information is a moment to call a lawyer, not a blog post. Our guide to website data breach reporting in Canada goes through the mechanics.

The practical consequence for your runbook: add a line that says who assesses whether personal information was involved, and who makes the reporting call. Deciding that during an outage, with no owner named, is how deadlines get missed.

What This Costs

All figures CAD, based on published vendor pricing. Verify current rates directly, since plans change.

The honest summary: for most small Canadian businesses, a genuinely resilient setup costs under $300 CAD a year in tooling plus four hours a year of attention. The reason it does not get done is not cost. It is that nothing bad has happened yet.

If you would rather it be somebody’s job, that is what our website care and growth packages cover, and what a WordPress maintenance plan should include sets out what to demand from any provider, including us.

Common Mistakes

• Never testing the restore. The defining mistake. Everything else on this list is downstream of it.
• Backups on the same server as the site. One failure, one compromise, both gone.
• Seven day retention. Too short to survive a compromise you discover late.
• Backing up files but not the database, or the reverse. Common with misconfigured plugins and invisible until the restore.
• Restoring the newest backup after a hack. You reinstall the attacker along with the site.
• Keeping the runbook on the system that is down. Or in an inbox on the affected domain.
• No named decision maker. Three people waiting for each other is most of your RTO.
• Ignoring the privacy obligation. Getting the site up does not discharge a reporting or record-keeping duty.

FAQ

How Often Should I Back Up My WordPress Site?

Match it to your RPO. Daily is right for most brochure and lead-generation sites. Ecommerce and booking systems need the database captured far more often, because an hour of lost orders is real money. Back up before every plugin or core update regardless of schedule.

Is My Host’s Backup Enough?

Not on its own. It lives on the same infrastructure as the site, retention is usually short, and restores are often all or nothing. Use it as the fast path for routine problems and keep one independent copy somewhere your hosting credentials cannot reach.

What Is The 3-2-1 Backup Rule?

Three copies of your data, on two different media or platforms, with one offline and offsite. The Canadian Centre for Cyber Security recommends it directly in ITSAP.40.002 and adds that a backup should be stored offline.

How Long Should I Keep Backups?

Thirty days of daily backups plus several months of weekly ones is a reasonable baseline for a small business. The driver is not storage cost, which is trivial. It is that compromises are often discovered weeks after they happen, and short retention leaves you with no clean restore point.

What Should I Do First If My Website Goes Down?

Determine which of three situations you are in before you touch anything: down, defaced, or compromised. A hosting outage needs your host. A bad update needs a rollback. A compromise needs containment and a forensic copy before any restore, because restoring first destroys the evidence and usually reinstalls the problem.

Do I Need To Report A Website Breach In Canada?

Under PIPEDA you must report to the Privacy Commissioner if the breach involves personal information under your control and it is reasonable to believe it creates a real risk of significant harm. Separately, you must keep a record of every breach, reportable or not, for 24 months. Provincial statutes apply in Alberta, BC and Quebec. Get legal advice on a real incident.

Does A Managed WordPress Host Remove The Need For A Plan?

No. It improves your RTO considerably and it does nothing about the decision chain, the credentials, the customer communication, or the privacy obligation. A good host is one component of a plan, not a substitute for one.

Conclusion

Write down the two numbers. Get one backup somewhere your hosting login cannot reach. Restore it into staging once a quarter and time it. Put the runbook on one page with a named decision maker on it. That is the whole plan, it costs a few hundred dollars a year and four hours of attention, and it is the difference between a bad afternoon and an existential week.

If you are not sure whether your current backups would survive a real test, the fastest way to find out is to run one. Tell us what you are running through our intake form and we will tell you where the gap is before you need to know.