Every backup system that has ever failed a customer reported success every day until the day it was needed. The report says the file was written. It does not say the file can be read, that it holds what you think, or that restoring it produces a working site.

Test the restore, not the backup

  1. Take the newest archive — Not one you made specially. The point is to test the process that runs unattended.
  2. Restore it somewhere else — A subdomain, a second VPS, a local container. Never over the live site.
  3. Open the restored site — Log in. Load a page that reads the database. Check a recent upload is there.
  4. Note the date of the newest content — That is your real recovery point, and it is often older than the backup schedule suggests.

What a restore usually reveals

  • The database is there but the uploads are not - the backup covered one and not the other.
  • It restores but will not run - a config file with the old server's paths or credentials.
  • The archive is truncated - the disk filled during the backup and nothing checked the exit code.
  • It is encrypted and nobody has the key - the key was on the server that died.
A backup on the same disk as the site is not a backup. It protects against a mistake, not against the disk, the server or the account. At least one copy lives somewhere else.

How often

The honest question is not how often to back up but how much work you are willing to redo. Daily means up to a day of orders gone. If that is unacceptable, daily is the wrong schedule, whatever it costs.

Put a restore test in the calendar, quarterly. It is the only test that proves anything, and the only one nobody does.