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

A backup that nobody has tested is a promise, not a recovery plan. That distinction gets painfully clear when a WordPress update breaks checkout just before lunch and the only available restore point is yesterday morning.

For a restaurant website, recovery means more than getting the homepage back. You need the menu, customer records, paid orders, delivery details, and kitchen workflow to agree with each other. Here’s how to back up a WordPress site, check that the copy is usable, and restore it without casually wiping out today’s business.

What Should a WordPress Backup Include?

WordPress has two main parts to protect: its database and its files. They work together, but they aren’t interchangeable. Downloading everything through your hosting file manager usually doesn’t export the database.

The database: content, settings, and transactions

The database stores posts, pages, users, and most site settings. On WooCommerce sites, it also holds products, customer information, orders, and other operational records across WordPress and WooCommerce tables. Plugins may create their own tables too.

Picture a pizzeria with photos of every pizza safely copied to a laptop. If its database disappears, those pictures won’t reconstruct prices, topping choices, customer addresses, or paid orders. An uploads folder is not a store backup.

The files: images, code, and configuration

A complete recovery plan should account for uploaded media, installed themes and plugins, custom code, and relevant configuration files. Must-use plugins and files placed outside the usual WordPress directories deserve particular attention.

Some backup tools focus on the database and selected content directories rather than the entire WordPress installation. Don’t assume they include wp-config.php, .htaccess, server configuration, or custom files in the site’s root directory. Standard WordPress core files can be downloaded again, but that doesn’t replace site-specific configuration.

Write down what your backup excludes and how you would recover it. Hosting-level redirects, scheduled server jobs, DNS settings, and email accounts may need separate documentation or backups. Keep configuration copies secure: they can contain database credentials and other secrets.

Choose a Backup Method That Fits Your Website

The best method is the one that meets your recovery needs and can actually be restored by whoever handles an outage. For many small businesses, that means host backups plus an independent off-site copy.

Managed-host backups

Hosting backups are often the easiest recovery route when WordPress won’t load. Depending on your plan, a hosting dashboard may let you restore files, a database, or an entire site without entering WordPress.

Check the details before relying on them. Backups may be included or charged separately, retention varies, and an apparently simple restore may overwrite both files and the database. Ask where copies live, whether you can download them, and whether recovery remains available during an account or server incident.

A WordPress backup plugin

A plugin gives you control inside WordPress and can send copies to independent storage. Entry-level functionality may be free, while advanced destinations, incremental backups, migration tools, or additional scheduling controls may require payment. Remote storage can have its own costs.

The trade-off is that plugin jobs depend partly on your WordPress environment. Server resource limits, broken scheduling, and expired storage authorization can interrupt them. A green settings screen isn’t proof that last night’s backup finished.

Manual database and file exports

You can export the database through a hosting database tool and download files using SFTP or a file manager. This can have little additional software cost, but it demands more time and technical care during restoration.

Manual exports suit occasional snapshots and supplementary copies. They’re a poor primary routine for a busy store, particularly if orders continue arriving while separate database and file copies are being taken.

Daily backups don’t mean continuous protection. A daily snapshot can leave almost a day of changes exposed. Hourly database backups narrow that window; services described as continuous may narrow it further, but you must verify their actual capture intervals and WooCommerce coverage. Keep an independent copy outside the production server—and preferably outside the same hosting account’s control.

[IMAGE: WordPress backup diagram showing database and files copied to hosting recovery storage and a separate off-site account, with daily and hourly recovery points marked]

How to Back Up WordPress Automatically With UpdraftPlus

UpdraftPlus illustrates a common plugin-based workflow: choose backup contents, authorize remote storage, set schedules, and verify an initial run. Labels and available options can vary by installed version and license, so check what your own screen offers rather than assuming every tutorial screenshot applies.

1. Install and open the backup settings

In WordPress, open Plugins → Add New Plugin, search for UpdraftPlus, and verify the plugin identity before installing and activating it. Its settings are normally available under Settings → UpdraftPlus Backups.

Confirm that your hosting account has room for temporary backup archives. Sending backups elsewhere doesn’t eliminate the local disk space needed while those archives are being built.

2. Connect remote storage

Open the plugin’s Settings tab and select a remote destination supported by your installed edition. Follow the destination-specific authentication steps; cloud account connections commonly require saving settings and completing a separate authorization screen.

Use business-controlled storage, not a departing employee’s personal account. Protect that account with multifactor authentication where available, and restrict access to the people responsible for recovery.

The free edition supports scheduled file and database backups and several remote destinations. Some storage integrations, multiple simultaneous destinations, incremental backups, and advanced scheduling controls require paid functionality. Verify the current feature labels before building your backup plan around an option.

3. Select contents and review exclusions

Review the file-backup settings for plugins, themes, uploads, and other directories inside wp-content. Read the exclusions as carefully as the inclusions. Excluding disposable caches is sensible; accidentally excluding uploaded menu images isn’t.

Make sure the database is part of your backup plan. Sites with custom tables or unusual configurations need an explicit coverage check rather than an assumption that everything was captured.

Standard content backups shouldn’t be treated as complete server images. Check how your edition handles WordPress core, root-level configuration, and files outside the normal content directories; arrange a separate secure copy of anything not included.

4. Set schedules and retention

File and database schedules can be configured separately. A mostly static brochure site might use daily database backups and weekly file backups, with extra backups whenever files change. A restaurant taking regular orders needs a shorter database interval.

Retention is usually expressed as a number of backups, not a guarantee of days. Keeping 24 hourly database backups gives roughly one day of history when every run succeeds. Keeping seven daily backups gives roughly a week. Set retention with both recovery history and storage capacity in mind.

5. Create and verify the first backup

Save the settings, then use Backup Now. Include both the database and files, and select the option to send the backup to remote storage when offered.

Wait for completion, inspect the log, and review the resulting backup entry. Large sites may generate several archives for one component. Every required part matters.

Finally, sign in to the remote-storage account independently. Confirm that the expected objects exist with plausible timestamps and sizes. A listing inside WordPress alone doesn’t establish that your off-site copy is accessible. The stronger test comes later: restoring it successfully.

Set a WooCommerce Backup Schedule That Protects New Orders

Backup frequency sets your potential data-loss window. Suppose your database backup finishes at 11:00 a.m., then a failure happens at 1:45 p.m. Restoring that snapshot alone would lose database changes after its recovery point—including lunchtime orders.

Payment providers may still show successful charges. Customers may still have receipts. Neither automatically rebuilds WooCommerce order records or sends missing tickets to the kitchen.

Choose an acceptable loss window first

Start with the operational question: how many minutes of orders could your team realistically reconstruct? Then choose and test a backup approach that can meet that target.

• A menu-only site may be adequately served by daily database backups and file backups after changes.
• A store with occasional orders may need hourly database backups during trading, plus daily file backups.
• A busy restaurant may need database recovery points every few minutes, using a system designed for that frequency and transaction consistency.

These are starting points, not guarantees. Check backup duration and performance under load. Starting a heavy full-site archive every few minutes can create another problem rather than solve the first one.

Cover the whole WooCommerce database

WooCommerce can use legacy post-based order storage or High-Performance Order Storage, usually called HPOS. HPOS uses dedicated order tables, but products, settings, and extension data still live elsewhere. Don’t back up only the tables you recognize as “orders.”

Use complete coverage of the tables belonging to the site, including extension tables, with a method that produces a consistent database snapshot. If you use FoodMaster’s WooCommerce restaurant ordering system for delivery, pickup, or dine-in, include its configuration and verify the ordering and kitchen workflows during recovery tests.

Take an additional database-and-file backup before updates or configuration changes. Keep some older recovery points too: corruption or unauthorized changes might remain unnoticed for days.

Backups contain personal information, including addresses and order histories. Apply access restrictions, secure transfers, and appropriate storage encryption. Set documented retention limits rather than keeping customer data indefinitely “just in case.”

[IMAGE: Restaurant lunchtime recovery timeline showing an 11 a.m. database backup, orders placed afterward, a 1:45 p.m. outage, and the orders requiring reconciliation before reopening]

How to Restore a Backup Without Overwriting Live Orders

The dangerous part of recovery isn’t clicking Restore. It’s deciding which data to replace. An older database can bring a broken site back while removing newer orders, stock changes, refunds, and customer updates.

Rehearse on isolated staging

First restore a known backup into an isolated staging environment. Restrict public access and indexing, and disable customer emails, SMS, outbound webhooks, automatic printing, and other external actions before the restored application runs.

Live payment credentials and scheduled subscription or payment actions need particular care. Block production connections and use sandbox settings where supported. Password protection alone won’t stop a background task from contacting a live service.

Restoring onto a different hostname may also require supported URL replacement or migration handling. Don’t perform a blanket database text replacement: WordPress data can include serialized values that careless editing breaks.

Restore through WordPress when it’s accessible

In UpdraftPlus, locate the required backup under Existing backups and choose Restore. If necessary, use the available options to upload backup archives or rescan connected remote storage. Select the components required and review any warnings.

A files-only restore may be appropriate when the problem is limited to changed files. But older plugin code can be incompatible with a database already changed by an update. Test the combination rather than treating files-only recovery as automatically safe.

If WordPress won’t open, use the host’s recovery tools or obtain qualified assistance. Recovery may involve restoring files and importing the database outside WordPress. Don’t delete the damaged installation before preserving what can still be recovered.

Protect orders before replacing the live database

1. Pause ordering. Stop new checkout activity and coordinate with staff and connected ordering channels. Account for payments already in progress.
2. Preserve the current state. Take a separate database-and-file copy, even if the site is broken. Save accessible order exports and relevant logs as supplementary evidence.
3. Record the recovery window. Note the backup’s recovery point and the time ordering stopped, including the timezone.
4. Reconcile affected transactions. Compare payment-provider records with orders, refunds, kitchen tickets, and delivery records. Have a WooCommerce specialist recover or reconstruct missing records where needed.
5. Test before reopening. Check products, modifiers, taxes, delivery charges, checkout, stock, and order records. Confirm that kitchen routing and printing work without replaying old tickets.

There’s no universally safe “merge my newer orders” button. Orders connect to items, metadata, customers, stock, and extension records. Importing selected database tables can leave those relationships inconsistent.

Never charge a customer again merely because their order disappeared locally. Verify the original transaction first. Reopen ordering only after the restored store and your operational records agree.

Verify Your Backups and Fix Common Failures

A scheduled backup is a task, not an outcome. Someone needs to own the checks—ideally a named person rather than “whoever notices.”

A practical troubleshooting checklist

• Check completion logs. Confirm the latest successful run, not just its start time. Investigate timeouts, database export errors, and upload failures.
• Test remote access. Reauthorize expired connections and check permissions. Confirm you can retrieve backups without depending on the live WordPress site.
• Check available space. Review both hosting disk space and remote quotas. Local temporary archives can fill a server even when the destination has capacity.
• Look for missing parts. Confirm that the database and every required file archive exist. A partial upload is not a complete recovery point.
• Investigate missed schedules. WordPress’s default WP-Cron mechanism is triggered by page requests. Low traffic, disabled cron, or blocked loopback requests can delay jobs; ask your host about reliable server-triggered scheduling.

Repeated failures on a large site may require reduced archive sizes, resource adjustments, or a different backup architecture. Don’t simply increase execution limits indefinitely. Find out whether the bottleneck is database export, archive creation, or remote transfer.

Make restoration part of maintenance

Review backup status at least weekly, with more frequent monitoring for active stores. Run a staging restore periodically—for example, monthly for a busy restaurant—and after significant hosting, storage, or backup configuration changes.

During each rehearsal, keep outbound messages and live payment actions disabled. Check representative older and recent orders, open uploaded images, and run a sandbox checkout. Record how long recovery takes and which steps need clarification.

Before an update, confirm four things: the fresh backup completed, its off-site copy is accessible, all required components are present, and someone knows the rollback procedure. Keep that recovery point separate from routine rotation when possible, and restrict backup access throughout its lifetime.

The goal isn’t a dashboard full of backup dates. It’s a recoverable site, an understood window of potential data loss, and a procedure your team can follow when checkout stops working. Build that procedure before the lunch rush gives it an unplanned test.