A WordPress multisite network is one install that runs many sites. That sounds simple until you ask what a backup of it has to contain. The answer is bigger than "the database and the files," because the database holds two different kinds of tables and the files folder is split by site. Miss one piece and the restore doesn't fail loudly. It comes back with a network that has forgotten some of its own sites.
This post walks through what's actually in a multisite install, how a per-site backup plugin ends up with a partial copy, and what a complete wordpress backup multisite setup has to capture. At BackupYourSite we take the whole database and the whole site folder over SSH, so we'll also be plain about what that does and doesn't cover.
What makes a multisite backup different from a normal one?
A single-site WordPress install keeps everything in one set of tables with one prefix, usually wp_. Multisite keeps one database too, but it layers two kinds of tables inside it. Some tables belong to the whole network. Others belong to one subsite each.
According to the WordPress VIP documentation on multisite database structure, the network-level tables are wp_blogs, wp_blog_versions, wp_registration_log, wp_signups, wp_site, wp_sitemeta, wp_users and wp_usermeta. That's 8 tables. Every user account on the network lives in just two of them, and the list of which sites exist lives in wp_blogs.
Then each subsite gets its own copy of the content tables, numbered by site ID. Site 2 gets wp_2_posts, wp_2_postmeta, wp_2_options and so on. Site 3 gets wp_3_*. A standard single-site install has 12 core tables, so a network with 10 subsites ends up with roughly 8 shared tables plus about 100 numbered ones, before any plugin adds its own.
Two sentences sum up the risk. Lose the shared tables and WordPress can no longer see any subsite. Lose a numbered set and that one subsite is gone, even though the network looks healthy.
Which files does a multisite backup need besides the database?
The files side is just as split. A complete copy needs the WordPress core files, the network's wp-config.php (which carries the MULTISITE constants), the .htaccess rewrite rules, the themes, and three kinds of plugins: regular, must-use and network-activated. Skip mu-plugins and you can lose behavior nobody remembers installing.
Uploads are where it gets awkward. The main site writes to wp-content/uploads/. Every other subsite writes to wp-content/uploads/sites/2/, .../sites/3/ and so on. A backup that only grabs the main uploads folder looks fine, restores fine, and then every image on site 4 returns a 404. Nothing warns you, because the database rows still point at files that no longer exist.
How does a backup plugin end up with a partial multisite copy?
Most backup plugins run inside WordPress, as PHP, and they inherit WordPress's view of the world. On a single site that's fine. On a network, "the site" is ambiguous. Is the plugin backing up the network, or the subsite whose dashboard you happen to be in?
Plugins answer that in different ways. Some run network-wide only if you network-activate them and pay for the right tier. Some offer per-site backups from each subsite's admin, which means a network of 25 subsites needs 25 schedules, and the shared tables belong to nobody's schedule. Some copy only the tables that carry the current subsite's prefix, which by definition leaves out wp_users, wp_blogs and wp_sitemeta.
The competitor guides we read for this post, including the BlogVault multisite guide, mostly frame this as a feature checklist: does the tool support multisite, yes or no. We think the better question is structural. Does the tool select anything? A tool that selects tables or sites has to be told the correct list, and a list drifts the first time someone adds site number 26.
In our experience the failure shows up late. The backup job reports success for months. The first time anyone checks is the restore, and by then the question isn't how to fix the backup but how to rebuild the network from what's left.
What does a complete multisite restore look like?
It helps to picture the restore, because that's the test a backup has to pass. You've lost the server. You build a fresh one, put the files back, import the database, and load the front page. For a multisite network to come back whole, five things must be true:
- The shared tables are present, so the network knows its sites and users.
- Every numbered table set is present, so each site has posts, options and menus.
- The
wp-config.phpconstants and.htaccessrules match the network type, subdomain or subfolder. - Every
uploads/sites/N/folder is present. - Network-activated plugins and must-use plugins are in the files.
Miss the first and nothing resolves. Miss the second and one subsite is empty. Miss the fourth and the network looks perfect until someone opens an old post. These are three different failures with three different symptoms, which is why a partial backup is so hard to catch by spot-checking the home page.
How does BackupYourSite back up a multisite network?
We don't select. That's the whole answer, and it's a design decision rather than a multisite feature. Our backup engine connects to the server over SSH and does two things. It streams a mysqldump of the entire database, using --single-transaction so the export is consistent without locking the live site. Then it streams a tar of the entire WordPress folder. Both land offsite, and nothing is written to the remote disk first.
We read the database credentials from the site's own wp-config.php. A multisite network has exactly one set of credentials, because it's one database. So the dump contains the 8 shared tables and every numbered subsite set, because the dump command never names a table. It can't forget site 26, because it never had a list of sites.
The files archive works the same way. It's the whole WordPress root, so wp-content/uploads/sites/N/ for every subsite comes along, plus the mu-plugins folder, the network wp-config.php and .htaccess. The only things left out are regenerable caches: wp-content/cache, wp-content/litespeed, wp-content/upgrade, other backup plugins' leftover folders such as ai1wm-backups and updraft, and a few similar paths. None of those carry content.
A fair limit to state: this covers a network whose tables all sit in the single database named in wp-config.php. That's how stock multisite works. If your network has been customized to spread tables across several databases with a plugin like HyperDB, a one-database dump won't see the others. That's rare, and if you run it you already know.
The other limit is access. We need SSH on the account. Shared hosts that block shell access can't be backed up this way. Our post on why a database backup is only half a website covers the files-plus-database pairing in more detail, and the write-up on database exports explains why an export alone falls short.
How we checked this claim before writing it
The methodology was simple, and we'd rather show it than assert it. We read the backup engine's own dump and archive code line by line, looking for any place it names a table, a site ID or a subfolder. The dump command takes one database name and passes it straight to mysqldump, with no table list. The archive step tars one directory and subtracts a fixed list of 8 cache and leftover-backup paths. Nothing in either step knows what a subsite is.
We also compared the engine's behavior with the failure modes in the research sources, including the 8 shared tables and the per-site uploads folders. The absence of selection is what matters. A tool with no selection logic can't pick the wrong tables, and that's a stronger guarantee than a tool that selects correctly today. Our team still recommends a real restore drill, because reading code proves the design and only a restore proves your particular server.
What does a lost network actually cost?
Take a franchise network with 30 location sites. Rebuilding a single subsite by hand, with its pages, menus, forms and 200 or so images, easily eats 4 to 6 hours. Across 30 sites that's up to 180 hours, or more than 4 working weeks, and that's the optimistic case where someone still has the source content. If the shared tables are gone, you also lose every user account and every site mapping, so you're not restoring a network, you're designing a new one.
Compare that with a restore from a complete backup, which on a mid-size network usually takes under 2 hours including DNS checks. The gap between 2 hours and 180 is the real price of a partial backup, and it's paid in a single bad afternoon.
Why does this matter more for agencies than for single-site owners?
Because agencies run networks for other people. A university department with 40 course sites, a franchise with a site per location, a publisher with a site per title: these are the typical multisite clients, and the network owner is rarely the person who can notice a missing subsite. The agency is. If you manage several of these, per-site schedules multiply fast, and so does the number of places a mistake can hide.
One method for every client is easier to defend. That's the argument we make in our guide for agencies selling backup as a service: the same SSH-based process works whether the client is on a single install, a network or a plain PHP app, so there's one runbook and one restore drill.
How do you test a multisite backup before you need it?
Run a restore on a throwaway server and check four things in this order. First, log in to the network admin and count the sites. The number should match what you had. Second, open the Users screen: the same account count. Third, visit one subsite you haven't looked at in months, and open its oldest post with an image. Fourth, check that a network-activated plugin is still active.
That takes about 30 minutes the first time and under 15 after you've done it once. Do it after the first backup, then again whenever you add a subsite or change hosts. A multisite backup you've never restored is a guess.
If you want to see what the engine captures on your own setup, the features page lists the supported hosts and what each backup set contains. Start with the one network you'd least like to lose.
Where to read more
For the table layout, the WordPress developer documentation on multisite is the primary reference: WordPress multisite documentation. The official guide to creating a network explains how subdomain and subfolder networks differ, and the WordPress backup handbook covers the two halves, database and files, that every backup has to include. And WordPress VIP's multisite database structure page is the clearest breakdown of shared versus per-site tables we found.
Frequently Asked Questions
Do I need a special plugin to back up a WordPress multisite network?
Not if the backup happens at the server level. A plugin has to understand the network, and many only back up the subsite you're viewing. A server-level dump of the database plus a copy of the full WordPress folder captures every site without needing to know how many there are.
Which database tables does a multisite network share across all sites?
Eight: wp_blogs, wp_blog_versions, wp_registration_log, wp_signups, wp_site, wp_sitemeta, wp_users and wp_usermeta. Lose them and WordPress no longer knows which subsites exist.
Where does multisite store images for subsites?
The main site uses wp-content/uploads/. Every other subsite uses wp-content/uploads/sites/<ID>/. A backup that skips those folders loses that subsite's images while its posts restore normally.
Does BackupYourSite back up multisite networks?
Yes, as long as we have SSH access to the account. We dump the whole database and archive the whole WordPress folder, so shared tables, every subsite's tables and every subsite's uploads are included. Networks that spread tables over several databases are the exception.
Can I restore just one subsite from a full network backup?
You can, but it's manual work. You pull that subsite's numbered tables and its uploads folder from the full copy and import them into the live network. Keep the full backup intact so you always have both options.