How often should my website be backed up?

The short answer: daily, at minimum

How often you back up depends on how much work you could afford to lose. A useful way to think about it is: how many hours of changes could I recreate if the site broke right now?

• Brochure sites that change a few times a month: daily backups are plenty.
• Blogs and news sites with regular posts and comments: daily backups, plus a manual backup before big updates.
• Online shops taking orders every day: daily full backups, and consider more frequent database backups during busy periods.
• Membership sites, forums and booking systems: daily as a minimum, because user data changes constantly.

Whatever the site, always take a fresh backup before updating a CMS, plugins, themes or the PHP version.

What a backup should actually contain

A website backup is a copy of everything needed to rebuild the site on another server. That means two parts:

1. Files: the code, themes, plugins, uploaded images and configuration files such as wp-config.php or configuration.php.
2. The database: usually MySQL or MariaDB, holding your pages, products, orders, users and settings.

Many sites also rely on email accounts, DNS records and cron jobs. A server-level backup in a control panel such as Plesk can capture mailboxes and settings too, which makes a full restore much quicker.

How long to keep backups

Frequency is only half the story. Retention, how long you keep old copies, matters just as much. Hacked sites often carry hidden malware for days or weeks before anyone notices. If you only keep the last two days, every backup may already be infected.

A sensible pattern for a small business is:

• Daily backups kept for at least a couple of weeks.
• Weekly or monthly copies kept for longer.
• At least one copy stored away from the live server, following the 3-2-1 rule: three copies, two types of storage, one off-site.

On dijitul hosting, daily backups are kept for 14 days, so you can go back to any day in the last two weeks. For older snapshots, such as a monthly archive, download a backup from Plesk and keep it on your own storage.

Test your backups

A backup that has never been restored is a hope, not a plan. Problems we often see when people first try a restore include missing databases, partial file sets and backups of the wrong folder.

1. Pick a recent backup.
2. Restore it to a staging copy or a test subdomain, not the live site.
3. Check that pages load, logins work and recent content is there.
4. Write down how long it took, so you know what to expect in an emergency.

Do this a couple of times a year, and after any big change to the site. If your site has been hacked, read what to do when your website is hacked before restoring anything.

Where backups should be stored

A backup stored on the same server as the website protects you from a bad update, but not from a failed disk, a hacked account or a mistake that wipes the whole server. That is why the 3-2-1 rule asks for one copy off-site.

• Server backups: quick to restore, handled by your host.
• Remote backups: copied to separate storage, so a server failure does not take them too.
• Your own copy: an occasional download of files and database that you keep, which also helps if you ever change host.

If a developer or agency set up your site, check that you can reach the backups yourself, not only through them.

How dijitul handles backups

dijitul Complete Hosting includes daily backups kept for 14 days as standard, for £1 a day + VAT. Because it is managed hosting, we watch the server and can restore a site for you if something goes wrong, rather than leaving you to work it out alone. You also have your own Plesk login, so you can take a manual backup before making changes.

Find out more on our website backups page, or order Complete Hosting. If your site is moving from another host, we handle the migration for you.

Related