WordPress Multisite Backup: How to Backup and Restore Your Network In 10 Minutes

When managing several sites from one WordPress installation, WordPress site backups need to protect the entire network, not just an individual site.

A reliable WordPress multisite backup gives you a recoverable copy of the shared files and complete database from the same point in time.

This guide explains what to include, how to keep your network backup consistent, and how to prepare it for recovery if an update, security issue, server failure, or user error affects one or more sites. For broader backup principles, see our guide to the best way to back up a WordPress site.

TL;DR: Use a reliable, Multisite-compatible backup plugin to protect the full WordPress installation, database, media library, and network configuration. Store backup copies away from production, then use this WordPress backup and restore checklist to review your recovery process. Restore one subsite when only its data is affected and the plugin supports it. Restore the full network when shared files, network data, or multiple sites are damaged.

What a WordPress Multisite backup includes

WordPress Multisite serves multiple sites from one installation. The sites can share core files, themes, plugins, and network settings, but each site has its own content, settings, database tables, and media path. Subdirectory, subdomain, and domain-mapped networks also depend on URL and server configuration. A complete backup set should include:

The files and database should represent approximately the same point in time. A file archive from Monday and a database export from Friday may not form a consistent restore set. Keep matching copies together and label them with the network name and restore-point date.

🧭 Note: A directory download cannot restore posts, settings, or users. A SQL export cannot restore themes, plugins, uploads, wp-config.php, or server rules. You need both halves of the recovery set.

Choose the right restore scope

Plan for the restore you may need, not only the backup process.

Situation	Preferred recovery scope	Why
One subsite has damaged content or media, while shared components are healthy	Selective subsite restore, if supported	It limits the rollback of healthy sites and newer network work.
Several subsites are affected, or shared files, tables, or configuration are damaged	Full-network restore	The failure crosses the boundary of one site’s data.
You are moving a site or performing advanced data work	Specialist subsite export or migration procedure	A few subsite tables are not automatically a disaster-recovery backup.

A selective restore is not the same as a subsite-only backup. Multisite has shared users and network-level tables as well as each site’s table group. Media, domain mapping, serialized settings, and shared plugins may sit outside the tables you associate with one subsite. Treat a subsite-only database export as an advanced migration or data operation unless the tool documents its dependencies and restore process.

Before restoring WordPress from a backup, create a fresh backup if the network is still accessible, pause changes, and record work created after the restore point. A full-network restore can remove newer work from healthy subsites even when it fixes the original problem.

⚠️ Note: If you can preserve the damaged state, do so before restoring. It may contain information needed to diagnose the failure or recover changes made after the selected restore point.

Backup the network

There are three practical routes. A Multisite-aware service is usually the simplest primary workflow. Host snapshots can provide another layer, and manual SFTP/FTP plus database export can create an independent copy when you have the technical access to manage it.

Use a Multisite-aware backup service

Choose a service that understands the network structure instead of treating each subsite as an unrelated single-site installation. The useful capabilities are scheduled copies, storage away from the live server, full-network coverage, and a documented restore path that does not depend on WordPress admin access. The general setup is:

Exact onboarding screens and button labels change. Follow the current product instructions and verify the network scope and completed first backup instead of relying on an old screenshot.

BlogVault is one option for this workflow. Its current WordPress Multisite backups feature page describes network-level backup for subdirectory and subdomain networks, cloud storage, complete network recovery, and selective subsite restore. Confirm the current plan and dashboard before relying on any specific capability in production. The feature page is not a substitute for a restore drill: verify access, retention, restore permissions, and the recovery scope available to your network.

An external dashboard matters when a server problem also blocks WordPress administration. Keep its login and restore permissions in the organization’s emergency-access process, and make sure at least two responsible administrators know the recovery path.

Use your host’s backups

Host backups may provide automatic snapshots and on-demand restore points, but “the host takes backups” does not tell you whether the whole network is protected. Ask the host:

Same-server snapshots may be affected by the same failure as the live site. A host restore may also restore too much: rolling back the entire network for one damaged subsite can remove healthy work elsewhere. Keep an independent offsite copy when the network’s content or uptime matters.

Backup jobs use database, server, and network resources. The impact depends on the network, method, and timing, so schedule large jobs during quieter periods and monitor the network rather than assuming either zero impact or an unavoidable outage.

⏱️ Note: A quiet schedule reduces contention; it does not fix an incomplete backup. Check the restore set after the job finishes.

Make a manual backup

Manual backup gives you control and an independent recovery copy, but it requires careful handling. For a step-by-step reference, see how to back up WordPress manually; files and the database must be captured separately and kept together.

Copy the complete files

Use SFTP when available because it protects the file-transfer connection. FTP or a host file manager may also be available.

1. Identify the complete WordPress document directory for the network, not a folder belonging to one subsite.
2. Copy core files, wp-config.php, themes, plugins, must-use plugins, uploads, and server rules used by the installation.
3. Preserve the directory structure and mark the archive with the network name and capture time.
4. Move the archive away from the live server and restrict access because it may contain private user data and configuration secrets.

Do not assume that downloading a visible media directory captures every required file. A working network can depend on configuration files, shared plugins, and server rules outside the folder you first notice.

Export the complete database

Use phpMyAdmin for a database small enough for the export to complete reliably. For a large database or to learn more about how to back up a WordPress database, use the host’s database-export tool or a command-line tool such as mysqldump.

1. Identify the database and table prefix in wp-config.php.
2. Export the complete database, including network and per-site tables and shared user data.If you only need specific assets, you can export your WordPress databaseor perform a targeted process to export a WordPress site.
3. Save the export as SQL and verify that it completed instead of ending in a browser timeout.
4. Check the file size and keep the SQL export with the matching file archive.

Do not select only the tables that appear to belong to one subsite unless you are performing a specialist migration with a documented dependency plan. A partial export can omit shared users, network settings, domain data, or other records needed by the restored site.

🧰 Note: Manual export is easier than manual recovery. Restore the files and database to staging before depending on them for production recovery, especially if you are unfamiliar with Multisite’s shared database structure.

Test that the backup can be restored

A completed backup job proves that a process ran. It does not prove that the archive is complete or that the restored network will route visitors correctly. Restore a copy to a WordPress staging environment or another Multisite staging environment; do not overwrite production for the first test. Check:

Record the restore point, checks performed, problems found, and access needed to repeat the test. Have another administrator observe or perform the drill so recovery does not depend on one person’s memory. If the network was hacked, choose a clean restore point and treat malware cleanup, credential changes, and restoration as separate decisions. Restoring an infected backup can return the original problem.

Set frequency and retention

Choose a schedule based on how much recent work the network can afford to lose. A network that changes weekly has a different recovery point objective from one that receives daily orders, form entries, or editorial updates. Increase backup frequency when the cost of losing recent work is high, but make sure the workload is practical for the server and storage system. If you want to follow standard data redundancy frameworks, consider setting up a 3-2-1 backup strategy for WordPress.

Keep enough history to cover delayed problems. The newest restore point may already contain a broken update or an infection, so retaining only one recent copy is risky. Store copies away from production, restrict access, and check that the organization can still reach the backup dashboard or archive. If offsite cloud storage is preferred, you can configure a WordPress backup to Google Drive
or set up a WordPress backup to Dropbox.

Create an extra restore point before:

When the network uses external object storage, domain mapping, a CDN, or a very large database, include those dependencies in the restore plan. A file and database copy may be necessary without being sufficient to reproduce the whole production environment.

WordPress Multisite backup checklist

Before relying on a backup, confirm that:

FAQs

Can I restore only one WordPress Multisite subsite?

Sometimes. A Multisite-aware system may restore one subsite from a complete network backup. That is different from exporting a few subsite tables, which may omit shared users, settings, files, or URL data. Confirm the system’s selective-restore scope and test it before an emergency.

How often should I back up a Multisite network?

Often enough to limit the recent work the organization can afford to lose. Increase the frequency when content or transactions change frequently, and take an extra restore point before network-wide updates, migrations, domain changes, or bulk edits.

What should a WordPress Multisite backup include?

A complete backup should include the WordPress core files, themes, plugins, uploads and media, database, network settings, and configuration files. Because Multisite shares some resources across the network, backing up only one subsite may leave out files or data needed for a full recovery.

Where should I store Multisite backups?

Store backups away from the production server, such as in secure cloud storage or another off-site location. Keep more than one recent copy, restrict access to backup files, and check that your backup plugin has completed each upload successfully.

How can I test a WordPress Multisite backup?

Restore the backup to a staging site or separate test environment and check the network dashboard, subsites, media, users, links, plugins, themes, and domain mapping. A backup is only dependable if you have confirmed that it can restore the parts of the network you may need to recover.

Conclusion

A reliable WordPress Multisite backup is a coordinated recovery set: shared files, every site’s media, the complete database, network configuration, safe storage, useful retention, and a tested restore path. Use a Multisite-aware service for a managed workflow, verify what your host actually stores, and use manual SFTP/FTP plus database export only when you can manage the recovery process.

When one subsite is damaged, choose selective restore if the backup system supports it and the shared network is healthy. When shared files, network data, or several sites are affected, restore the full network. The restore drill is what turns a completed backup into protection you can depend on. If the network is hacked or crashes, MalCare’s WordPress site crash guide is a useful separate recovery checklist.