How to automate your website backups

A backup that depends on you remembering to run it competes with everything else on your to-do list, and eventually loses. Automation removes the human step entirely, so the backup happens whether or not you thought about it that week. This guide covers three ways to set that up, from simplest to most flexible.

Option 1: your hosting control panel

The simplest option for most sites. The backups section of your control panel typically lets you set a schedule — daily or weekly, depending on what your plan offers — and it takes files and databases together automatically, without you needing to script anything.

Two settings are worth checking once it is running:

• Retention. Decide how many past backups to keep. Keeping every one indefinitely will eventually consume your disk quota, which is a common and avoidable cause of a site running out of space.
• Notifications. If the tool can email you on completion or failure, turn that on. A schedule that has been silently failing for months is worse than having no schedule, because you believe you are covered when you are not.

Option 2: a backup plugin or service

If your site runs on a platform with a backup plugin ecosystem — WordPress being the obvious example — a plugin can run to its own schedule and, importantly, push the result to storage you control rather than leaving it on the account. That off-site push is the main reason to choose a plugin over a control-panel schedule: it satisfies the off-site part of the 3-2-1 rule automatically instead of as a separate manual step. Backing up a WordPress site covers plugin configuration in detail, including the settings people most often get wrong.

Option 3: a cron job, for full control

If you have shell access, a scheduled job gives you the most control and does not depend on any particular plugin being kept up to date. The building blocks are the same commands used for a manual backup, just wrapped in a script and run on a timer.

A simple database backup, compressed and dated, might look like this as a cron entry:

0 2 * * * mysqldump -u dbuser -p'dbpass' dbname | gzip > /home/user/backups/db-$(date +\%F).sql.gz

And the files, once a week:

0 3 * * 0 tar -czf /home/user/backups/files-$(date +\%F).tar.gz /home/user/public_html

Storing a database password directly in a crontab is common but not ideal — a ~/.my.cnf file with restricted permissions, referenced by mysqldump automatically, keeps the password out of a file that is easy to accidentally expose. Setting up a cron job covers the scheduling syntax itself if you have not used cron before, and if you run a VPS, automatic backups on a VPS goes further into server-level scheduling.

Prove the schedule is actually working

An automated backup that has been quietly failing is arguably worse than not having one, because it replaces a known gap with a false sense of security. Once a month or so:

• Check that a new backup file exists with a recent date.
• Check the file size is reasonable compared with previous ones — a file a fraction of the expected size usually means the job stopped early.
• Occasionally restore one, rather than only checking that it exists. Testing that a backup works covers what that check should involve.

Which option to choose

None of these are mutually exclusive, and running two is not wasted effort. A control panel schedule as the simple default, with a plugin or a cron job handling the off-site copy, gives you redundancy in the automation itself — if one method silently breaks, the other is still running.

Automation is a floor, not a ceiling

However good your schedule is, keep taking a manual backup before anything you are doing on purpose — an update, a migration, an edit you are not fully confident about. Backing up before a risky change takes minutes and catches the specific case a nightly schedule is least suited to: a mistake you make between one automated run and the next. If you would like help reviewing a backup schedule on your account, our support team can talk through what your plan supports.