Website backups for Canadian businesses: what actually works (and what does not)

Why "my host does backups" is not a backup strategy

When a hosting provider says they perform daily backups, what they typically mean is this: once per day, they take a snapshot of their servers and store it somewhere. If you need to restore, you contact support, wait for a human to process your request, and hope the snapshot you need exists and is intact. This is better than nothing. It is not a backup strategy.

The first problem is shared infrastructure risk. Most hosting-level backups are stored on infrastructure that shares a failure domain with your live site. If your host's data centre experiences a catastrophic failure — a hardware failure, a ransomware attack, a fire, a flood — both your live site and the backup may be affected. This is not a hypothetical: hosting providers have lost customer data in exactly this way, including backups they advertised as reliable.

The second problem is retention limits. Budget and shared hosting plans typically retain backups for seven to thirty days. If your site is compromised by malware that was injected thirty-five days ago and has been dormant since, every backup your host holds may include the infection. You have no clean copy to restore from.

The third problem is coverage gaps. Hosting backups capture the server state — files and, sometimes, databases — but they may not capture everything your site needs to function. Configuration files, custom server rules, email accounts, DNS records, SSL certificates, and third-party integrations are all things that live adjacent to your website and may not be included in a standard hosting backup. When you need to rebuild from scratch after a serious incident, you will discover quickly which of these things were not backed up.

The fourth problem is the restore process itself. Hosting-level restores are often slow, opaque, and dependent on support queue times. In a real emergency — your site is down, customers cannot reach you, you are losing revenue or credibility by the hour — waiting two business days for a support ticket to be resolved is not acceptable. If you have not set up your own backup system with self-serve restoration, you are dependent on someone else's timeline during the worst possible moment.

What a complete backup actually covers

A complete website backup has three components, and all three need to be captured together to allow a meaningful restore.

Files. This includes your website's theme files, plugin files, uploaded images and documents, configuration files (including wp-config.php for WordPress sites, or equivalent), and any custom code. For a WordPress site, this is typically the entire contents of the public_html directory. For a static HTML site, it is simpler — just the HTML, CSS, JavaScript, and asset files. For a custom PHP application, it includes all application files and any environment configuration that is stored on disk rather than in a database.

Database. For any dynamic website — WordPress, WooCommerce, a custom CMS, or any application that stores content or user data — the database is often more important than the files. Your theme can be reinstalled. Your plugins can be reinstalled. Your content — blog posts, product listings, customer records, orders, settings — lives in the database and cannot be reconstructed without a backup. A file backup without a matching database backup is half a backup at best.

Configuration outside the web root. This is the category most often omitted. Your server's .htaccess file (or Nginx configuration equivalent), your SSL certificate and its private key, your PHP settings, your email account configuration, your DNS records, your cron jobs — none of these are typically captured in a file backup of your website directory. Document them separately. For SSL certificates, note the issuer and renewal date so you can regenerate quickly. For DNS records, keep a plain text record of every entry in your zone file. For server configuration, ask your host what is and is not captured in their backup system.

The practical implication is that your backup process needs to be deliberate, not passive. You need to know what is being captured, verify that all three categories are covered, and confirm that the backup files are complete and uncorrupted — not just that the backup ran.

Frequency and retention: how much history you actually need

Backup frequency should be proportionate to how often your site changes. A brochure website that is updated monthly does not need hourly backups; a WooCommerce store processing daily transactions does.

For most small business websites, daily backups are sufficient. The important thing is that "daily" means a full backup runs every 24 hours automatically, not that you manually remember to do it. Automated backups are reliable; manual backups are not, because the day you forget is the day before something goes wrong.

For e-commerce sites, membership sites, or any site where user-generated content or transactions happen continuously, daily may not be sufficient. If your store processes fifty orders a day and your backup runs at midnight, a failure at 11pm means you have lost a full day of transaction records. Consider backup windows that align with your transaction volume — twice-daily or every six hours for high-activity periods.

Retention is the question of how far back your backups go. The common advice — keep 30 days of daily backups — is a reasonable baseline, but it is not a universal answer. The relevant question is: how long could malware or a corruption event be present before it is detected? Security researchers consistently find that the average time between a website compromise and its detection is measured in weeks, not hours. A 30-day retention window means a compromise from five weeks ago leaves you without a clean restore point.

A tiered retention policy is more robust than a flat window. Keep daily backups for 30 days. Keep weekly backups for three months. Keep monthly backups for a year. This approach means you have granular recent history for quick fixes (you accidentally deleted a post from two days ago) and reach-back history for serious incidents (your site was compromised six weeks ago and you need a pre-infection copy). The storage cost is modest — a typical small business website backup is a few hundred megabytes — and the protection is significantly greater.

Off-site backups and why they matter

Off-site means physically and logically separate from your hosting provider. A backup stored on the same server as your website is not off-site. A backup stored in the same data centre as your server is technically off-site but still shares a geographic failure domain. True off-site means a different provider, in a different location, accessible independently.

For most small businesses, cloud storage is the practical solution. Amazon S3, Backblaze B2, Cloudflare R2, and Google Cloud Storage all offer inexpensive object storage that can serve as a backup destination. WordPress backup plugins like UpdraftPlus, WPvivid, and All-in-One WP Migration can be configured to push backups automatically to cloud storage on a schedule. For static sites or custom PHP applications, automated scripts using rsync, duplicati, or similar tools accomplish the same thing.

The Canadian dimension matters here. PIPEDA and Quebec's Law 25 both have implications for where personal information is stored. If your backup contains personal information — customer names, email addresses, order records — and that backup is stored on servers in the United States, that data is subject to US law, including US government access requests. For most small businesses, this is a manageable risk with appropriate disclosure in your privacy policy. For businesses handling sensitive personal information or operating in regulated industries, it warrants more careful consideration. Canadian-region storage options exist with all major cloud providers (AWS ca-central-1, Google Cloud northamerica-northeast1 and northamerica-northeast2, Azure Canada Central and Canada East) and allow you to keep backup data within Canadian borders.

Whatever cloud provider you choose, configure access credentials carefully. Your backup destination should have its own access key with write-only or append-only permissions where possible — this limits the damage if those credentials are ever compromised. A ransomware attack that gains access to your hosting account should not be able to delete your cloud storage backups using credentials it finds in your backup plugin configuration.

Testing your backups: the step most people skip

A backup you have never restored is not a backup — it is a hypothesis. The only way to know that your backup will work when you need it is to actually restore from it in a controlled environment. Most website owners never do this. The result is that the first restore they attempt is during a real emergency, under pressure, without the knowledge of whether the backup is complete or the restore process works.

Testing a backup does not require taking your live site offline. The standard approach is to restore to a staging environment — a temporary installation on a development subdomain or a local development environment — and verify that the restored site is functional. Can you log in? Do all the pages load? Is the database intact — does the content match what you expect? Are uploaded files present?

How often you test depends on how risk-tolerant you are and how critical your website is to your business. A minimum reasonable cadence is quarterly — restore to staging four times a year and verify the result. If your site is the primary way customers contact you or make purchases, monthly testing is more appropriate. After any significant change to your website infrastructure — a hosting migration, a major plugin update, a change to your backup tool — run a test restore immediately.

Document the restore process the first time you do it. Write down the exact steps, the time it took, and any complications you encountered. This documentation serves two purposes: it means anyone in your organization can attempt a restore without having to figure it out under pressure, and it gives you a reference for verifying that subsequent restores follow the same pattern and take roughly the same amount of time.

Backup data and Canadian privacy law (PIPEDA obligations)

If your website collects personal information — and nearly every business website does, through contact forms at minimum — your backups contain personal information. That means your backups are subject to PIPEDA's requirements for safeguarding personal information, limiting retention, and ensuring that data is not used for purposes beyond those for which it was collected.

The safeguard obligation (Principle 7 of PIPEDA) applies to all copies of personal information, including backups. An unencrypted backup file sitting in an accessible folder on your server, or stored in a cloud bucket with overly permissive access controls, does not meet the safeguard standard. Backups should be encrypted at rest — most backup tools offer this — and access to backup storage should be restricted to people who have a legitimate reason to access it.

Retention obligations apply to backups as well as live data. PIPEDA Principle 5 requires that personal information be retained only as long as necessary for the purposes for which it was collected. If you have committed to deleting customer data after three years, a backup archive that retains that data for ten years is not PIPEDA-compliant. This is a genuine tension in backup strategy: longer retention is better for disaster recovery, but creates longer-tail privacy obligations. The practical resolution is a documented retention policy that specifies how long backups are kept and ensures that backup data is purged on the same schedule as live data for records that have passed their retention date.

Mandatory breach reporting obligations also apply to backup data. If a backup is compromised — if someone gains unauthorized access to your cloud storage bucket containing website backups — and that backup includes personal information, you may have a reportable breach under PIPEDA. The breach reporting assessment is based on the real risk of significant harm to individuals, not on the format of the data. Encrypted backups that are inaccessible without a key are significantly lower risk than unencrypted backups. Encryption is both a safeguard measure and a meaningful risk-reduction factor in a breach reporting analysis.

For Quebec businesses or businesses with Quebec customers, Law 25 creates additional requirements. Privacy impact assessments are required before using technology that involves personal information — and backup systems that store personal information in cloud storage, particularly outside Canada, fall within scope. Document your backup system, the data it captures, where it is stored, how it is protected, and how long it is retained. This documentation is the foundation of a Law 25 privacy impact assessment for your backup infrastructure.

Website backups are operational insurance. Like all insurance, they need to be sized to the risk, tested to verify they work, and maintained so they remain current. The businesses that recover quickly from website disasters are not the ones with the most sophisticated hosting — they are the ones that treated backups as infrastructure rather than an afterthought, and found out their restore process actually worked before they needed to use it under pressure.