Journal / Tutorial
Tutorial

A backup nobody has ever restored from is a hope, not a plan. Here's a setup that covers both halves of the job.
A WordPress site is really two things: the database (posts, pages, settings, comments, product orders — anything stored as text) and the files (theme, plugins, uploaded media). A complete backup needs both. Backing up only the files misses every post and setting; backing up only the database misses every uploaded image.
A daily backup makes sense for a site with an active blog, store, or membership area where losing a day of content is a real loss. A weekly backup is reasonable for a mostly-static brochure site that rarely changes. Match the schedule to your actual publishing cadence, not a default setting.
A backup saved to the same server it's protecting doesn't help if that server fails, gets compromised, or the hosting account is suspended. Point your backup plugin at external storage — cloud storage, a separate remote server, anything not physically on the same box as the live site.
A backup file that has never been restored is an assumption, not a guarantee. At least once, actually run the restore process — ideally onto a staging site or a local environment, not the live site — and confirm the result is a working, browsable copy of your site. This is the only way to catch a corrupted archive, a missing database table, or a misconfigured backup plugin before you need it in an emergency.
Scheduled backups run on a timer, but a major theme update, a plugin change, or a hosting migration deserves its own fresh, manual backup taken immediately beforehand — not "whatever the last scheduled one happened to be."
Back up both the database and the files, store copies somewhere else, and prove the restore works before you actually need it.