WordPress Backup Strategy: What Small Businesses Should Actually Back Up
Most "backup your WordPress site" guides stop at "install a backup plugin." That part is correct. But it leaves out everything that actually determines whether a backup will save you when something goes wrong: what the backup contains, how often it runs, where the copies go, and whether a restore has ever been tested.
This guide gives you eight decisions to work through as part of a solid WordPress backup plan. It covers files versus database, frequency by site type, off-site storage, restore testing, pre-update backups, and special considerations for WooCommerce stores and booking sites. Work through it once and you will have a backup strategy that fits your actual situation, not a generic recommendation.
Quick Answer
| Decision | Short answer |
|---|---|
| What to back up | Files and database. Both. Every backup. |
| How often | WooCommerce and booking sites: daily minimum. Active blogs: daily. Static brochure sites: weekly. |
| Where to store | Off-site cloud storage: Google Drive, Dropbox, Amazon S3, or Backblaze. Not the same server as your site. |
| How many copies | Keep 2 to 4 restore points. High-volume stores should keep more. |
| Before updates | Manual backup before every major update, before applying. |
| Restore testing | At least once per quarter. Untested backups are assumptions. |
| WooCommerce and bookings | Higher frequency. All order and booking data lives in the database and changes in real time. |
| Host backup vs your backup | Different things. Your host's backup is a secondary safety net, not your primary plan. |
1. Back Up Both Files AND the Database
Why it matters: WordPress has two separate components. Your files contain the code: plugins, themes, uploaded images, and the WordPress core files. Your database contains your content and settings: posts, pages, orders, bookings, user accounts, and plugin configurations.
Neither is complete without the other. A backup that covers only one cannot restore a working site.
What to check:
- Open your backup plugin settings and confirm both database and files are included in every scheduled backup.
- In UpdraftPlus: go to Settings and look at the Files section and Database section. Both should be enabled and running on the same schedule.
- In WPvivid: the default full backup includes both. Confirm "Database" and "Files" are both selected in the backup settings.
- If you have a backup from your host or another source, open the backup archive and verify it contains a
.sqlfile (the database export) and file directories (at minimum/wp-content/).
Red flag:
A backup that contains only a .sql file means you can restore the database but not the plugins, themes, or uploaded media. A backup that contains only files means you lose all content, settings, orders, and user accounts. Both are incomplete.
2. Know What Each Part of Your Backup Contains
Why it matters: Understanding what lives where tells you exactly what you stand to lose if one part of the backup is missing.
What is in your database:
- All posts, pages, and custom post types (including WooCommerce orders and booking records)
- Published and draft content
- Plugin and theme settings
- Site configuration stored in the options table: timezone, site URL, active theme, active plugins, widget settings
- User accounts, roles, and passwords
- Comments
- WooCommerce orders, customers, inventory changes, and cart session data
- Booking plugin appointments, customer records, staff assignments, and service settings
What is in your files:
- Uploaded images, PDFs, and other media (
/wp-content/uploads/) - Installed plugins (
/wp-content/plugins/) - Active theme and child theme files (
/wp-content/themes/) - Any custom code in
mu-pluginsor elsewhere inwp-content/ wp-config.php: the configuration file in your WordPress root containing database credentials and security keys
One file that matters above the rest:
wp-config.php sits in the WordPress root directory, one level above /wp-content/. It holds your database name, username, password, and table prefix. Without it, the restored files cannot connect to the database. A good backup plugin includes wp-config.php automatically. Confirm yours does.
Red flag:
A backup that does not include /wp-content/uploads/ means all images and media files are gone on restore. This is a common gap in misconfigured backups.
3. Set Backup Frequency to Match Your Site Activity
Why it matters: Backup frequency determines how much work or data you lose if something goes wrong. For a static site updated once a month, a weekly backup covers most risks. For a WooCommerce store processing orders every day, a daily backup still means potentially an entire day of orders lost in the worst case.
The decision is simple: how many hours or days of site activity are you comfortable potentially losing?
What to check:
| Site type | Recommended minimum frequency | Reason |
|---|---|---|
| Static brochure or portfolio | Weekly | Content rarely changes |
| Active blog (2+ posts per week) | Daily | New content and media uploads accumulate |
| WooCommerce store (low volume, under 5 orders per day) | Daily | Orders and customer records grow constantly |
| WooCommerce store (higher volume) | Daily or real-time | Significant data loss risk per hour without backup |
| Service site with online bookings | Daily | Appointment data lives in the database and changes with every booking |
| Membership or LMS site | Daily | User progress and course completion records change continuously |
- Set automated schedules in your backup plugin. Do not rely on manual backups.
- If your plugin supports separate schedules for database and files, consider running the database more frequently. The database changes with every order, booking, or published post. Files change only when you add media, update plugins, or edit theme code.
Red flag: A WooCommerce store or active booking site on a weekly backup schedule. An active site where the last confirmed backup is more than 48 hours old.
4. Store Every Backup Off-site
Why it matters: A backup stored on the same server as your WordPress site does not protect you from the most common failure scenarios: server failure, data center incident, hosting account suspension, or a hack that compromises your entire server account. Any of those can make your site and the on-server backup unavailable at the same time.
Off-site means the backup copy lives in a separate system that is not connected to your hosting account or server.
What to check:
- Connect your backup plugin to at least one off-site destination. Common options supported by major backup plugins:
- Google Drive (free tier up to 15 GB; supported by UpdraftPlus free tier and WPvivid free)
- Dropbox (free tier up to 2 GB; supported by UpdraftPlus free tier)
- Amazon S3 (pay-per-storage; supported by most premium plugins)
- Backblaze B2 (lower cost than S3 for large sites; supported by UpdraftPlus premium and others)
- The backup plugin's own managed cloud (BlogVault, Jetpack VaultPress Backup)
- After connecting cloud storage, open your Google Drive or Dropbox account and confirm recent backup files are actually arriving there.
- Keep your backup destination credentials (your Google account, Dropbox account) separate from your WordPress hosting login. If your hosting account is compromised, you do not want the attacker to also access your backups.
Red flag: Backups configured to save only to the local server directory, which is the default in some plugins if you do not connect cloud storage. Or a cloud destination where the last backup file arrived more than 72 hours ago on an active site.
5. Test a Restore Before You Need One
Why it matters: A backup that has never been successfully restored is an assumption, not a safety net. Backup files can be corrupted. Plugins can fail silently mid-backup. Database exports can be incomplete. You will not know any of this until you try to restore.
The goal is to confirm that if something broke tonight, you could have the site running again from your backup.
What to check:
- Schedule a restore test at least once per quarter.
- Use a staging environment for the test, not the live site. Restore the backup to staging, confirm it works, then leave the live site untouched. Most backup plugins include staging tools or one-click staging restore. Many managed WordPress hosts offer staging environments you can use for this purpose.
- After the restore, verify:
- Does the site homepage load correctly?
- Are posts, pages, and images all present?
- If you have WooCommerce: are recent test orders, customer accounts, and product pages visible?
- If you have a booking plugin: are appointments from the last 7 days visible in the admin panel?
- Are plugin and theme settings correct?
- If the restore fails or shows missing content, fix the backup configuration before you rely on it in a real emergency.
Red flag: A restore test that fails, times out, or returns a site with missing database content. A site owner who has never run a restore test and is relying on an untested backup as their recovery plan.
6. Take a Manual Backup Before Every Major Update
Why it matters: Plugin and WordPress core updates are the most predictable risk moment for a WordPress site. A major version update can change database table structures, overwrite customizations, or conflict with another plugin. If something breaks after the update, you need a restore point from immediately before the update, not yesterday's scheduled backup (which may be 12 to 24 hours old).
What to check:
- Before applying a major update (a major version bump, or a plugin with significant changelog items), go to your backup plugin and trigger a manual full backup.
- Wait for the manual backup to complete and confirm it has reached off-site storage before starting the update.
- For minor updates (security patches, point releases), scheduled backups are usually sufficient. If you are applying several plugin updates at once, a pre-update backup is still good practice.
- If you have a staging site: test the update on staging first. Confirm everything works, then apply to production with a pre-update backup in place.
For a step-by-step process for applying updates safely, see how to safely update WordPress plugins without breaking your website.
Red flag: Applying a major update on a WooCommerce store or active booking site with no same-day backup in place. Relying on the previous night's scheduled backup as the only restore point when applying multiple plugin updates.
7. Treat WooCommerce and Booking Data as Higher-Frequency
Why it matters: WooCommerce orders, customer records, and inventory changes are written to the database in real time. So are appointment bookings. Every time a customer places an order or books a service, that data goes into the database immediately. If the last backup was 18 hours ago and something breaks, you have 18 hours of orders and bookings that cannot be recovered.
This is different from a blog post, where losing a few hours of drafts is inconvenient but not a business crisis.
What to check:
- For WooCommerce stores: configure daily database backups at a minimum. For significant order volume (more than 10 to 15 orders per day), consider a plugin or service that supports real-time or hourly database backups.
- For booking-heavy sites: confirm your backup includes all custom tables created by the booking plugin. Booking plugins store appointments, services, staff schedules, and customer data in their own custom database tables. These tables must be included. Most backup plugins include all tables by default. Check your plugin settings to confirm "all database tables" is selected, rather than a whitelist that could exclude custom tables.
- For WooCommerce with HPOS: WooCommerce 7.1 and later introduced High-Performance Order Storage (HPOS), which stores order records in four custom tables:
wp_wc_orders,wp_wc_orders_meta,wp_wc_order_addresses, andwp_wc_order_operational_data(using the standardwp_table prefix; this varies on installations with a custom prefix). These replace the olderwp_posts-based order storage. Order line items continue to use the existingwp_woocommerce_order_itemstable. A backup plugin that is not updated to support HPOS may miss the new order tables entirely. UpdraftPlus (2.23+), WPvivid, and BlogVault each list HPOS support in their documentation. Verify your plugin version supports it. - For WooCommerce Subscriptions or recurring memberships: subscription schedules and renewal records live in the database. These are harder to reconstruct manually than one-time orders. Daily backups are especially important for subscription-based businesses.
Red flag: A WooCommerce store or booking site running on weekly database backups. A backup plugin that allows table exclusions for performance reasons and has inadvertently excluded tables that store booking or order data.
8. Understand What Your Host's Backup Actually Covers
Why it matters: Most managed WordPress hosts and shared hosting plans include automatic backups. This sounds like a complete solution. It is not always one. Host-provided backups come with real limitations that affect how useful they are in practice.
What to check:
- Find out your host's backup retention period. Common windows are 7 days on shared hosting, 14 to 30 days on managed WordPress hosts. If something went wrong 10 days ago and you notice today, a 7-day retention does not cover you.
- Find out how restores work: is it self-service from the control panel, or does it require a support ticket? Support-initiated restores can take hours.
- Find out what the restore covers. Most host restores are full-account restores. They overwrite the current state of the site, including any new content, orders, or bookings added since the backup was taken. You cannot selectively restore one table or one plugin folder without technical help.
- Check whether the host charges for restore assistance. Some shared hosting plans bill for support-initiated restores.
- Confirm whether the host stores backup copies on separate infrastructure from your server, or within the same account environment. A data center incident can affect both.
The conclusion: treat your host's backup as a secondary safety net, not your primary backup plan. Run your own plugin-based, off-site backup independently so you always have a copy you control.
If you need to choose a backup plugin that fits your site type and budget, the best WordPress backup plugins roundup compares the main options with a breakdown by site type.
Red flag: Assuming the host handles everything and running no separate backup process. Or discovering your host's most recent backup is from before a major update or a large order influx, leaving you with no recent clean restore point.
Practical Scenarios
If you run a static brochure or portfolio site
Your content changes infrequently. A weekly automated backup to Google Drive or Dropbox covers most risks. The most important thing is that you have an off-site copy at all. Install a backup plugin, connect cloud storage once, and verify that backups are arriving. Review the destination every few months to confirm the connection is still active and files are landing correctly.
If you run an active blog or content site
Content is your main asset. Daily backups mean you lose at most one day of published posts or drafts in the worst case. Set up a daily database and files backup to cloud storage. If you publish heavily and upload large media files regularly, confirm your cloud destination has enough space. Backup archives are compressed by most plugins, but large media libraries grow over time and will eventually exceed free-tier cloud storage limits.
If you run a WooCommerce store
Daily backups are the floor, not the ceiling. If your store processes more than 10 to 15 orders per day, the financial cost of losing a day of orders likely exceeds the cost of a premium backup plugin that runs more frequently. Confirm your plugin supports WooCommerce HPOS if that feature is active on your store. Run a restore test on a staging copy of your store at least once per quarter. Before sale events or high-traffic promotions, take a manual backup. These are the moments when losing orders costs the most.
If you run a service business with online bookings
Booking data is operationally critical. A missing or lost appointment can mean a no-show with no staff awareness, or a customer who thinks they are confirmed and never receives communication. Daily backups should include the full database. Confirm that custom tables from your booking plugin are included in every backup. Before any booking plugin update, take a manual full backup. Test a restore on a staging copy once per quarter so you know the process works before an emergency forces you to use it.
If you are a freelancer or agency managing client sites
You may be the only person tracking backup status across multiple sites. Each client site should have its own backup destination. Sharing one Google Drive or Dropbox account for multiple clients' backups creates access problems if a client relationship ends. Use a plugin that supports per-site configurations with separate cloud destinations, or a SaaS backup tool with multi-site management. Document the backup setup in a handoff note when a client takes over self-management.
Mistakes to Avoid
- Backing up only files or only the database. A file-only backup has no content. A database-only backup has no theme, plugins, or uploaded media. A working restore needs both.
- Storing the only backup copy on the same server as the site. A server failure or account suspension removes the site and the backup at the same time.
- Assuming the host's automatic backup is enough. Host backups have limited retention periods, often require support involvement to restore, and may not be stored off-site from your server.
- Never testing a restore. A backup that has never been successfully restored is not a recovery plan. It is an assumption that will fail at the worst possible moment.
- Running a WooCommerce or booking site on weekly backups. Every week of orders or appointments not covered is a week of revenue and customer data that cannot be recovered if something goes wrong.
- Forgetting to include wp-config.php. This file holds the database credentials needed to reconnect the restored files to the database. Most backup plugins include it automatically, but verify yours does.
- Relying on manual backups instead of automated ones. Manual backups break down during busy periods, vacations, or when site management is handed off. Automated, scheduled backups with off-site storage are the only reliable approach.
- Not taking a backup before high-traffic events. Product launches, sale campaigns, and seasonal peaks are exactly when losing orders would cost the most. Back up before the event, not after.
Recommended Next Step
Start with one check: open WordPress admin, look at whether a backup plugin is installed, and verify that the most recent backup included both files and database and reached an off-site storage destination.
If no backup plugin is running, or if you are not confident the current setup is complete, the best WordPress backup plugins roundup covers the main options by site type, including free and paid choices with cloud storage support.
If a backup plugin is already configured, the next step is a restore test. Pick a staging environment, restore from the most recent backup, and verify the site loads correctly. Do that once and you will know your backup plan is real, not assumed.
A backup strategy is one part of broader site health. Pair it with your update routine and regular security and content checks. The WordPress website maintenance checklist covers those recurring tasks in a structured weekly, monthly, and quarterly format.