How often you should back up a WordPress site has a boring honest answer: as often as you would lose real work if the server disappeared tonight. A brochure site updated monthly does not need the same schedule as a WooCommerce store taking orders every hour. This guide turns that principle into a concrete schedule you can defend, plus the restore test that proves the schedule is not just a setting on a screen.
Match The Schedule To How The Site Changes
Start with the site’s own rhythm instead of a generic rule. Count three things: how often content changes (posts, pages, products, orders), how often code changes (plugin updates, theme edits, new forms), and how much an hour of lost data costs. A site publishing twice a week and selling nothing can live with weekly files plus nightly database copies. A store processing thirty orders a day needs the database protected much more often — every few hours or in real time through the host’s replication, with files following daily.
| Site rhythm | Database copies | Full file copies | Why this is enough |
|---|---|---|---|
| Brochure site, updated monthly | Weekly | Before each update and monthly | Content loss is bounded to one month at worst, and updates are the real breakage moment |
| Active blog or booking site, updated weekly | Nightly | Weekly plus before updates | A day of comments, bookings, or form entries is recoverable; files change rarely |
| WooCommerce or membership site | Every 1–4 hours (or host-level replication) | Daily | Orders and member signups are financial records; losing a day is a business problem, not an IT one |
| Site under active rebuild or migration | Before every significant change | Before every significant change | During rebuilds the highest risk is the last change you made, so snapshot at decision points |
How Often Should I Backup My WordPress Site Restore Check Sheet
Use this check sheet after every scheduled restore test. It captures the four facts that make a schedule defensible and exposes the gaps that a plugin dashboard will never show you.
| Check | What to record | Red flag |
|---|---|---|
| Recovery point | Date and time of the newest item that came back | Anything newer exists on the live site than in the backup |
| Recovery time | Minutes from start of restore to a working site | Longer than your business can tolerate, even if the data is complete |
| Manual repairs | Anything fixed by hand after the restore | More than an hour of fixes means the backup is incomplete, not broken |
| Second operator | Someone else repeats the test without help | Only one person can restore — that is a single point of failure |
The check sheet also settles the update-day question. Before every plugin, theme, or core update, take one extra backup and note it in the sheet. If the update breaks something, the decision becomes a two-minute restore instead of an afternoon of debugging. Over a year this habit matters more than the exact interval, because most real-world site losses follow a change someone made, not a random server failure.
Finally, review the schedule itself twice a year. Sites drift: a quiet blog starts taking bookings, a store adds a membership tier, a rebuild moves uploads to separate storage. The rhythm that was right in spring can be quietly wrong by autumn, and the restore check sheet is where that drift shows up first.
The Restore Test Matters More Than The Interval
Whatever schedule you pick, it is only a promise until someone has restored from it. The test does not need drama: spin up a staging copy or a local environment, restore the latest backup into it, and answer four questions. Did everything come back? How long did it take? What had to be fixed by hand? Who else could repeat the test without you? Write the answers down — that record is what turns a backup plugin’s green checkmark into an actual recovery capability.
Most failed recoveries are not missing files. They are a database restored onto the wrong table prefix, an uploads folder that nobody backed up because it lived outside the default path, or a license key for a premium plugin that was never written down anywhere. The restore test surfaces all of these while you still have a working site to compare against.
What To Back Up — And What People Forget
- The database: posts, pages, orders, settings, and user records. For most sites this is the irreplaceable part.
- The uploads folder: everything in
wp-content/uploads. On long-running sites this is often larger than the database and just as irreplaceable. - Plugin and theme files you changed: custom code, template overrides, and must-use plugins. Stock plugins can be re-downloaded; your changes cannot.
- The wp-config.php file and .htaccess/web.config rules: small files that hold credentials, salts, and server rules. Restoring a site without them is a puzzle.
- A record of license keys and external service settings: SMTP, CDN, analytics, and premium plugin keys that a fresh install will ask for.
A backup of only the database, which is the default of many cheap setups, protects your words but not your media or your configuration. Decide consciously what “backup” means for each site and write it into the schedule so nobody assumes.
Where The Copies Should Live
A backup that lives on the same server as the site is not a backup; it is a copy that shares the same fate. Keep at least one copy offsite — a different hosting account, a cloud storage bucket, or the backup provider’s own storage if you trust their retention terms. Keep more than one generation too: three or four recent copies plus one older copy from before the last major update. The older copy is your escape hatch when a problem has been sitting quietly for two weeks and every recent backup already contains it.
Retention can stay simple: daily copies for two weeks, weekly copies for two months, monthly copies for a year. Adjust for the site’s rhythm — stores keep more generations longer — but do not let retention grow unbounded, because restore times slow down and storage costs creep.
A Schedule You Can Defend In One Sentence
The end goal is a sentence you can say out loud: “This site’s database copies itself nightly to offsite storage, files follow weekly, we keep four weeks of generations, and we restored successfully from last week’s copy on staging.” If any clause of that sentence is false, you have found the next task. For the restore-drill side of that claim, the small-site backup schedule walkthrough on this site covers the quarterly routine that keeps the sentence true, and the WordPress developer handbook’s backup guidance documents what core considers worth protecting. For offsite storage choices, the WordPress backups documentation lays out the standard options without vendor bias.
Set the schedule once, prove it with a restore, and then stop thinking about it until the next rhythm change — a sale season, a rebuild, a new editor. That is the whole system.