There is no correct frequency, only a consequence. The interval between backups is exactly how much work you will lose in the worst case. Decide what that number is allowed to be and the schedule follows from it.

Ask it out loud

If everything vanished right now and the most recent copy was from last night, what is gone? For a brochure site: nothing. For a shop: today's orders, which means customers who paid and have no record of it.

Reasonable starting points

  • Brochure site, changed monthly - weekly full is generous.
  • Blog or news site - nightly.
  • Shop or booking system - nightly files, database every hour.
  • Anything taking payments continuously - nightly files, database every 15 minutes or continuous log shipping.

Files and database do not need the same schedule

Files change when you deploy. Rows change every minute. Backing them separately means the expensive frequent job is the small one.

# hourly, database only
15 * * * * /usr/bin/mysqldump --single-transaction --quick shop \
  | gzip > /srv/backup/db-$(date +\%H).sql.gz

# nightly, everything
30 2 * * * /usr/local/bin/restic backup /var/www /srv/backup
--single-transaction takes a consistent snapshot of InnoDB without locking the site. Without it a busy shop is locked for the duration of the dump - see exporting without locking the site.

Before every change, as well

A schedule does not cover the update you are about to apply. Take one first - see backup before every update.

More often is only better up to the point where nobody checks that it worked. A nightly backup that is verified beats an hourly one that has been failing silently since March - see reading a failed backup log.