A WordPress backup is a copy of two separate things: the database, which holds your posts, settings, users and orders, and the files, which hold uploads, themes and plugins. A backup missing either one will not restore a working site.
wp-content/uploads/ ← your media, irreplaceable
wp-content/themes/ ← including any customisations
wp-content/plugins/
wp-config.php ← database credentials and saltsWorth knowing: Retention matters as much as frequency. Compromises and content damage are often discovered weeks after they happen, and seven days of backups is no use if the problem started on day nine. Thirty days of daily backups, with monthly copies kept longer, covers the realistic cases.
A backup plugin automates all of the above on a schedule and pushes copies to off-site storage such as S3, Dropbox or Google Drive. That is the right answer for most sites. Configure it to include both database and files, verify the off-site destination is actually receiving them, and check the retention window is long enough to reach a clean copy.
One caveat: Many hosts also take their own backups. Treat those as a convenience rather than your backup strategy: retention is often short, they are stored on the same provider, and you may not be able to restore a single file rather than the whole account.
Backups are easy to configure and easy to leave silently failing. Asking for one before a risky change is the case where you want it confirmed, not assumed.
“Back up all client sites before tonight's plugin updates and confirm each one completed.”
+ 11 sites queued for backup
+ Database + wp-content captured per site
+ Pushed to off-site storage — 11/11 verified
! staging.clientsite.com skipped — excluded from routine
For a change you made deliberately, a snapshot is the faster instrument: reversing one action costs nothing, while restoring a backup costs everything written since. How undo works.
Across a portfolio the failure is rarely that backups were not configured — it is that one site's job has been failing silently for three months and nobody noticed until it was needed. What matters at scale is not running backups but verifying every site actually produced one.
Related: Recovering a hacked site · Support plans and response times
Both the database and the files. The database holds posts, pages, users, settings, comments and WooCommerce orders. The files hold your uploads, themes and plugins. Restoring one without the other gives you a site that loads and is missing everything that matters.
Match it to how much work you are willing to lose. A brochure site updated monthly is fine with weekly backups. A blog publishing several times a week wants daily. A store taking orders continuously needs at least daily, because orders cannot be reconstructed from the front end.
Usually not on their own. Retention is often only a few days, the copies sit with the same provider as the site, and restores are frequently all-or-nothing rather than letting you recover a single file or table. They are a useful second copy, not a strategy.
Restore it. A meaningful share of backup configurations fail on first restore — truncated database exports, excluded uploads directories, plugin data stored in tables the export missed. Restoring to a staging site once a month is the only way to convert a backup from a hope into a fact.
Run and verify backups across your portfolio, and get told which site failed rather than finding out later.
Start free