How to Back Up a WordPress Website and Restore It Safely (2026)

A backup can finish successfully and still leave you unable to recover the site you actually need. Missing uploads, an excluded orders table, or a backup stored on the same failed server can turn a routine restore into a very long evening.

For a restaurant taking WooCommerce orders, the stakes go beyond a broken homepage. You need customer details, paid orders, menu options, and kitchen workflows back in agreement. Here’s how to back up WordPress in 2026—and recover without creating a second problem.

What a Full WordPress Backup Actually Includes

WordPress has two main parts: its database and its files. A usable full-site backup needs both, captured at a compatible point in time.

The database holds posts, pages, users, settings, and much of your plugins’ information. WooCommerce stores products, orders, customer information, and other operational records there, although the exact tables depend on your configuration and extensions.

Files include WordPress core, themes, plugins, and uploaded images or documents. You also need relevant configuration files, particularly wp-config.php and, on servers that use it, .htaccess. Custom code, must-use plugins, or files outside the standard WordPress folders can easily escape a narrowly configured backup.

A product export isn’t a recovery plan

A WooCommerce product CSV is useful for moving or editing catalog data. It isn’t a complete store backup: it doesn’t capture your entire order history, customer accounts, plugin configuration, theme files, or uploaded image files. Extension-specific product add-ons may also need data that a standard export doesn’t include.

If you use FoodMaster as your WooCommerce restaurant ordering system, protect the whole installation—not just the visible menu. Delivery, pickup, dine-in, QR ordering, and kitchen workflows depend on the store’s underlying data and configuration.

A restore point is a saved state you can recover. A staging site is a separate working copy for testing. Staging may be overwritten or share infrastructure with production, so it’s not automatically an independent backup.

Also check the boundaries: server settings, DNS records, mailboxes, and externally stored media may require separate protection.

Choose a Backup Schedule That Matches Your Website

Start with two questions: how much recent data could you afford to lose, and how long could the site stay offline? These are your recovery point and recovery time targets. A brochure site and a busy takeaway should not have identical answers.

Hosting backups, plugins, or manual copies?

Hosting backups are convenient, especially when support can recover a site without WordPress working. Check what’s included, how frequently backups run, how long they’re retained, and whether restoration costs extra. Ask whether you can download a copy outside the hosting account.

A backup plugin gives you control from WordPress and can send copies to independent storage. But it still depends on server resources, working scheduling, and correct configuration. Manual downloads are useful before significant changes, but they’re too easy to forget as your only protection.

My preference is a hosting recovery option plus an independent off-site backup. Compare the total cost: storage, paid features, restore assistance, and staff time—not just the plugin’s price.

Match frequency to actual activity

A rarely edited brochure site might tolerate daily backups. A restaurant receiving orders throughout the evening may need database recovery points every few minutes, depending on its acceptable loss window. Daily file backups can be sufficient between deployments if uploads and code change less frequently.

Scheduled backups capture particular moments. Incremental backups save changes since an earlier backup, reducing repeated copying. Continuous protection captures changes much more frequently, sometimes through database logs. Incremental doesn’t automatically mean continuous; verify the actual recovery-point interval.

Keep multiple generations—for example, recent daily copies plus older weekly copies—within your storage budget and privacy obligations. One backup can faithfully preserve corruption you haven’t noticed yet.

Off-site storage should survive the loss of your web server. Protect it with restricted access, multifactor authentication where available, encryption, and separate credentials. Keep recovery instructions somewhere accessible even when WordPress is down.

How to Back Up WordPress Automatically with UpdraftPlus

UpdraftPlus provides a dashboard-based way to schedule file and database backups. The following workflow covers a standard installation; labels, supported destinations, and paid entitlements can change, so check the options shown in your installed version.

1. Install and open the backup settings

In WordPress, go to Plugins → Add New Plugin, search for UpdraftPlus, and confirm the plugin’s identity before installing and activating it. Open Settings → UpdraftPlus Backups.

Before starting, check available hosting storage. Backup tools may need local working space while building archives, even when the final destination is remote. A nearly full account is a poor place to discover that requirement.

2. Set separate file and database schedules

Open the Settings tab and choose the file and database schedules. A modest site might use daily database backups and weekly file backups, with an extra full backup before updates.

Choose a database interval that matches your order-loss tolerance. If the available scheduling or your server can’t meet it, this setup alone isn’t enough. Also confirm that WordPress scheduled tasks run reliably; traffic-dependent WP-Cron can run late on quiet sites.

3. Connect remote storage and choose retention

Select a supported remote destination available in your edition, then complete its authorization or credential steps. Save the settings and follow any additional connection prompts. Selecting an icon isn’t the same as completing authentication.

Configure how many scheduled backups to retain for both files and the database. Retention counts and schedule intervals work together: seven hourly database backups provide roughly seven hours of history, not seven days.

[IMAGE: WordPress backup settings showing separate file and database schedules, retention counts, and a connected remote storage destination]

4. Check coverage and run the first backup

Review the file inclusion settings and exclusions. Standard backup components commonly include plugins, themes, uploads, the database, and other content within wp-content. Don’t assume this covers every root-level configuration file, custom directory, or server setting.

Save wp-config.php and relevant server configuration separately if your selected backup scope doesn’t include them. Then choose Backup Now, include both the database and files, and enable sending the backup to remote storage when that option appears.

Wait for completion and read the log. Investigate warnings, skipped files, database errors, or failed uploads. Check the destination itself to confirm the backup arrived, rather than relying exclusively on the dashboard status.

5. Verify WooCommerce tables and archive components

Inspect the backup set for database, plugins, themes, uploads, and any other selected archives. Large components may be split into multiple files; retain every part. Download a copy and inspect the SQL export locally in a protected environment.

Confirm that it contains the site’s actual table prefix and your extensions’ custom tables. With WooCommerce High-Performance Order Storage enabled, verify the presence of tables such as prefix_wc_orders, prefix_wc_order_addresses, prefix_wc_order_operational_data, and prefix_wc_orders_meta, alongside the other WooCommerce tables. Replace “prefix_” with your real prefix.

HPOS order tables alone aren’t a complete store backup. Don’t exclude tables just because their names look unfamiliar; order items, settings, and extension data also matter.

6. Understand the free-version boundary

UpdraftPlus’s free version supports scheduled backups, restoration, and several remote destinations. Features such as incremental backups, additional destinations, advanced scheduling, and expanded file coverage may require paid functionality. Verify current entitlements before building your recovery plan around them.

The decisive check is a successful test restore. An archive’s existence proves that something was saved—not that everything required can be recovered.

How to Make a Manual Backup Before Important Changes

Before a major WooCommerce update, theme replacement, or checkout customization, take a fresh backup. Manual copies provide another recovery route, particularly when you’re changing the backup plugin itself.

Download the website files

Use your hosting file manager or an SFTP connection to locate the correct document root. Dashboard labels vary by host, and an account with several websites may have several similar-looking directories.

Download the entire WordPress installation, including wp-admin, wp-includes, wp-content, and root files. Enable hidden-file visibility so you don’t miss .htaccess. Check whether custom uploads, linked directories, or configuration files live outside that folder and need separate copying.

A host-generated archive can make downloading thousands of files easier. Keep temporary archives outside the public web directory where possible, and delete server-side copies after checking the download.

Export the correct database

Open wp-config.php securely and identify DB_NAME and $table_prefix. If database values come from environment variables, use the hosting configuration to identify them. Don’t paste credentials into support forums or screenshots.

Open phpMyAdmin through your host, select the matching database, and export its relevant tables as SQL, including structure and data. A dedicated database can normally be exported in full. On shared databases, identify the installation’s tables carefully, including custom extension tables.

Store the export and files together with a timestamp and short notes about the site version. Encrypt downloaded customer data, restrict access, and remove unnecessary copies from shared computers.

A busy store needs a consistent recovery point. Downloading files at lunch and exporting orders after dinner isn’t necessarily one. Pause writes where practical, or ask the host for a coordinated snapshot. Database export consistency also depends on table engines and export settings; get technical help when transactions remain active.

How to Restore WordPress and Check That Everything Works

Restoring safely means controlling what happens before and after the restore—not merely clicking a button. Treat recovery as a planned operation, even when the homepage has disappeared and everyone wants an immediate fix.

1. Preserve the current state

Take a copy of the current files and database if possible, even if the site is broken. They may contain newer orders, useful logs, or changes you’ll need to recover later. Don’t overwrite your last usable evidence.

For a suspected compromise, preserve that copy separately and treat it as potentially infected. Choose a restore point from before the incident, then address the entry point and rotate affected credentials. Restoring yesterday’s files without fixing the vulnerability invites a repeat visit.

2. Test the restore in isolation

Use an isolated staging environment with restricted access. Block outgoing customer emails, live payment activity, webhooks, scheduled renewals, and integrations that can write to production systems. Discouraging search engines doesn’t isolate a site.

Restaurant integrations need particular attention. A recovered test order must not print in the real kitchen, appear as a live delivery, or change POS inventory. For FoodMaster installations, include QR table ordering, kitchen display, and automatic printing connections in that isolation review.

[IMAGE: Recovery workflow from preserved live-site copy to isolated staging restore, validation checks, and controlled reopening, with email, payment, and kitchen integration blocks highlighted]

3. Restore the selected backup set

If wp-admin works and you used UpdraftPlus, open its existing backups, select the intended timestamp, and choose Restore. For a full rollback, restore the matching database and file components from that set. Follow the prompts and inspect the restoration log for errors.

A narrowly scoped file restore may avoid rolling back orders when the failure is limited to files. But plugin code and database schemas must remain compatible; don’t assume restoring an older plugin folder reverses its database migration.

If wp-admin is unavailable, contact hosting support about their restore mechanism. Another route is a clean WordPress installation with the backup tool installed and the archives uploaded. Manual recovery requires placing files correctly, importing the database, and checking configuration and permissions.

Tell support you run WooCommerce and need to preserve post-backup transactions before authorizing a database rollback. If restoring to a staging URL, use a migration-aware process for URL changes; plain SQL replacement can corrupt serialized settings.

4. Validate the site before reopening

Check more than the homepage. A restored menu can look perfect while checkout quietly fails.

• Open menu pages, product variations, add-ons, images, and downloadable files on mobile and desktop.
• Test administrator and customer logins, account pages, navigation, and permalinks. Re-save permalink settings if rewrite rules need refreshing.
• Verify delivery areas, pickup slots, opening hours, taxes, fees, coupons, and stock behavior.
• Complete test-mode checkout and inspect the resulting order, payment state, totals, and customer details.
• Check notifications through a controlled mail sink, then verify kitchen and delivery workflows without sending real fulfillment instructions.

Inspect application logs and background-task queues before reconnecting integrations. Pending actions may run when the site returns. Clear relevant caches, confirm HTTPS and production URLs, and reopen only after the live configuration has been reviewed.

Avoid Losing WooCommerce Orders During a Restore

A database restore rewinds your store, not the payment provider. Transactions processed after the backup still exist externally, even if their matching WooCommerce orders disappear.

Imagine a restaurant restores its 5 p.m. backup at 8 p.m. Paid orders placed during those three hours may vanish from WooCommerce, while customers have already received confirmations—or dinner. Refund records, stock adjustments, customer updates, and subscription records can also be rolled back.

The dangerous response is to ask customers to pay again or rerun refunds without checking the provider. First establish what actually happened.

A practical restaurant recovery checklist

1. Pause new orders when necessary. Coordinate with staff and use a clear temporary ordering message. Account for payments already in progress and incoming callbacks; maintenance mode alone may not stop every write.
2. Preserve the current database. Save order exports, logs, and available kitchen or POS records as supporting evidence. Exports supplement the database copy; they don’t replace it.
3. Identify activity since the restore point. Compare payment-provider transaction IDs, timestamps, amounts, refunds, and fulfillment records. Confirm time zones before deciding which transactions belong in the gap.
4. Reconcile with specialist help. Have a WooCommerce specialist recover or reconcile missing records. Blindly importing database rows can create ID collisions, incomplete metadata, HPOS inconsistencies, or duplicate notifications and stock changes.
5. Check money and fulfillment separately. Confirm what was charged, refunded, prepared, delivered, and still owed. Where tips are collected through WooCommerce checkout tipping, include gratuities in the reconciliation rather than checking product totals alone.

Run restore drills on a schedule and after significant hosting, storage, or ordering-system changes. Record how long recovery takes and whether the newest usable backup meets your loss tolerance.

The goal isn’t a green “backup complete” message. It’s getting the website back with the right orders, the right payment records, and a kitchen that knows exactly what to prepare next.