Every website owner learns about backups eventually — the lucky ones learn before disaster strikes. Knowing how to backup your website through your hosting account is one of the highest-value skills in site ownership: it turns hacks, bad updates, and human errors from catastrophes into fifteen-minute inconveniences. Yet most owners either have no backups or have never tested the ones they think they have.
This guide covers the backup options your host provides, what a complete backup includes, how to schedule and store copies safely, and — critically — how to verify your backups actually work before you depend on them.
- What a Complete Backup Includes
- Host-Provided Backup Options
- Backup Frequency and Retention
- Off-Site Storage: The Critical Step
- Testing Your Backups
- Restoring From Backup
What a Complete Backup Includes
A complete website backup has two parts: files (your site’s code, themes, plugins, uploads, and media) and the database (posts, pages, comments, settings, user accounts, and orders). You need both. Files without the database give you an empty shell; a database without files gives you content with no site to display it. Partial backups are a common and painful discovery made at the worst moment.
Also back up the things people forget: email account data if your host handles email, DNS zone records, SSL certificate details, and any server-level configurations like cron jobs or redirects. A migration-grade backup captures everything needed to rebuild the site from scratch on a new server.
Understand the difference between a backup and a sync. Syncing (like Dropbox-style mirroring) replicates deletions and corruptions instantly — if ransomware encrypts your files, sync copies the encrypted versions. True backups are point-in-time snapshots you can roll back to, which is why versioned backup systems matter. The same principle applies to personal data: backing up your computer properly means versioned snapshots, not just mirrored folders.
Host-Provided Backup Options
Most hosts offer some backup capability, but the details vary enormously. Automatic daily backups are the gold standard for shared and managed hosting: the host snapshots your account every night and retains some days or weeks of history. Check what “automatic” actually includes — files only, or database too? How many restore points are kept? Is restore self-service or does it require a support ticket?
On-demand backups let you snapshot manually before risky changes — updating plugins, redesigning, migrating. Always take one before major work; it costs nothing and saves everything. Control-panel backups (full account exports from cPanel or Plesk) are excellent for migrations and for keeping your own downloadable copies.
Read the fine print on retention and guarantees. Some hosts keep only a few days of backups; others disclaim responsibility for backup integrity entirely. Host backups are a safety net provided as a courtesy on many plans — valuable, but not something to rely on exclusively. For keeping those personal copies safe, secure cloud storage practices apply just as much to backup archives as to any sensitive files.
Backup Frequency and Retention
How often should you back up? Match frequency to how often your site changes. A static brochure site that changes monthly is fine with weekly backups. A blog publishing daily needs daily backups. A WooCommerce store processing orders needs daily backups at minimum — ideally more frequent database snapshots, since every lost hour can mean lost orders.
Retention — how many historical copies you keep — matters as much as frequency. Keep multiple restore points because problems are often discovered late: a hack might have happened three weeks ago, making yesterday’s backup infected too. A common scheme is daily backups kept for a week, plus weekly backups kept for a month, plus monthly backups kept longer.
Automate all of it. Manual backups fail because humans forget, get busy, or assume “I’ll do it tomorrow.” Whether through your host’s scheduler or a backup plugin, set the schedule once and let it run — then verify periodically that it is actually running.
Off-Site Storage: The Critical Step
A backup stored on the same server as your website is barely a backup. If the server fails, gets hacked, or your hosting account is compromised, the attacker or the outage takes your backups with it. Off-site storage — copies kept somewhere completely separate from your hosting account — is what makes backups actually protective.
Practical options: download backup archives to your own computer or external drive periodically, push automated backups to independent cloud storage, or use a backup plugin that supports remote destinations. The 3-2-1 rule is the classic guidance: three copies of your data, on two different media types, with one copy off-site.
Encrypt sensitive backups. Backup archives contain your database — including user emails, and possibly customer data — in readable form. If you store them in cloud storage or on portable drives, encryption protects that data if the storage is ever accessed by the wrong person. This is the same discipline as backing up your phone: the backup is only as safe as where you keep it.
Testing Your Backups
Here is the step almost everyone skips: test your restores. A backup file that is corrupted, truncated, or incomplete is worse than no backup, because it gives false confidence. Schedule a test restore at least twice a year — more often for critical sites.
The safest way to test is restoring to a staging environment or a local copy, never over your live site. Verify that the restored site loads, key pages work, the database is complete (spot-check recent content), and logins function. If anything is missing or broken, fix your backup process immediately — you have just discovered the problem on your terms instead of during a crisis.
Also verify you can actually access your off-site copies: confirm cloud storage credentials work, external drives mount, and archive files open. Access failures discovered during an emergency are a special kind of misery.
Restoring From Backup
When disaster strikes, work methodically. First, assess: what happened, and when? Choose a restore point from before the incident — for hacks, that may mean going back further than you expect. If possible, take a snapshot of the current (broken) state first, in case you need to recover something from it.
Restore files and database together from the same point in time to keep them consistent. After restoring, immediately update everything (the vulnerability that caused the problem may still exist), change all passwords, and scan for remaining malicious code. Then monitor closely for a few days.
Finally, treat every incident as a lesson: document what happened, what you restored, and what you will change — backup frequency, security hardening, monitoring. The goal is not just recovery but making the next incident less likely and less painful. For authoritative guidance on data protection practices, CISA offers resources on backups as part of cyber resilience.