For many business websites, a daily backup is a practical starting point. A busy online shop or membership site may need backups every few hours, or more frequently, to protect recent orders and registrations. Take an additional backup before important changes, even when an automatic schedule is already running.
The right frequency depends on how much recent data you can afford to lose. This guide helps you choose a website backup schedule, decide how long to keep copies and check that your recovery process works. For a broader introduction, read our guide to building a website backup strategy.
Start with the changes you cannot afford to lose
A website backup saves a recoverable version of your site. For a database-driven website such as WordPress, that normally means both the website files and the database. Include uploads, themes, plugins and configuration, and check whether any important information lives in a separate booking, sales or email service.
Ask what would happen if you had to restore yesterday’s version. Could you recreate the missing changes? Would you lose enquiries, orders or customer registrations? A brochure site that looks unchanged may still collect valuable information throughout the day.
The amount of recent data you can tolerate losing is your recovery point objective, or RPO. Your recovery time objective, or RTO, is the maximum time you aim to allow for restoring the service. If losing an hour of orders would be unacceptable, a daily database backup will not meet your needs.
Choose a website backup frequency
Use the following schedules as starting points, then adjust them to your website’s activity and the recovery objectives you have set.
| Website activity | Example starting schedule | Take an extra backup when |
| Business or brochure site with occasional edits | Daily, with a copy after important changes | You change the design, configuration or key pages |
| Blog or content website | Daily; more often if important work is published throughout the day | You publish a substantial batch of content or change the CMS |
| Online shop processing orders regularly | Hourly or more frequent database backups where supported; choose an interval that meets your acceptable data loss | You change checkout, payment integrations, stock handling or the platform |
| Membership site, forum or booking website | Every few hours or more frequently, according to activity and acceptable loss | You change permissions, membership rules or booking functionality |
Files and databases may need different schedules. Product images may change occasionally while orders change every minute. Your backup tool must still let you restore compatible files and database data together. Ask your provider or developer how that consistency is maintained before relying on separate schedules.
Frequent full backups can use server resources and storage. Incremental backups save changes and need a suitable baseline and recovery chain, or the tool’s equivalent reconstruction process. Check that the plan and restore method support your chosen schedule.
Back up before important changes
A scheduled backup may be several hours old when you start an update. Create a fresh recovery point before changing WordPress core, plugins, themes, server settings, or an important integration. Confirm that it has completed before proceeding. For WordPress installations managed through Softaculous in cPanel, our WordPress update guide explains how to create a manual backup of the installation’s directory and database.
After the change, check the pages and features it could affect. Once everything works, make sure the regular backup schedule is still running. A backup made before an update is an extra recovery option, rather than a replacement for routine backups
Keep enough recovery history
Backup frequency and retention answer different questions. Frequency determines how recent a recovery point can be. Retention determines how far back you can go when you discover a problem.
A faulty update or unnoticed compromise may take time to become apparent. Keeping only the newest copy can leave you without a suitable older version. Choose a retention period that reflects how quickly your team is likely to discover problems and what recovery history the business needs.
For example, a business might choose daily copies for 30 days and a smaller set of monthly recovery points for longer-term needs. That is an example policy, not a requirement for every website. It also needs more storage and retention than a short recovery window provided with a hosting plan.
Where backups contain personal data, document why you keep it and when copies expire. The ICO’s storage limitation guidance explains that retention depends on purpose; UK GDPR does not set one universal storage period.
Store a copy separately from your live hosting
Keep an independent backup away from the live website. A copy in the same hosting account may be affected by the same account compromise, deletion or server problem.
The 3-2-1 approach means keeping at least three copies of the data across two storage devices or media, with one copy off-site. One example is your live website, an independent cloud backup, and a copy on an external drive that is disconnected after use. Your hosting provider’s recovery points can be an additional option.
When choosing a backup destination, check version history, access controls, retention and recovery options. Use strong unique credentials and multifactor authentication where available. Encrypt sensitive copies using a supported method, and keep the recovery keys accessible to authorised people during an incident.
A synchronised cloud folder can propagate deletions, so check what protects older copies from being changed or removed. Off-site storage alone does not make a backup resistant to ransomware.
Check your Heart Internet recovery points
Heart Internet’s current cPanel platform uses JetBackup 5 for recovery points covering the previous seven days. Check the dates and items available in your account, particularly if you use another hosting product or an older platform.
To find the cPanel restore options:
- Open cPanel from your Heart Internet account.
- Go to Files and open JetBackup 5.
- Select Domains and inspect the available backups.
- Use Choose Other Backup when you need an older recovery point, then check what the restore will replace.
Follow our cPanel backup and restore instructions for the current process. Confirm that recovery includes the files and database your site needs. Completion time varies, so avoid treating any estimate as a recovery guarantee.
If you download a full cPanel account backup, establish how it would be restored. cPanel’s documentation distinguishes partial restores from full account restoration, which requires WHM or help from the hosting provider.
Test that your schedule supports recovery
Check backup completion and failure notifications regularly. An alert is useful only if someone is responsible for responding to it.
Test a restore at an interval appropriate to the website. A quarterly test may be a starting point for a small site; test again after major changes to the platform or backup setup, and more often where business requirements demand it.
Use an isolated test environment with its own database and access protection. Disable live payments, customer emails, scheduled jobs, and external integrations, or replace them with suitable test settings, before using the restored site.
During the test, check that:
- The expected pages, images and recent data are present.
- Login, forms and relevant transaction flows work safely.
- The required recovery steps can be followed by someone else on the team.
- The measured restore time meets your recovery objective.
Record the result and fix any failures. Following a security incident, choose a known clean recovery point and address the original cause before returning the website to service.
