A backup you have never restored is not a backup. It is a compressed hope.
The purpose of a backup strategy is not to have files somewhere. It is to return a site to a known good state, within a time you can predict, with reasonable confidence that it will work. Almost every failure of a backup strategy is a failure of one of those three clauses, and usually the last one.
Start from two numbers, not from a schedule
Before choosing a frequency, decide two things. They are the standard disaster recovery quantities and they turn a vague preference into a specification.
Recovery point objective (RPO): how much data can you afford to lose? This sets backup frequency. If you back up nightly, your RPO is 24 hours, and you are stating that losing a day of work is acceptable.
Recovery time objective (RTO): how long can the site be down? This sets everything else: where backups are stored, how large they are, whether you have tested the process, and whether the restore path is one click or a support ticket.
Most people pick a frequency first and discover their real RPO during an incident. Doing it in the other order takes ten minutes and changes the answer more often than not.
The reason this matters is that the two numbers pull in different directions and are satisfied by different things. Hourly backups do nothing for RTO. A fast, rehearsed restore does nothing for RPO. A strategy that only addresses one is half a strategy.
What a complete backup contains
The database. All content, settings, users, comments, and most plugin configuration. Typically small, and fast to both back up and restore. This is where the majority of what people mean by "the site" actually lives.
The uploads directory. wp-content/uploads holds media that exists nowhere else. It is usually the bulk of the bytes and the part that cannot be regenerated.
Everything else. Core, plugins, and themes are reproducible: they can be downloaded again at the same versions. Backing them up costs storage and buys speed of recovery.
The common recommendation, and a good default, is database plus uploads, on the reasoning that the rest is replaceable. Two caveats deserve stating, because "replaceable" is doing a lot of work in that sentence.
Custom and commercial code is not replaceable. A bespoke theme, a client-specific plugin, or a paid plugin whose licence has lapsed exists only on that server. If your backup excludes wp-content/themes and wp-content/plugins wholesale, verify that every excluded item can genuinely be re-obtained.
Root drop-ins matter more than their size suggests. wp-config.php, .htaccess, and drop-ins like object-cache.php or advanced-cache.php are small, easy to exclude by accident, and their absence produces a site that restores "successfully" and does not work.
Frequency patterns that hold up
Given an RPO, the patterns that work in practice:
- Daily, retained 30 days. Content sites, brochure sites, most small business sites. Losing a day is annoying, not existential.
- Hourly for 7 days plus daily for 30. Stores and membership sites. Hourly bounds the loss; the daily tier gives you depth to reach past a problem you did not notice immediately.
- Continuous database replication plus daily file backups. High transaction volume or regulated data, where losing an hour of orders is not acceptable.
The depth matters as much as the frequency, and it is the part people under-provision. Ransomware, a slow-burning compromise, and a corrupted import all share a property: you find out days later. A backup set that only reaches back 48 hours contains the problem in every copy.
Incremental backups, and why they change the calculus
A full backup copies everything every time. At any real size that is slow, expensive, and the reason people quietly reduce frequency until the strategy stops meaning anything.
Incremental backups copy only what changed. WPMgr splits file content into chunks addressed by hash and stores each chunk once, so two versions of a file sharing most of their content share most of their storage. The cost of a daily backup approaches the cost of the day's delta rather than the size of the site.
The practical effect is that frequency stops being a budget decision. That is the actual benefit: not the storage saving, but that you no longer have to choose between an acceptable RPO and an acceptable bill.
Offsite is not optional
A backup on the same server as the site is not a backup. Server dies, backup dies. Server is compromised, and any attacker competent enough to matter deletes the backups first, because that is what converts an incident into leverage.
Offsite means a different failure domain: a different provider, or at minimum a different account. The practical options are S3-compatible object storage (S3, Cloudflare R2, Backblaze B2, MinIO), a remote SFTP target, or a NAS you control.
Two properties are worth insisting on. Encryption before the data leaves the site, so the storage provider holds ciphertext rather than your client's customer database. And credentials the site cannot use to delete history: if the WordPress install holds keys with delete permission on the bucket, then anything that compromises the site can erase the backups. Write-only or append-only credentials, or object lock on the bucket, close that path.
WPMgr encrypts on the site before upload, supports S3-compatible and local destinations configured once at the control plane and reused across the fleet, and keeps destination credentials in the control plane rather than on the sites.
Retention, and pruning on purpose
Retention is where storage costs actually live, and where most setups drift into either unbounded growth or accidental shallowness.
A tiered scheme covers the realistic recovery scenarios without keeping everything forever: hourly for a day or two, daily for a month, weekly for a quarter, monthly for a year if you have a compliance reason. Each tier answers a different question, from "undo the last hour" to "what did this look like before the redesign".
The failure to avoid is a retention rule that silently prunes the only copy you needed. If pruning is automatic, know what it deletes and when.
Consistency: the failure nobody looks for
A backup is taken over a period of time, and the site keeps running during it. That gap creates a class of problem that produces backups which restore perfectly and contain nonsense.
Consider a store during a five-minute backup. The database is dumped at the start; an order arrives at minute two, writing rows across several tables; the uploads directory is copied at minute four. Depending on the order of operations you can end up with a database that references an uploaded file the backup does not contain, or an order row in one table with no matching row in another.
Two mitigations matter. Dump the database in a single transaction so it represents one consistent moment rather than a smear across the backup window, which for InnoDB tables is a standard option and costs nothing. And back up the database before the files, so any file referenced by the database is at least as old as the reference, and the worst case is an orphaned file rather than a broken link.
Neither is exotic, and both are the difference between a backup that is internally coherent and one that merely completed.
Large sites need a different shape
Past a certain size the strategy changes rather than just scaling, and the threshold is usually file count rather than gigabytes.
A media library with hundreds of thousands of files makes the per-file overhead dominate: walking the directory tree and hashing takes longer than transferring the data. Sites in this position benefit from excluding uploads from the frequent backup entirely and covering it separately at a lower frequency, on the reasoning that yesterday's uploads are recoverable from a source and yesterday's orders are not.
Very large databases hit the opposite constraint, where the dump itself becomes the slow part and the consistency question above becomes acute.
The general principle: when a backup takes long enough that it overlaps meaningfully with site activity, split it by component and give each the frequency its actual risk deserves, rather than pushing the whole thing to a schedule dictated by its slowest part.
Testing, which is the part that gets skipped
Every backup strategy is a hypothesis until you restore one. The failure modes are numerous and none of them announce themselves: a backup that ran nightly for a year and only ever captured an empty database, an archive that was never completed, a file excluded by a pattern nobody reviewed.
A minimal test:
- Restore a recent backup to a staging environment or a scratch site, not production.
- Load the site and click through the parts that matter: the home page, a post, checkout, a form.
- Check the database has actual rows, not just tables.
- Time it, and write the number down. That is your real RTO, and it is usually longer than people guess.
Quarterly is a reasonable cadence, plus after any change to hosting, backup configuration, or site architecture.
WPMgr restores any stored backup to any site in the fleet, so testing means restoring production's backup onto a staging site rather than building a parallel process you only ever use in a crisis. The mechanism you rehearse is the mechanism you use.
Pre-update snapshots
The single highest-risk moment in a WordPress site's normal life is the minute after an update. It is also entirely predictable, which makes it the easiest risk to cover.
A pre-update snapshot is a backup taken automatically immediately before an update runs, so a broken update becomes a rollback rather than an incident. WPMgr takes one before every update and retains it for a configurable window, defaulting to 14 days.
This is the restore people actually perform. Catastrophes are rare. Plugin updates that break a layout are Tuesday.
For the mechanics of performing one, see restoring a WordPress site in practice. For the feature detail, see the Backups and restore page, and for the wider view the WordPress backups solution guide.