WordPress Website Backup: How to Protect and Restore Your Site

The safest plan does more than create a ZIP file. It decides how much recent work the business can afford to lose, stores several protected recovery points away from the live server, and proves that at least one copy can be restored.

For a small brochure site, that may mean an automated daily or weekly backup plus a fresh copy before major changes. A store, membership platform, or busy publication may need much more frequent database protection because orders, accounts, and new content arrive throughout the day.

This guide explains what to include, how to choose a schedule and method, where to store the copies, and how to restore the site without creating a second problem.

What a Complete WordPress Website Backup Contains

A typical WordPress installation has two main layers.

The file system contains WordPress core files, themes, plugins, uploads, custom code, and configuration files. The database holds posts, pages, users, comments, menus, settings, plugin data, and other records used to build the site.

WordPress’s official backup documentation states that both are normally needed for a full restoration. It also recommends treating the files and database created around the same time as one backup set.

Files that need attention

The wp-content directory is usually the most site-specific part of the file system. It commonly contains:

• Uploaded images and documents
• Themes and child themes
• Plugins and must-use plugins
• Language files
• Plugin-created folders
• Custom code stored under wp-content

The site’s wp-config.php and .htaccess files may also be important. WordPress’s file-backup guidance specifically calls out wp-content, wp-config.php, and the WordPress directory.

Core files can often be replaced from a clean WordPress download. A complete server copy may still speed up recovery and preserve site-specific changes that should not have been made to core.

Treat every archive as sensitive. A copied wp-config.php can contain database connection details, while uploads and database exports may contain personal or business information.

Data stored in the database

A WordPress database backup usually includes:

• Posts, pages, and custom post types
• User accounts and roles
• Comments
• Site and plugin settings
• Navigation menus and taxonomies
• Product, order, or membership data
• Plugin-created tables
• Metadata connected to content, users, and other records

The WordPress database-backup guide makes the boundary clear: a database export can protect content and settings, but it does not include themes, plugins, uploads, or wp-config.php.

That is why a database dump and a file archive should share a timestamp or recovery label. If they come from widely different moments, the restored code and stored settings may no longer match.

What the WordPress Export tool does not replace

Tools → Export creates a WordPress eXtended RSS file, usually called WXR. The official Export screen documentation lists content such as posts, pages, comments, custom fields, taxonomies, and users.

That XML file is useful for moving content between WordPress sites. It is not a substitute for a full database dump and file backup. It does not recreate the complete plugin configuration, server files, uploads, or every custom database table required by a complex site.

Set Recovery Goals Before Choosing a Schedule

“Back up regularly” is sound advice, but it does not tell a business what regular should mean.

Two recovery questions make the schedule more concrete.

How much recent data can the site lose?

This is the recovery point question. NIST defines a recovery point objective as the point in time to which data must be recovered after an outage.

If backups run once every 24 hours, a failure just before the next backup could cost almost a full day of changes. That might be tolerable for a site updated twice a month. It may be unacceptable for a store taking orders every few minutes.

How long can the site remain unavailable?

The second question is recovery time. NIST describes the recovery time objective as the period a system can remain in recovery before the outage harms the organization’s work.

A backup stored on an inaccessible account may eventually restore the site, but it does not meet a two-hour recovery need. The team also needs credentials, instructions, available staff, and a tested restoration method.

You do not need a formal enterprise program to use these ideas. Write down two plain-language targets:

• “We can lose no more than four hours of new orders.”
• “We need the store accepting orders again within two hours.”

Those statements help determine frequency, storage, tool choice, and who must be available during an incident.

How Often Should You Back Up a WordPress Site?

Match backup frequency to the rate of meaningful change, not just traffic.

A mostly static company site may need a weekly backup and an extra recovery point before updates or design work. A daily publication usually needs at least daily protection. Stores, learning platforms, communities, and membership sites may need hourly, incremental, or near-real-time database backups.

WordPress gives weekly backups for smaller sites and daily backups for high-activity sites as broad examples. Those are starting points, not universal rules.

Use these events to trigger an additional backup even when an automatic schedule already exists:

• WordPress core, plugin, or theme updates
• PHP or database version changes
• New plugin or theme installation
• Database cleanup or search-and-replace work
• Large content imports
• Site migrations or domain changes
• Major design releases
• Custom-code deployments
• Security remediation

A backup created immediately before a controlled change is easier to identify than “yesterday’s automatic backup.” Give it a clear label that records the date, site, environment, and reason.

Choose a Backup Method You Can Actually Restore

Hosting backups, backup plugins, managed services, and manual copies can all be valid. The strongest choice is the one that meets the site’s recovery goals and remains available when the normal WordPress dashboard does not.

Hosting backups

Host-provided backups can be convenient because the provider controls the server, database, and restore interface. Before relying on them, confirm:

• What is included
• How often backups run
• How many recovery points are retained
• Whether copies are stored outside the production server
• Whether you can download an independent copy
• Whether restores are self-service or require support
• How long a normal restore takes
• Whether restoring one site affects an entire hosting account

A backup owned only by the hosting account can become difficult to reach during an account lockout, billing dispute, or provider outage. Keep at least one copy under separate control.

WordPress backup plugins

A WordPress backup plugin can schedule files and database copies from the dashboard. It may also send archives to remote storage and provide guided restoration.

Evaluate the recovery process, not the number of marketing features. Check whether the plugin:

• Backs up both files and every relevant database table
• Supports the site’s size and hosting limits
• Sends copies off the web server
• Encrypts data in transit and, where supported, at rest
• Provides useful logs and failure alerts
• Offers the retention schedule you need
• Supports multisite or WooCommerce when relevant
• Can restore when the normal admin area is unavailable
• Lets you download the backup in a portable format

Do not run several automatic backup plugins on overlapping schedules. Large archives can consume storage, CPU, and I/O, and competing jobs can fail at the same time.

Manual backups

Manual backups provide direct control and are useful before high-risk work. Files can be copied through SFTP or a trusted hosting file manager, while the database can be exported through the host, phpMyAdmin, or WP-CLI.

For administrators who already use WP-CLI, the documented command below exports the current database:

wp db export

The WP-CLI database reference confirms that wp db export creates a database export and wp db import restores one. These commands do not copy wp-content or other files.

Manual work becomes unreliable when everyone assumes someone else completed it. Record who created the backup, where it is stored, what it contains, and whether it has been tested.

How to Create a Complete WordPress Website Backup

The interface will vary by host or tool, but the underlying process should remain consistent.

1. Confirm access before the maintenance window

Verify that you can reach the hosting account, database, SFTP or SSH service, remote storage, domain settings, and any encryption keys required to read older backups.

Do not wait for an outage to discover that the only recovery code belongs to a former employee.

2. Record the current environment

Note the WordPress version, PHP version, database engine version, active theme, key plugins, domain, and database prefix. Save any host-specific server or rewrite configuration that a standard WordPress archive does not capture.

This small inventory helps when the replacement server is not identical to the original environment.

3. Export the database

Use the host’s backup tool, phpMyAdmin, a maintained backup tool, or WP-CLI. Include all tables used by the installation, not only those beginning with wp_; sites can have a custom prefix, and plugins can add their own tables.

For an active transactional site, use a method designed to produce a consistent backup while the database is changing. A store that accepts orders during a long manual export needs a more careful plan than a static blog.

4. Copy the WordPress files

Capture the WordPress directory or the scope required by your recovery design. At minimum, pay close attention to wp-content, wp-config.php, .htaccess, and any custom files stored outside the standard directories.

Use SFTP instead of unencrypted FTP when the host supports it. Confirm that hidden files are included; otherwise .htaccess can be missed.

5. Pair and label the backup set

WordPress currently recommends backing up the database first and then the files. For restoration, its typical order is files first, then the database.

Store the matching pieces together or use an identical label such as:

example-com-production-2026-10-03-before-plugin-update

Avoid filenames such as final-backup-new.zip. The label should identify the site, environment, time, and reason without exposing passwords or customer data.

6. Move a protected copy away from production

A backup left inside public_html, the media library, or another web-accessible directory can expose sensitive data. It can also disappear with the server it was meant to protect.

Transfer the completed set to approved off-site storage, confirm the upload finished, and remove temporary public copies safely.

7. Verify the result

Check the archive size, file list, database file, timestamp, encryption status, and job log. Automated systems should alert someone when a job fails or no recent backup exists.

Verification confirms that files were created. A restore test confirms that they are useful.

Store WordPress Backups Safely

Multiple copies help only when a single problem cannot destroy all of them.

A practical arrangement may include:

• The production site
• A recent backup in independent cloud or managed storage
• Another protected copy under different credentials or offline control

WordPress recommends several recent recovery points in different locations. For ransomware preparation, CISA advises organizations to maintain offline, encrypted backups and test their availability and integrity.

The word offline matters. A permanently connected drive or storage account that the compromised server can delete is not isolated from the same attack. Immutability or version protection can also prevent an attacker or mistaken automation from overwriting every recovery point.

Protect backup storage as carefully as the live site:

• Use a separate strong password and multifactor authentication
• Limit access to people who need recovery responsibilities
• Encrypt sensitive archives and protect the recovery key separately
• Review access logs when the storage service provides them
• Delete expired copies according to a defined retention policy
• Confirm that business and privacy requirements permit the chosen storage location

Long retention is not automatically safer. Old backups preserve old personal data, credentials, vulnerable code, and outdated configurations. Keep enough history to survive delayed discovery without collecting forgotten archives forever.

Test the Backup With a Restore Drill

A dashboard can report “backup successful” even when the archive is incomplete, corrupted, or impossible for the current team to restore.

Test a representative backup in an isolated staging environment. Do not overwrite the production site simply to prove the backup works.

A useful drill checks whether you can:

1. Locate the correct recovery point without guessing.
2. Decrypt or download every required part.
3. Restore the files and database into a clean environment.
4. Connect WordPress to the restored database.
5. Sign in with an authorized test account.
6. Open public pages and the admin area.
7. Submit important forms and run search.
8. Verify media, redirects, scheduled jobs, and integrations.
9. Complete a test checkout or account workflow where relevant.
10. Record the time and any missing instructions.

Do this after changing backup tools, hosting providers, storage accounts, encryption keys, or critical site architecture. A routine drill also keeps the runbook understandable to someone other than the person who designed it.

How to Restore a WordPress Website Safely

Restoration is not always the first action after a failure. Start by identifying what happened and what the restore will overwrite.

1. Contain the problem

Pause risky changes and prevent new transactions if the site is unstable. For a store, that may require a maintenance or coming-soon mode. Preserve logs and a copy of the current state when security investigation or data reconciliation may be necessary.

2. Choose a known-good recovery point

Match the failure time against backup timestamps, deployment notes, security alerts, and activity logs. The newest backup is not automatically the safest one; it may already contain the broken plugin, malicious file, or unwanted database change.

3. Prepare the target environment

Confirm that the server supports the required PHP and database versions. Create the database and credentials if the restore is going to a new host. Keep the failed site isolated until the recovered copy passes validation.

4. Restore the files

WordPress’s current guidance gives files first as the typical restore order. Place the required WordPress files in the correct document root, preserve file permissions, and avoid mixing a partial new installation with an old archive unless the plan specifically calls for it.

5. Import the database

Import the matching SQL backup through the host’s interface, phpMyAdmin, MySQL/MariaDB tools, or a tested recovery tool. WP-CLI users can import a dump with:

wp db import backup.sql

The WP-CLI import documentation notes that this runs the SQL in the selected file and does not create the database itself. Confirm the destination before running it; an import can replace current data.

6. Reconnect configuration

If database credentials changed, update wp-config.php accordingly. A migration may also require safe URL replacement that understands serialized WordPress data. Do not use a blanket text replacement on an SQL file unless you understand the consequences.

7. Clear caches and refresh site rules

Clear server, page, object, and CDN caches so visitors do not receive a mixture of old and restored assets. Review permalinks and rewrite rules if pages return unexpected 404 responses.

8. Validate before reopening

Check the homepage, representative posts, admin area, media, forms, logins, search, scheduled tasks, redirects, email, analytics, and error logs. Stores should also verify products, cart, checkout, payments, taxes, shipping, order emails, and account pages.

The wider health of the recovered site still matters. Our technical SEO guide explains why availability, crawl access, secure delivery, and performance need to work together after a technical change.

9. Fix the original cause

Do not return the site to production with the same vulnerable plugin, compromised password, broken deployment, or server issue that caused the failure. Apply the correction, rotate affected credentials, and monitor the recovered site.

Restoring After a Security Incident

A backup is a recovery resource, not proof that the copy is clean.

If malicious access began days before discovery, several recent backups may contain the same unwanted code or account. WordPress’s hardening guidance recommends regularly timed snapshots partly because older recovery points can predate a delayed compromise.

Do not delete the current site before preserving evidence that may be needed to understand the intrusion. Identify the entry point, choose a pre-compromise backup, replace compromised code with trusted copies where appropriate, patch the vulnerability, and rotate credentials and security keys.

Restoring the site without closing the entry point can place the same vulnerable version back online. Our WordPress vulnerability coverage explains why installed-version checks and timely remediation belong alongside recovery planning.

For a serious incident involving customer data, regulated information, payment systems, or persistent access, involve qualified security and legal professionals. A general backup guide cannot determine notification or evidence requirements for a specific organization.

WooCommerce and Other Live-Data Sites Need a Different Restore Plan

Restoring a simple content site rolls posts and settings back to an earlier state. Restoring a busy store can also erase legitimate orders, accounts, saved payment information, inventory changes, and scheduled actions created after the backup.

WooCommerce documents this as the gap period between the recovery point and the restore. Its Subscriptions recovery guidance warns that a full rollback can lose orders and customer records from that interval and may cause processed renewal actions to run again.

Before restoring a transactional database:

• Stop or control new transactions
• Preserve a copy of the current database
• Identify orders, users, or subscriptions created after the recovery point
• Decide how those records will be reconciled
• Prevent duplicate scheduled actions or charges
• Test the procedure on an isolated copy
• Use specialist help when payment tokens or subscriptions are involved

WooCommerce also recommends a current backup and staging tests before updates. Its update documentation lists the cart, checkout, payments, shipping, taxes, emails, and extension-specific workflows that should be tested.

A backup tool that works well for a brochure site is not automatically suitable for a store. Ask whether it supports frequent database changes and transaction-preserving recovery.

What a WordPress Backup May Not Include

Even a complete WordPress archive may not recreate every service connected to the site.

Depending on the setup, you may also need separate records or exports for:

• Domain registration and DNS settings
• Email mailboxes and delivery configuration
• CDN, firewall, and edge rules
• Server-level scheduled jobs
• SSL certificate configuration
• Third-party form, CRM, analytics, or payment data
• API credentials and integration settings stored outside WordPress
• Software licenses and vendor account access
• Hosting-specific configuration outside the site directory

Do not place secrets in an unprotected recovery document. Record where authorized staff can retrieve them securely.

This ongoing responsibility is part of the wider platform decision. Our CMS vs WordPress comparison explains how control and maintenance responsibility change across different website setups.

Common WordPress Backup Mistakes

Saving only the files or only the database

The two layers contain different parts of the site. Keep a matching set unless the task is intentionally limited to one component.

Keeping every copy on the live server

Server failure, account loss, or malicious access can remove the site and its backups together.

Confusing an export with a full backup

A WXR content export can support migration, but it does not reproduce the complete database and file system.

Never reading failure alerts

An automatic schedule is not protection when jobs have been failing for weeks. Assign responsibility for checking alerts and backup age.

Retaining only the newest recovery point

The latest copy may contain the same corruption, bad update, or compromise as production. Keep enough history to recover from delayed discovery.

Storing unencrypted customer data carelessly

Backups can contain user profiles, form submissions, orders, and configuration secrets. Restrict access and protect the archive throughout its retention period.

Testing a restore for the first time during an outage

An emergency is the worst moment to discover missing credentials, incomplete files, or undocumented steps.

Restoring production without preserving new data

This is especially dangerous for stores and memberships. A full rollback can replace legitimate activity that occurred after the backup.

A Practical WordPress Backup Routine

Keep the system simple enough that someone will actually maintain it.

On the regular schedule

• Run automated backups at the frequency set by the site’s recovery point goal
• Send at least one copy away from the production environment
• Retain several dated recovery points
• Review alerts and confirm the newest successful backup

Before a major change

• Create a fresh labeled backup
• Confirm that files and database are both included
• Verify access to the storage and recovery method
• Test the change on staging when the site’s risk justifies it

During a periodic review

• Restore a representative copy in an isolated environment
• Measure how long the recovery takes
• Update the runbook and access list
• Review retention, encryption, storage permissions, and costs
• Remove obsolete copies safely when their retention period ends

After a restore

• Test public and administrative workflows
• Reconcile any gap-period data
• Correct the original failure or security issue
• Rotate credentials when exposure is possible
• Monitor logs, errors, scheduled jobs, and user reports
• Create a clean new recovery point after the site is stable

Frequently Asked Questions

What is a WordPress website backup?

It is a recoverable copy of the site’s files and database. The file portion protects themes, plugins, uploads, and configuration, while the database protects content, users, settings, and plugin-created records.

How often should I back up WordPress?

Back up often enough that the maximum likely data loss is acceptable. A low-change site may use weekly or daily backups. Stores, memberships, and busy publications may need hourly, incremental, or near-real-time database protection, plus fresh backups before major changes.

Is my hosting provider’s backup enough?

It can be an important recovery layer, but verify its scope, frequency, retention, restore time, and download options. Keep an independent copy so one provider or account problem does not control every recovery point.

Does the WordPress Export tool create a full backup?

No. It creates a WXR content file containing items such as posts, pages, comments, taxonomies, and users. A full-site recovery normally also needs the database and WordPress files.

Should I use a WordPress backup plugin?

A maintained plugin can automate backups and remote storage. Choose it based on complete coverage, failure alerts, retention, portability, and a tested restore process rather than a long feature list.

Can a backup remove malware from WordPress?

Not by itself. A backup may provide a clean recovery point, but the vulnerability, stolen credential, malicious account, or compromised environment must also be identified and fixed.

How do I know whether a backup works?

Restore it in an isolated environment and test the site. Checking that the archive exists is useful, but only a restore drill proves that the files, database, credentials, and instructions work together.

Can I restore only the database?

Yes, when the problem affects only database data and the existing files are compatible with that recovery point. Importing an older database can overwrite current content, users, orders, and settings, so preserve the present state and confirm the target first.

A Backup Is Useful Only When You Can Recover From It

The strongest WordPress backup plan is easy to describe. Protect the files and database as a matching set, run backups as often as the site changes, retain several recovery points, keep an isolated copy, and test the restore before an emergency.

The details should match the site. A brochure website, a news publication, and a WooCommerce store do not share the same tolerance for data loss or downtime.

Start by writing down how much data the business can lose and how quickly the site must return. Then choose the method, schedule, storage, and people capable of meeting those targets.

A successful job notification tells you that a backup was created. A successful restore drill tells you that the website can recover.