Backup frequency gets asked about as if there's a universal correct answer — daily, hourly, weekly — but the only question that actually determines the right frequency is how much work a business can tolerate redoing if the most recent backup is what gets restored. A static five-page brochure site and a store processing orders every few minutes have almost nothing in common on this question, even though both might be using identical backup software. For background on what full, incremental and differential backups actually do mechanically before getting into frequency, see How Website Backups Work.
The real question: how much work can you afford to redo
Every backup has an age at the moment it's needed — the gap between when it was taken and when the restore happens, sometimes called the acceptable data loss window. If backups run nightly at 2am and a server fails at 6pm, restoring means losing everything created or changed between 2am and 6pm: sixteen hours of orders, form submissions, content edits, whatever happened that day. The question worth asking isn't "how often should we back up" in the abstract, it's "how many hours or days of activity can this business recreate or afford to lose, and does our current schedule keep the gap under that number."
What determines the right frequency
A few concrete factors drive the answer more than any general rule: how often content actually changes (a site updated monthly doesn't need daily backups no matter how critical it is, because there's nothing new to lose most days), whether the site processes transactions or user-generated data that can't be recreated from a content source of truth elsewhere, and how costly it would be in staff time to manually recreate a day's worth of activity versus just restoring it. A site where an editor could re-enter a day's missed blog posts in twenty minutes has a very different tolerance than a store where a day of lost orders means lost revenue and confused customers who were charged for something the store has no record of.
Two sites, two different schedules
Consider a WooCommerce store taking orders continuously throughout the day, versus a static brochure site for a local professional services firm that gets edited a few times a month. For the store, a day of lost orders is a day of lost revenue and a support backlog from customers whose payments went through but whose orders vanished — that's a strong case for backups at least every few hours, sometimes more frequently for the database specifically (which changes with every order) even if the file backup, which barely changes day to day, stays on a slower schedule. For the brochure site, a weekly backup likely covers the realistic gap between edits with room to spare — daily backups wouldn't be wrong, but they're solving a problem that site doesn't really have, consuming storage and backup windows for a site where the content is nearly static between infrequent updates. A third case worth naming explicitly: a content-heavy site that publishes frequently but doesn't process transactions, like a news or membership site adding several articles a day. Losing a day of published content isn't the same financial loss as losing a day of orders, but re-creating or re-publishing a day's worth of editorial work is still real, avoidable cost — this profile usually sits between the other two, reasonably served by a daily schedule without needing the multi-hour cadence a transactional store benefits from.
Retention: how many copies to keep, not just how often
Frequency answers "how big is the gap if we need the latest backup," but retention — how many backups are kept before older ones are deleted — answers a different question: "how far back can we reach if the most recent backup turns out to be part of the problem." This matters more than it sounds like it should, because not every incident is discovered immediately. Malware that sat undetected for two weeks, or a bad plugin update that quietly corrupted data days before anyone noticed, means the most recent backup may already contain the problem — restoring from it just restores the issue along with everything else. A retention policy that keeps, for example, the last 7 daily backups plus 4 weekly ones going back a month gives a much better chance of reaching back to a clean state than one that only ever keeps yesterday's copy.
Automating the schedule vs. relying on manual triggers
A schedule that depends on someone remembering to click a button eventually fails, usually at the worst possible time — not because anyone is careless, but because "remember to back this up" quietly loses to whatever's actually urgent that day. Automated, scheduled backups that run without anyone having to initiate them are the baseline for any frequency that matters more than occasionally; manual backups still have a real place, but as a supplement before a specific risky change (a major update, a migration, a bulk data edit), not as the primary mechanism. The distinction matters because the two failure modes are different: an automated schedule can fail silently if nobody's monitoring whether it actually completed, while a manual-only approach fails by simply not happening often enough in the first place. A reasonable setup treats automated backups as the floor and adds a manual one immediately before any change deliberate enough to warrant extra caution, rather than treating either approach as sufficient entirely on its own.
Signs your current backup frequency isn't enough
- A recent restore (real or tested) lost more than a few hours of work that mattered. If the gap between backups and the pace of real changes don't match, that gap is exactly what gets lost.
- Orders, bookings or form submissions happen continuously, but backups run once a day or less. Any transactional data generated between backups is at risk by definition.
- Nobody can say when the last successful backup actually completed. A schedule that isn't being monitored for failures isn't a reliable schedule, regardless of what frequency it's set to.
- Only one backup copy exists at any time. Without retention, a bad backup (corrupted, or taken after an undetected compromise) has nothing older to fall back to.
Setting a schedule in practice
A workable starting point is to separate files and database if the backup system allows it, since they usually don't need the same frequency: the database on an active transactional site often deserves backups every few hours, while the file layer (code, themes, uploaded media) changes far less often and can reasonably run daily. For a low-change brochure or portfolio site, weekly for both is usually sufficient, with the real safeguard being that a human actually triggers a manual backup before any deliberate change — a plugin update, a theme switch, a bulk content edit — rather than trusting the schedule to have caught the moment right before. Whatever frequency gets chosen, it's only a real safeguard once it's been tested: restoring a backup into a staging environment at least occasionally is the only way to know the schedule is producing something usable, not just something that completes without errors. It's also worth revisiting the schedule periodically rather than setting it once and forgetting it — a brochure site that adds an online booking form six months later has quietly become a site with transactional data worth protecting on a tighter schedule, and the backup frequency decided before that change was made no longer reflects what the site actually does.
