Settings export vs. full backup: what’s the difference

A settings export and a full WordPress backup can both produce downloadable files, but they solve fundamentally different problems.

A settings export is designed to move selected configuration from one installation to another.

A full backup is designed to preserve enough of a website to recover it after data loss, corruption, a failed update, a server problem or another incident.

Confusing the two can create serious problems.

If you rely on a settings export as your only backup, you may discover that it contains none of your:

• posts;
• pages;
• users;
• orders;
• comments;
• plugin data;
• uploaded media;
• themes;
• plugins;
• database tables.

On the other hand, if you use complete site backups whenever you simply want to reproduce a plugin configuration across several WordPress installations, you are moving far more data than necessary.

The distinction becomes especially important for agencies, developers and administrators managing multiple WordPress environments.

The simple rule is:

Use a settings export when you want to reproduce configuration. Use a backup when you need to recover data and application state.

What is a WordPress settings export?

A settings export is a portable representation of selected configuration.

There is no single universal WordPress core format that automatically exports the settings of every plugin, theme and WordPress subsystem. Instead, plugins and tools can provide their own import/export mechanisms for the configuration they manage.

A settings export might contain values such as:

• feature enable or disable states;
• role configuration;
• visibility rules;
• interface preferences;
• security policies;
• media-management settings;
• SEO configuration;
• module-specific options;
• references to assets used by those settings.

Its objective is portability rather than disaster recovery.

A settings export answers a configuration question

Imagine that an agency configures a new WordPress installation with its preferred settings.

The team decides:

• which modules should be enabled;
• which roles should have access to particular functionality;
• how the admin interface should behave;
• which security options should be active;
• how media should be managed.

If another client site needs the same starting configuration, manually repeating every setting is inefficient.

An export can preserve those choices and apply them elsewhere.

This workflow is explored in more detail in Standardizing WordPress Configuration Across Client Sites.

A settings export should usually be selective

A good settings exporter should know exactly what it is exporting.

Dumping every value from the WordPress database would defeat much of the purpose.

Some stored data represents configuration. Other values may represent:

• temporary state;
• logs;
• cache data;
• credentials;
• site identity;
• historical records;
• content;
• runtime information.

A portable configuration tool should distinguish between those categories.

What is a full WordPress backup?

A backup exists for recovery.

The official WordPress backup documentation explains that a typical complete WordPress backup has two major components:

• the WordPress database;
• the WordPress files.

Both matter because they contain different parts of the application.

The database contains dynamic site data

The WordPress database commonly contains:

• posts;
• pages;
• comments;
• users;
• site settings;
• plugin settings;
• post metadata;
• user metadata;
• taxonomy data;
• plugin-generated data;
• WooCommerce orders and related records when applicable;
• other application state stored in database tables.

The official WordPress database backup documentation specifically notes that a database backup does not automatically include WordPress files such as themes, plugins, uploads or wp-config.php.

The file system contains another part of the site

WordPress files can include:

• WordPress core files;
• themes;
• plugins;
• media uploads;
• custom PHP code;
• JavaScript;
• CSS;
• wp-config.php;
• .htaccess;
• other files stored inside the installation.

The official WordPress file-backup documentation therefore treats file backups separately from database backups.

Downloading the WordPress directory usually does not back up the database because the database normally lives in a separate MySQL or MariaDB system.

A complete backup is about reconstruction

The purpose of the backup is to make restoration possible.

If a site disappears tomorrow, a useful recovery set should give you enough information to reconstruct the required state.

That is a fundamentally broader goal than reproducing a collection of configuration settings.

Settings export vs. backup: the core differences

Scope is the main difference

A settings export deliberately has a narrow scope.

A full backup deliberately has a broad scope.

Neither is inherently better. They are optimized for different jobs.

Why a settings export is not a backup

The fact that a settings exporter creates a ZIP, JSON file or another downloadable archive does not make that archive a backup.

It may contain no content

A settings export may recreate how a plugin behaves while containing none of the content that plugin operates on.

For example, an export might preserve a setting saying that a certain role can access a feature.

It does not necessarily contain the users assigned to that role.

It may contain no WordPress files

The export normally does not include:

• plugin PHP files;
• theme files;
• WordPress core;
• the complete uploads directory.

Selected supporting assets can be an exception when an exporter deliberately packages them with the configuration.

It cannot recover deleted database content

If somebody accidentally deletes hundreds of WooCommerce orders, a plugin settings export is not going to recreate those orders.

If a database table becomes corrupted, an export of a few configuration values does not reconstruct that table.

If malware modifies theme files, a configuration export does not restore the original files.

These are backup problems.

Why a full backup is inefficient for simple configuration portability

The opposite mistake also happens.

A developer wants to apply a standard plugin configuration to another site, so they duplicate an entire WordPress installation.

That can work, but it moves much more than the configuration.

A full site copy includes unrelated state

Depending on the backup, you may transfer:

• users;
• posts;
• comments;
• orders;
• media;
• logs;
• database history;
• plugin data;
• credentials;
• client-specific settings.

If the only thing you needed was twenty configuration values, this is a very large hammer for a very small nail.

Site cloning can spread client-specific information

This becomes especially important for agencies.

Using Client A’s production site as the starting point for Client B’s project can accidentally bring along:

• user accounts;
• email addresses;
• analytics identifiers;
• API credentials;
• payment settings;
• private content;
• historical records.

A clean configuration baseline is usually a safer starting point when the objective is standardization rather than duplication.

Credentials illustrate the difference particularly well

Secrets demonstrate why portable configuration and complete recovery data need different security models.

A settings export should generally avoid carrying credentials unless credential transfer is explicitly part of its design.

A full backup, however, may contain sensitive information simply because recovering the application may require restoring the state in which those values existed.

Settings exports should minimize sensitivity

A portable configuration file is likely to be:

• downloaded;
• emailed;
• shared with colleagues;
• stored in project folders;
• imported onto staging sites;
• reused across client installations.

That makes unnecessary secrets especially dangerous.

See Why API Keys Shouldn’t Travel in a Settings Export for a detailed explanation.

Backups should be treated as sensitive archives

A complete database or site backup can contain considerably more sensitive information than a settings export.

Potentially sensitive content includes:

• password hashes;
• customer information;
• email addresses;
• private content;
• configuration values;
• credentials stored by applications;
• server configuration.

Backups therefore need appropriate access control, storage, retention and integrity protection.

The WordPress hardening documentation recommends regular backups and discusses integrity protections for backup data.

When should you use a settings export?

Use a settings export when the thing you want to preserve is configuration rather than the complete state of the website.

Standardizing new client sites

An agency may create a reviewed configuration baseline and import it into every new project.

This can reduce:

• manual setup;
• configuration mistakes;
• inconsistent settings;
• forgotten security options;
• support differences between client installations.

Moving plugin configuration from staging to production

Suppose you spent time configuring a complex plugin on staging.

If the plugin supports safe settings portability, exporting the configuration can be much cleaner than replacing the production database.

This is particularly useful because production may have received new:

• orders;
• comments;
• users;
• form submissions;
• content edits.

Replacing that database merely to move a few settings could destroy legitimate production data.

Creating reusable project profiles

You might maintain different configuration exports for:

• standard business websites;
• WooCommerce installations;
• membership sites;
• editorial projects;
• agency-managed sites.

Each export becomes a starting profile rather than an entire cloned website.

When should you use a full backup?

Use a backup when recovering or protecting actual site state matters.

Before major updates

Before significant WordPress, plugin, theme or infrastructure changes, a restorable backup gives you a recovery point if the change causes problems.

For disaster recovery

If the database is corrupted, a server fails or critical files are deleted, configuration exports are insufficient.

You need the affected data.

Before risky migrations

Migration operations can affect:

• URLs;
• serialized data;
• database contents;
• filesystem paths;
• configuration files.

A backup gives you a recovery point if the migration fails.

For related migration issues, see How to Migrate WordPress URLs Safely and Why Serialized Data Breaks Naive WordPress Migrations.

For rollback after a security incident

Historical backups can also help when determining when a site changed or when rebuilding from a known earlier state.

This is one reason keeping multiple backup generations can be more useful than maintaining only one continually overwritten archive.

Database-only and files-only backups also have different purposes

Not every backup operation needs to be complete.

Sometimes only one part of the site needs protection.

Database-only backup

A database-only backup can be useful before:

• bulk content changes;
• database optimization;
• search-and-replace operations;
• plugin migrations that modify database structures;
• large editorial changes.

But remember that it does not protect files uploaded or modified after the corresponding file backup.

Files-only backup

A files-only backup can protect:

• themes;
• plugins;
• uploads;
• custom code;
• configuration files.

But it does not normally contain the live WordPress database.

Complete backup

For full-site recovery, database and files should normally be treated as one matching recovery set.

The official WordPress documentation recommends thinking of both components together because restoring only one can leave the site in an inconsistent state.

Settings export and backup can work together

The most useful workflow is not choosing one forever.

It is using each tool where it fits.

Example: building a new client site

1. Create a clean WordPress installation.
2. Install the required plugins and theme.
3. Import the agency’s standard configuration.
4. Apply client-specific settings.
5. Configure environment-specific credentials.
6. Create a full backup once the project reaches an important milestone.

The settings export accelerates setup.

The backup protects the resulting site.

Example: changing configuration on production

1. Create a current backup.
2. Test the new configuration on staging.
3. Export the supported settings.
4. Import them into production.
5. Validate the result.

Again, each tool performs a different job.

Example: disaster recovery

If the production database becomes unusable, importing the agency baseline is not enough.

The site may regain preferred plugin settings, but the actual production content is still gone.

A valid backup is what provides the recovery path.

How TheOneWP separates settings portability from backups

TheOneWP treats these as two distinct workflows rather than pretending one archive can conveniently mean everything.

Export Settings is for selected TheOneWP configuration

Export Settings packages supported TheOneWP configuration for import into another installation.

The verified implementation exports eleven explicit TheOneWP option groups rather than dumping the entire WordPress database.

Supported configuration includes areas such as:

• module settings;
• Role Manager rules;
• Access Manager lists;
• supported interface configuration;
• robots.txt configuration;
• other selected TheOneWP settings.

It is therefore a configuration portability tool, not a WordPress disaster-recovery archive.

Referenced local images can move with settings

Some configuration depends on locally uploaded visual assets.

The export can include supported images referenced by its settings.

During import, TheOneWP can add those files to the destination Media Library and update the corresponding URLs.

This does not turn the settings export into a complete media backup.

It only moves the assets required by the supported portable configuration.

Sensitive and runtime data are excluded

The export deliberately excludes categories of data that should not automatically travel with portable configuration, including AI-related credentials and runtime data.

The destination site can then provide its own environment-specific credentials.

Backup Manager is for broader site protection

Backup Manager addresses the separate recovery and migration problem.

Its verified feature set supports:

• complete backups;
• database-only backups;
• files-only backups;
• restore operations;
• migration-oriented workflows;
• scheduled backup automation;
• remote storage workflows;
• optional backup encryption.

This broader scope is what makes it appropriate when actual site recovery is required.

How to choose the right tool

Before creating an export or backup, ask one question:

What problem am I trying to solve?

I want another site to use the same configuration

Use a settings export.

I want to recover this site if something breaks

Use a backup.

I want to preserve posts, users and database content

Use a database backup or complete backup depending on the files you also need.

I want to preserve media, themes and plugins

Use a files backup or complete backup.

I want to create a staging copy

A full migration or site clone may be appropriate because you normally want much of the current site state.

Follow the practices in WordPress Staging Site Best Practices.

I want to configure twenty new client sites consistently

Use a controlled configuration baseline rather than cloning the complete database of an unrelated client site.

Common mistakes

Treating a settings export as disaster recovery

If your export contains only configuration, it cannot restore content it never contained.

Backing up only the database and assuming uploads are included

They normally are not.

Database and files are separate components in a typical WordPress installation.

Backing up only files and assuming posts are included

Posts, users, comments and much application state live in the database.

Using an old client site as a universal template

This can spread client-specific users, credentials and historical data.

Moving production credentials through reusable settings exports

Portable configuration and secrets should generally remain separate.

Creating backups but never testing restoration

A backup that cannot be restored when needed has limited practical value.

Critical backup strategies should therefore include restore testing rather than assuming archive creation equals recoverability.

Keeping the only backup on the same server

If the server itself is lost or compromised, a backup stored only beside the production site may disappear with it.

Important backups should have storage and retention appropriate to the failure scenarios they are meant to protect against.

Settings export vs. backup checklist

• Use settings exports for configuration portability.
• Use backups for recovery.
• Do not expect a settings export to contain posts, users or complete site data unless explicitly documented.
• Remember that a complete WordPress backup normally needs both database and files.
• Do not assume a database backup contains uploaded media.
• Do not assume a file backup contains posts or users.
• Keep secrets out of ordinary reusable configuration exports.
• Treat complete backups as sensitive data.
• Use database-only backups when only database state needs protection.
• Use files-only backups when file state is the relevant concern.
• Create matching database and file backups for complete recovery.
• Use settings exports to standardize client-site configuration.
• Use full backups before risky upgrades or migrations.
• Keep multiple backup generations where the risk model justifies it.
• Store important backups independently from the production environment.
• Test restoration for critical sites.
• Do not clone unrelated client data merely to reuse configuration.
• Review environment-specific credentials after migrations.
• Keep configuration portability and disaster recovery as separate operational processes.

Related guides

• Standardizing WordPress Configuration Across Client Sites
• Why API Keys Shouldn’t Travel in a Settings Export
• WordPress Staging Site Best Practices
• How to Migrate WordPress URLs Safely
• Why Serialized Data Breaks Naive WordPress Migrations
• WordPress Database Bloat Explained
• WordPress File Permissions Explained
• Path Traversal: What It Is and How Plugins Prevent It

Final recommendation

A settings export and a full backup should not compete for the same role in a WordPress workflow.

They are complementary tools.

A settings export answers:

How can I reproduce these configuration choices somewhere else?

A backup answers:

How can I recover this website if its current state is lost or damaged?

That distinction determines what each archive should contain.

A configuration export should ideally remain narrow, portable and free from unnecessary site-specific or sensitive data.

A full backup needs a much broader scope because recovering a typical WordPress site requires both its database and its files.

For agencies, this separation creates a particularly effective workflow: use settings exports to establish consistent client-site baselines, then use backups to protect the unique site that grows from that baseline.

Once configuration portability and recovery are treated as separate operations, both become easier to manage, easier to secure and considerably harder to misuse.