Website Backup Strategy: How to Back Up, Test and Restore Your Site

Short answer: A website backup strategy is only as good as your last successful restore. Decide how much data you can afford to lose and how long you can be offline. Back up the files and the database together, on a schedule that matches how often the site changes. Keep at least three copies, and make sure one of them sits outside your hosting account, ideally offline or impossible to change. Keep enough history to go back past the point where a hack started. Then test a restore before you ever need one. Your host’s daily backups are a strong layer, but they shouldn’t be the only one.

This guide is written for small business owners and the people who look after their sites. It covers what a complete website backup includes and how to set recovery targets. It also explains how the 3-2-1 rule works for a hosted site, how long to keep backups, how to run a restore drill, and the order to follow when you actually have to recover. The advice is drawn from Canadian Centre for Cyber Security, CISA, NIST, WordPress.org and cPanel documentation, all checked on November 2, 2026.

What is a website backup strategy, and how is it different from a recovery plan?

A website backup strategy is the set of decisions about what you copy, how often, where the copies live, how long you keep them, and who can reach them. A recovery plan is the other half: the written steps, owners and time targets for turning one of those copies back into a working website.

Most backup advice stops at the first half. It says “turn on automated backups” and moves on. In practice, recoveries fail for reasons that have nothing to do with whether a backup existed:

• The backup was stored in the same account that got compromised, so it was encrypted or deleted along with the site.
• Every restore point was taken after the malware arrived, because the hack went unnoticed for weeks and retention was only a few days.
• The files were backed up but the database wasn’t, or the two were taken hours apart and don’t match.
• Nobody knew where the backups were, who had the login, or whether a full restore needed a support ticket.
• The restore worked, but it quietly rolled back two days of orders and form submissions.

The Canadian Centre for Cyber Security frames backups in terms of two goals: availability, meaning people can keep reaching your information, and recovery, meaning you can restore systems and limit the information, time and money lost to downtime (Cyber Centre, ITSAP.40.002). A strategy that only covers copying serves the first goal at best. The rest of this guide covers both.

What does a complete website backup include?

A complete website backup includes everything you would need to rebuild the site on a fresh server and have it behave exactly as it did before. For most sites that means more than one thing.

WordPress’s own documentation makes the most common gap explicit. Backing up your WordPress files does not back up the database, because the database lives in a separate system (usually MySQL or MariaDB). You need both to fully restore a typical WordPress site (WordPress.org, Backups). The same is true of most content management systems and online stores.

Two items belong in your plan but not in the backup file itself. Keep credentials for the hosting account, registrar, DNS and backup storage in a password manager, not in a text file inside the site. And keep a list of paid plugin and theme licences, so a rebuild doesn’t stall on a key you can’t find.

cPanel’s Backup Wizard shows how these pieces split up on most Canadian shared hosting. A full backup is a single .tar.gz archive of the account. Partial backups are separate downloads for the home directory, MySQL databases, and email forwarders and filters. A home directory backup includes your public_html files and the email for your domains (cPanel Docs, Backup Wizard).

Set your recovery targets first: RPO and RTO

Before you choose tools or schedules, write down two numbers. NIST SP 800-34 defines them:

• Recovery point objective (RPO): “The point in time to which data must be recovered after an outage” (NIST CSRC glossary, RPO). In plain terms, it’s how much recent work you can afford to lose.
• Recovery time objective (RTO): “The overall length of time an information system’s components can be in the recovery phase before negatively impacting the organization’s mission” (NIST CSRC glossary, RTO). In other words, it’s how long the site can be down.

CISA’s backup guidance for small and medium businesses tells owners to use scheduled recovery tests to refine both numbers until they match business needs (CISA, Back Up Business Data). Your RPO drives backup frequency. Your RTO drives where you store backups and how restores work, because a restore that depends on downloading a large archive over a slow office connection can’t meet a two-hour target.

The table below gives starting points, not rules. Adjust them to what a lost day or a lost hour actually costs you.

For stores, remember that the payment processor keeps its own transaction records. If a restore loses a few hours of orders, those records let you rebuild them. That’s part of your real RPO, so check you can export them before you need to.

The 3-2-1 rule, applied to a hosted website

The 3-2-1 rule is the most widely cited backup guideline. CISA puts it simply: keep 3 copies of important files, on 2 different types of storage media, with 1 copy stored off-site (CISA, Back Up Business Data). WordPress’s handbook gives the same advice in its own words: keep at least three backups, in different places and on different media, in case one is corrupted or lost (WordPress.org, Backups).

For a site on shared, managed WordPress or VPS hosting, the three copies usually look like this:

1. The live site on the hosting server. It counts as a copy, but it’s the one most likely to be damaged.
2. Your host’s backups, taken automatically and stored separately from the live server. This is your fastest restore path for everyday mistakes.
3. A copy you control outside the hosting account: object storage with versioning, a separate cloud account, or an encrypted external drive. This is your restore path when the account itself is the problem, whether that’s compromised credentials, a billing lapse, a provider dispute or a deleted account.

The third copy is the one most small sites skip, and it’s the one that matters most in a ransomware or account-takeover incident. The Cyber Centre recommends keeping at least one backup offline. Offline (or “cold”) backups stay disconnected from your systems until needed, so they’re unaffected by many threats, ransomware included, that can compromise everything on a network (Cyber Centre, ITSAP.40.002). Its baseline controls for small and medium organizations go further: backups should be encrypted and accessible only to the people responsible for testing and restoring them. Long-term backups, such as weekly ones, must be stored offline, while frequent daily backups may stay online (Cyber Centre, Baseline cyber security controls).

CISA’s #StopRansomware Guide explains why. Many ransomware variants try to find and delete or encrypt any backups they can reach, which makes restoring impossible unless the ransom is paid (CISA, #StopRansomware Guide). In a 2024 advisory, CISA and its partners recommended that backup data be encrypted and immutable, meaning it can’t be altered or deleted (CISA, Akira ransomware advisory AA24-109A).

For a small website, “offline or immutable” doesn’t need enterprise hardware. Any of these meets the spirit of the guidance:

• Object storage with versioning and a retention lock turned on, using credentials that the website itself never holds.
• A monthly full backup downloaded to an encrypted drive that is unplugged and stored away from the office.
• A separate cloud account with its own login and multi-factor authentication, where the website can write new backups but can’t delete old ones.

The test is simple. If an attacker had your website admin password, or full control of your hosting account, could they reach that copy and destroy it? If the answer is yes, it isn’t your third copy.

RAID, snapshots, host backups and plugin backups: what each one protects against

Not everything that sounds like a backup works like one. Redundant storage (RAID) keeps a server running when a disk fails. But it mirrors every change instantly, including deletions, corruption and malware. 4GoodHosting’s own Linux VPS hosting page puts it plainly: RAID provides storage redundancy and is not a substitute for backups.

A backup plugin that writes its archives into the site’s own folders is a weak layer. Those copies sit inside the thing being backed up, so whatever takes out the site usually takes them out too. p4e’s guide to WordPress hosting speed, security and backups covers this WordPress-specific trap in more detail. If you use a plugin, point it at external storage. 4GoodHosting’s roundups of WordPress backup plugins and why WordPress backups matter and how to do them compare common options.

How long should you keep website backups?

Keep website backups long enough to reach a clean copy from before any problem you might find late. For most small business sites, that means daily restore points for at least the last week or two, plus older weekly and monthly copies. A short retention window is the most common reason a backup exists but can’t be used.

Hacks and data corruption are rarely discovered the day they happen. Google’s guide to recovering a hacked site tells owners to work out when suspicious activity first occurred, because that determines which backups might still be clean. It also says to check that a backup was created before the site was hacked before restoring it (web.dev, Identify the vulnerability; web.dev, Clean and maintain your site). CISA advises testing that you can roll data back at least seven days if needed (CISA, Back Up Business Data). That’s a floor, not a target.

A simple rotation works well for most sites:

• Daily backups, kept for 14 to 30 days.
• Weekly backups, kept for 2 to 3 months.
• Monthly backups, kept for 6 to 12 months, with at least one stored offline.
• Before every major change (core or plugin updates, theme edits, migrations, redesigns), a manual full backup labelled with the date and the reason.

Check your host’s retention rather than assuming it. 4GoodHosting’s help article on creating and restoring a cPanel backup says that retention for its nightly server backups can vary by plan, and asks customers to confirm current retention with support. That’s the right question to put to any provider.

Longer retention has a cost beyond storage. Backups contain everything the site holds: customer names, emails, order histories, sometimes account details. They’re subject to the same privacy safeguards as the live site, so encrypt them, restrict who can open them, and delete old copies on schedule.

How to automate backups without creating new risks

Automation fixes the biggest weakness of manual backups, which is that people forget. But an automated job can fail silently for months. Build these checks into the setup:

• Turn on notifications and read them. cPanel’s Backup interface can email you when a backup finishes (cPanel Docs, Backup for cPanel). Most plugins and backup services can report failures too. A failure alert that goes to an unwatched inbox is the same as no alert.
• Watch your disk quota. cPanel warns that a backup of an account near or over its quota may fail, because the system can’t write files it needs, such as a database lock file (cPanel Docs, Backup Wizard). If you keep running into quota limits, see p4e’s guide to the signs it’s time to upgrade your web hosting plan.
• Send copies off the server using a secure method. cPanel can deliver a full backup to a remote server over FTP or Secure Copy (SCP) (cPanel Docs, Backup for cPanel). Choose SCP or another encrypted transfer over plain FTP, which sends credentials unencrypted.
• Capture files and database at the same moment. If the database is exported hours after the files, a restore can leave orders pointing at images that don’t exist, or the reverse. Use a tool that captures both in one job.
• Separate the credentials. The login that writes backups to off-site storage shouldn’t be able to delete them. It also shouldn’t be stored somewhere an attacker with website admin access could read it.
• Encrypt backups that leave the server. The Cyber Centre’s baseline controls call for backups to be stored in an encrypted state (Cyber Centre, Baseline cyber security controls).
• Keep a manual habit too. WordPress’s handbook recommends backing up automated backups with a manual one now and then, to confirm the process is working (WordPress.org, Backups).

For a database-only copy before a risky change, a phpMyAdmin export is quick. 4GoodHosting has a walkthrough on backing up your database with phpMyAdmin, and WordPress documents the same process in Backing Up Your Database.

How to test a website restore (a 30-minute drill)

A backup you have never restored is an assumption. NIST’s Cybersecurity Framework 2.0 lists the expectation as a single outcome: “Backups of data are created, protected, maintained, and tested” (PR.DS-11). It adds that backup integrity should be verified before a restore (RC.RP-03), and that restored systems should be checked before normal operations resume (RC.RP-05) (NIST, Cybersecurity Framework 2.0). The Cyber Centre recommends testing recovery from backup on a routine basis, and CISA says to test that your team can restore data both fully and partially (Cyber Centre, ITSAP.40.002; CISA, Back Up Business Data).

Run this drill every quarter, and after any change to hosting or backup tools:

1. Pick a backup at random, not just the newest. Pick one from your off-site or offline copy at least once a year.
2. Restore it somewhere safe: a staging site, a test subdomain, or a local environment. Never test by overwriting the live site.
3. Time it, from “decide to restore” to “site loads”. Compare the result with your RTO.
4. Check what matters: the homepage, a recent post or product, the contact form, login, the cart and checkout in test mode, and images from the newest uploads.
5. Check the date of the newest content in the restored copy. Compare it with your RPO.
6. Write down what went wrong: missing files, a password nobody had, a step that needed a support ticket. Then fix it.
7. Delete the test copy when you’re done, or protect it as carefully as production, since it holds real data.

The first drill is usually the most valuable, because it reveals the gaps: a database password nobody recorded, an archive too large to upload through the control panel, or a plugin licence tied to the old domain.

Step-by-step: recovering a website from a backup

When something breaks, the urge is to hit “restore” straight away. For a simple mistake, like a bad plugin update caught within the hour, that’s often right. For anything involving a possible hack, slow down and follow an order. The steps below follow Google’s hacked-site recovery guidance and CISA’s ransomware response checklist (web.dev, Clean and maintain your site; CISA, #StopRansomware Guide).

1. Stop making it worse

Pause scheduled updates and deployments. If the site is hacked or is serving harmful content, take it offline or put up a maintenance page. For an outage of a day or two, Google recommends returning an informational error page with a 503 status code. Keep robots.txt crawlable, because a 503 on robots.txt blocks all crawling (Google Search Central, Temporarily pause or disable a website).

2. Work out what happened and when

Was it a failed update, an accidental deletion, a database error, or a compromise? Check access logs, recent logins and file modification dates. The time the problem started tells you which restore points are safe to use.

3. Preserve the damaged copy

Before restoring over a hacked site, Google’s guidance is to take a full copy of the compromised files and database first (web.dev, Clean and maintain your site). You’ll need it to find out how the attacker got in, and it may hold recent orders or posts you want to recover by hand.

4. Choose the restore point

Use the newest backup taken before the problem began. If the timing is unclear, restore an older copy to staging first and inspect it. A restore point that already contains the backdoor will just put you back where you started.

5. Restore files, then the database

WordPress documents the usual order: restore the files first, then import the database. If database credentials changed during the move, update wp-config.php to match (WordPress.org, Backups). On cPanel, you can restore partial backups (home directory, databases, email forwarders and filters) yourself through the Backup Wizard. But cPanel’s documentation notes that a full backup can’t be restored automatically from cPanel. That function is only available in WHM, so you’d ask your hosting provider (cPanel Docs, Backup Wizard). Know which kind of restore your host lets you do yourself before you need one.

For a single deleted page template or image, a whole-site restore is overkill. Restore just that file or directory, through your host’s file restoration tool if it offers one, or from a backup archive.

6. Close the hole before going live

If the cause was a compromise, restoring alone isn’t enough. Google’s guidance is to install all available updates and patches after restoring, remove software you no longer use, and change passwords (web.dev, Clean and maintain your site). Rotate every credential: hosting, CMS admin accounts, database, SFTP, API keys and the backup storage login.

7. Verify, then reopen

Run the same checks as your restore drill. Clear any page cache and CDN cache. Confirm the site returns normal 200 responses and that forms, payments and emails work.

8. Reconcile what the restore rolled back

Compare orders, bookings, sign-ups and form entries against the payment processor, email notifications and third-party tools for the gap between the restore point and the incident. Re-enter or contact customers as needed.

9. Report if you have to, and write it down

Organizations subject to PIPEDA must keep records of all breaches of security safeguards. If personal information was involved and the breach creates a real risk of significant harm, they must also report it to the Office of the Privacy Commissioner of Canada and notify the people affected (OPC, Mandatory reporting of breaches of security safeguards). Restoring from a backup doesn’t remove that obligation. Finally, record what happened, how long recovery took and what you’ll change. CISA lists documenting lessons learned as part of post-incident recovery (CISA, #StopRansomware Guide).

What 4GoodHosting’s backups cover, and what to ask any host

If your site runs on 4GoodHosting, this is what the company’s live pages said on November 2, 2026. Confirm the current details for your own plan with support.

• Linux shared hosting: the Linux web hosting page says sites are backed up automatically every day, with offsite copies stored out of province. It also says these servers use RAID 10 disk mirroring.
• Self-service cPanel backups and restores: the cPanel backup help article says nightly backups are kept on hosting servers, with retention that can vary by plan. Customers can generate a full or partial backup in cPanel’s Backup or Backup Wizard and download it. To restore, they can use the Backup Wizard, or open a ticket asking for a restore from 4GoodHosting’s snapshots, giving the approximate date and time. The article also advises downloading a backup before major site changes or migrations.
• Managed WordPress hosting: the plan comparison lists automatic daily backups on every plan, with 1-click restores.
• Linux VPS: the VPS page treats backups as separate from RAID storage. It says the Level 3 managed support option includes 50 GB of onsite backups, and asks customers to contact support to confirm retention, restoration and any offsite requirements. 4GoodHosting’s article on why VPS hosting with backup matters covers that decision in more depth.
• Its own advice: 4GoodHosting’s data centres page says storage resilience and a backup are different protections. It tells customers to confirm the backup options, latest restore point and restoration process for their service, and to keep a separate copy of critical data. That’s the 3-2-1 rule in the host’s own words.

Whoever hosts your site, ask these questions and keep the answers with your recovery plan:

1. How often are backups taken, and how many days or restore points are kept?
2. Are backups stored on the same server, in the same data centre, or off-site?
3. Do backups cover files, databases and email?
4. Can I restore files, databases and the full account myself, or do some restores need a ticket? How long do they usually take?
5. Can I download a full backup at any time, in a standard format I could restore elsewhere?
6. If my account is suspended, cancelled or compromised, what happens to the backups?
7. If I host in Canada for data-residency reasons, are the backups also stored in Canada?

A one-page website backup and recovery plan

Fill this in once, store a copy outside the website (printed, or in a shared drive), and review it every time you run a restore drill.

FAQ

How often should I back up my website?

Back up as often as your content changes, and always before updates or major edits. For a brochure site, daily host backups plus a manual copy after edits are usually enough. For a store or booking site, the database needs backing up far more often than daily, because every order placed after the last backup is at risk.

Are my web host’s backups enough?

They’re a valuable layer, often the fastest way to recover, but they shouldn’t be your only copy. Host backups may not reach back far enough to predate a late-discovered hack, and they may be out of reach if your hosting account is compromised, suspended or closed. Keep at least one copy that you control outside the hosting account.

What’s the difference between a full, incremental and differential backup?

A full backup copies everything. A differential backup copies what has changed since the last full backup. An incremental backup copies only what changed since the most recent backup of any kind. Incrementals are fast and small, but restoring one means processing each increment in sequence, which takes longer (Cyber Centre, ITSAP.40.002).

Is a backup plugin better than my host’s backups?

They solve different problems, so many sites use both. Host backups work at the server or account level and don’t depend on the website running. A plugin can send copies to storage you control and run on its own schedule. If you use a plugin, make sure it stores archives off the server, not inside the site’s own folders.

Can ransomware or malware infect my backups?

Yes, if they’re reachable. Ransomware often goes looking for backups to delete or encrypt, and a backup taken after an infection will contain the infection. Keep at least one copy offline or immutable, keep enough history to reach a clean point, and scan or inspect a restore point in staging before trusting it.

How do I know my backups actually work?

Restore one. Run a restore drill to a staging site every quarter. Time it, check the newest content, and test the forms and checkout. A successful backup job only proves a file was written, not that it can bring your site back.

Key Takeaways

• Define your RPO (how much data you can lose) and RTO (how long you can be down) before you choose tools or schedules.
• A complete backup covers files and the database captured together, plus configuration, email, DNS records and data held by other services.
• Follow 3-2-1: the live site, your host’s backups, and a copy you control outside the hosting account, with at least one kept offline or immutable.
• RAID and backups stored inside the site aren’t real backups. They don’t protect against deletion, corruption or compromise.
• Keep enough history to reach back past a late-discovered hack: daily copies for weeks, plus weekly and monthly copies.
• Test restores quarterly in staging, and follow a set order in a real incident: stop, investigate, preserve, restore, patch, verify, reconcile and report.

Sources

• Canadian Centre for Cyber Security, Tips for backing up your information (ITSAP.40.002)
• Canadian Centre for Cyber Security, Baseline cyber security controls for small and medium organizations
• CISA, Back Up Business Data
• CISA, #StopRansomware Guide
• CISA, #StopRansomware: Akira Ransomware (AA24-109A)
• NIST CSRC glossary, Recovery Point Objective
• NIST CSRC glossary, Recovery Time Objective
• NIST, The NIST Cybersecurity Framework (CSF) 2.0
• WordPress.org Advanced Administration Handbook, Backups
• WordPress.org Advanced Administration Handbook, Backing Up Your Database
• cPanel & WHM Documentation, Backup Wizard
• cPanel & WHM Documentation, Backup for cPanel
• web.dev, Identify the vulnerability
• web.dev, Clean and maintain your site
• Google Search Central, Temporarily pause or disable a website
• Office of the Privacy Commissioner of Canada, Mandatory reporting of breaches of security safeguards

About the author: This article was written by the team at 4GoodHosting, a Canadian web hosting company operating since 2002 with servers in Vancouver and Toronto. This article is a guest contribution to P4 Emachines.