There is no single correct answer to “How often should I back up my website?”
The right frequency depends on how quickly valuable data changes and how much recent work, customer information or revenue the business could afford to lose.
A five-page brochure site updated once a month may be comfortable with daily or even weekly restore points. A WooCommerce store taking orders every few minutes may need database protection far more frequently.
Set the backup schedule by the acceptable data-loss window.
Ask: if the site failed right now and we had to restore the latest backup, how many minutes, hours or days of new data could the business afford to lose? That answer is your starting point.
A practical website backup schedule by site type
| Website type | Practical starting point | Main data at risk |
|---|---|---|
| Static brochure site | Daily or weekly | Content/design changes |
| Blog/news site | Daily, more often during heavy publishing | Posts, comments, media |
| Lead-generation site | Daily site backup + independent lead storage | Forms, enquiries, configuration |
| Bookings/membership | Several times daily or event-driven | Bookings, members, payments |
| WooCommerce | Frequent database/incremental backups; potentially real-time | Orders, customers, stock |
These are starting points. The actual schedule should follow your business risk.
What is RPO and why does it matter?
Recovery Point Objective (RPO) means the maximum amount of recent data the business is prepared to lose after a failure.
If your RPO is 24 hours, a daily backup may be enough.
If your RPO is one hour, daily is nowhere near enough.
For a WooCommerce store taking £2,000 of orders per hour, that difference is obvious.
What is RTO?
Recovery Time Objective (RTO) is how quickly the site needs to be restored after failure.
Backup frequency and recovery speed are related but different.
You can have an hourly backup and still need six hours to restore it if:
- nobody knows the restore process;
- credentials are missing;
- the archive is huge;
- the backup has never been tested.
Files and database change at different speeds
A WordPress website has two main categories of recoverable data.
Files
These include:
- themes;
- plugins;
- uploads;
- custom code;
- WordPress files.
Files may change only when somebody updates the site or uploads media.
Database
The database can contain:
- pages;
- posts;
- settings;
- users;
- orders;
- comments;
- bookings;
- plugin data;
- form submissions.
On a dynamic site, database activity can happen constantly.
Does a brochure site really need daily backups?
Not always from a pure RPO perspective.
If nothing changes for weeks, a seven-day-old copy may be functionally identical to yesterday’s.
But automated daily backups are now inexpensive and common, so many businesses use them anyway.
The bigger questions are whether the backup is:
- complete;
- kept long enough;
- stored separately;
- restorable.
How often should a lead-generation site be backed up?
Daily site backups are a sensible baseline, but the more important question is what happens to enquiries.
If form submissions live only inside WordPress, restoring yesterday’s database can erase today’s leads.
Consider sending enquiries into:
- email;
- CRM;
- external form storage;
- helpdesk;
so lead recovery does not depend on the website database alone.
How often should a WooCommerce store be backed up?
According to order frequency.
A store receiving two orders a week might tolerate a daily backup.
A busy store receiving several orders per hour may need:
- hourly database backups;
- incremental backups;
- real-time order/database protection.
The WooCommerce maintenance checklist covers the wider operational checks around orders and payments.
How often should a booking site be backed up?
Think about how often customers book, cancel or reschedule.
If losing half a day of appointments would create operational chaos, half-day or daily backups are not enough.
How often should a news or frequently updated content site be backed up?
Match the schedule to publishing activity.
A site publishing ten stories a day should not use the same schedule as a blog publishing once a month.
Back up before risky changes even if the automatic schedule just ran
Take or verify a fresh restore point before:
- major plugin updates;
- WordPress core changes;
- PHP upgrades;
- theme changes;
- database optimisation;
- large imports;
- site migrations;
- redesign launches.
The WordPress update guide explains why change-specific backups matter even when normal automation is healthy.
How many restore points should you keep?
One backup is not a backup strategy.
A useful retention model often combines:
- recent hourly/daily backups;
- older weekly backups;
- monthly archive points.
The reason is simple: you may discover a problem long after it began.
If malware was added ten days ago, restoring yesterday’s copy may restore the malware too.
Use the 3-2-1 principle as a resilience guide
A commonly used backup principle is:
- 3 copies of important data;
- 2 different storage types or locations;
- 1 copy off-site / separated from production.
You do not need to follow the wording mechanically, but the principle is valuable: do not keep your only recovery copy next to the thing that may fail.
Why same-server backups are weak on their own
If the entire hosting account is:
- deleted;
- compromised;
- corrupted;
- suspended;
- inaccessible;
a backup stored only inside that account may disappear with it.
Cloud backups can fail too
Remote storage is safer, not infallible.
Check for:
- expired API credentials;
- full storage quota;
- billing failure;
- retention changes;
- incomplete archives.
Do hosting backups count?
Yes, but understand the terms.
Ask:
- how often they run;
- how long they are kept;
- whether both files and database are included;
- whether you can restore yourself;
- whether backups survive account failure;
- whether the host guarantees them.
For important sites, an independent backup layer adds resilience.
Should you keep manual backups too?
Before major changes, a manual point-in-time backup can be useful even when automation exists.
Label it clearly with the date and reason.
Backup frequency is not the same as backup retention
A site can back up every hour but keep only 24 hours of history.
Another can back up daily and keep 90 days.
Both numbers matter.
Backups should be encrypted where appropriate
A backup may contain:
- customer data;
- user accounts;
- business records;
- configuration secrets.
Protect backup storage with appropriate access controls and encryption where supported.
Who should have access to backups?
Use least privilege.
People who need to restore should have access. Former staff, old developers and unused agency accounts should not.
Should backups include email?
Website backups and email backups are often separate systems.
If business email is hosted elsewhere, do not assume a WordPress backup includes it.
How often should backups be tested?
A scheduled archive can complete successfully and still be unusable.
Test recovery periodically and after major changes to:
- host;
- backup tool;
- PHP;
- site architecture;
- ecommerce/booking systems.
The backup restore-testing guide gives the full process.
A useful backup policy for a small business
1. Set RPO: how much recent data can we lose?
2. Set RTO: how quickly must the site return?
3. Set frequency: faster than the RPO.
4. Set retention: enough history to escape silent problems.
5. Store independently: do not rely on one server/account.
6. Test restores: prove recovery.
7. Document ownership: who responds during an incident?
When should you increase backup frequency?
Review the schedule when:
- orders increase;
- publishing increases;
- you add booking/membership;
- forms become business-critical;
- you launch paid campaigns;
- the maximum acceptable data-loss window shrinks.
When can you reduce frequency?
If a site becomes effectively static and critical data lives elsewhere, the business may decide a less frequent schedule is acceptable.
Make that decision consciously rather than because backups silently stopped.
How Core Web UK handles backup planning
Our website maintenance and support service matches backup and recovery expectations to the site’s business risk rather than applying the same schedule to every WordPress install.
The website maintenance cost guide explains why recovery requirements change the cost of hands-on maintenance.
Frequently asked questions
Is a daily website backup enough?
For many brochure and lead-generation sites, yes. For busy ecommerce, booking or membership sites, a day of lost data may be unacceptable.
Should WooCommerce be backed up hourly?
If the store receives enough orders that losing several hours would be costly, hourly or incremental database backups can make sense.
How many website backups should I keep?
Keep multiple restore points across recent and older periods. The right retention depends on storage, risk and how long silent problems may go unnoticed.
Are hosting backups enough?
They can be part of the strategy, but understand frequency, retention, restore access and whether an independent copy is needed.
Should I back up before plugin updates?
For higher-risk updates, yes. A current point-in-time backup gives you a cleaner rollback route.
How do I know a backup actually works?
Restore it into an isolated environment and verify the files, database and business-critical functions.
Choose it from the amount of real data the business can afford to lose — then make sure the backups are kept long enough, stored separately and proven by a restore test.
Choose backup frequency from your acceptable data-loss window
The right schedule is easier to decide when you stop asking “daily or weekly?” and ask a more practical question:
If the site failed right now, how much recent data could the business afford to lose?
That window is your recovery point objective.
| Site type | Typical risk | Practical starting point |
|---|---|---|
| Static brochure | Few content changes | Daily or weekly depending on edit frequency, plus before major changes |
| Lead generation | Forms and regular edits | Daily database/full backups plus stored form/CRM records |
| WooCommerce | Orders, stock and customer data change continuously | Frequent or real-time database protection where order volume justifies it |
| Membership / booking | User and booking data changes throughout the day | Several backups per day or continuous protection where required |
Use more than one backup location
A backup stored only on the same server as the live site is vulnerable to the same hosting failure, account compromise or storage problem. Keep at least one independent off-site copy for important sites.
Back up before high-risk changes even if the schedule already ran
Create an additional current restore point before core, theme, WooCommerce, PHP, migration or major plugin changes. A backup from twelve hours earlier may be technically “daily” and still contain an unacceptable data gap.
