WordPress Multisite transforms a single WordPress installation into a network of multiple sites, all sharing the same WordPress core, plugins, and themes while maintaining separate content and settings. This architecture creates unique backup challenges—how do you backup an entire network versus individual sites? What about shared vs site-specific data? How do you restore one subsite without affecting others?
This comprehensive guide addresses all aspects of WordPress multisite backups using Backup Copilot Pro. You’ll learn the fundamental differences between network-wide and site-specific backups, understand multisite database architecture, and implement backup strategies that protect your entire network while allowing granular control over individual sites.
By the end of this tutorial, you’ll have a complete multisite backup strategy that protects network admins, subsite owners, and all content across your WordPress network, whether you’re running a small business with 5 sites or an enterprise network with hundreds of subsites.
What You’ll Learn
- Understanding WordPress multisite architecture
- Network-wide vs site-specific backups
- Backing up individual subsites
- Restoring multisite networks
- Multisite backup best practices
- Managing storage for large networks
- Converting single site to multisite
Understanding WordPress Multisite
Multisite Architecture Overview
What is WordPress Multisite: WordPress Multisite is a feature that allows you to create and manage multiple WordPress sites from a single WordPress installation. All sites share:
- WordPress core files (wp-admin, wp-includes)
- Plugins directory (though plugins can be activated per-site)
- Themes directory (though themes can be activated per-site)
- Database instance (with site-specific table prefixes)
Common Multisite Use Cases:
- Corporate networks: Main site + departmental blogs
- Educational institutions: University site + faculty/student blogs
- SaaS platforms: Service site + customer subsites
- Publishing networks: Parent publication + niche topic sites
- Franchise businesses: Corporate site + location-specific sites
Multisite Types:
Subdomain Multisite:
- Main site:
example.com - Subsite 1:
blog.example.com - Subsite 2:
shop.example.com - Requires wildcard DNS setup
Subdirectory Multisite:
- Main site:
example.com - Subsite 1:
example.com/blog/ - Subsite 2:
example.com/shop/ - Easier to set up, no DNS changes needed
Domain Mapping:
- Main site:
company.com - Subsite 1:
brand1.com(mapped) - Subsite 2:
brand2.com(mapped) - Requires domain mapping plugin
Shared vs Site-Specific Data
Understanding what’s shared vs site-specific is critical for backup strategies.
Shared Across All Sites:
- WordPress core files (
/wp-admin/,/wp-includes/) - All plugins in
/wp-content/plugins/ - All themes in
/wp-content/themes/ - Network-level settings and configuration
- Network-activated plugins
- Super Admin accounts
Site-Specific Data:
- Posts, pages, comments (in database)
- Uploaded media files (in
/wp-content/uploads/sites/[site-id]/) - Site-specific settings and options
- Active theme per site
- Activated plugins per site
- Site administrators and users
- Categories, tags, custom taxonomies
Implication for Backups:
- Full network backup includes shared + all site-specific data
- Individual site backup must include shared components for restoration
- Cannot restore single site database without shared tables
Multisite Database Structure
Standard WordPress Tables:
wp_users– All network users (shared)wp_usermeta– User metadata (shared)
Network-Specific Tables:
wp_blogs– List of all sites in networkwp_site– Network configurationwp_sitemeta– Network-wide optionswp_registration_log– New site registrationswp_signups– User/site signup queue
Main Site Tables (Site ID 1):
wp_posts,wp_postmetawp_comments,wp_commentmetawp_terms,wp_term_taxonomy,wp_term_relationshipswp_options- And all other standard WordPress tables
Subsite Tables (Site ID 2, 3, etc.): Each subsite gets its own set of tables with numbered prefix:
wp_2_posts,wp_2_postmetawp_2_comments,wp_2_commentmetawp_2_options- And so on for each site
Example 3-Site Network:
Network tables: wp_blogs, wp_site, wp_sitemeta
Shared tables: wp_users, wp_usermeta
Main site (ID 1): wp_posts, wp_options, etc.
Subsite (ID 2): wp_2_posts, wp_2_options, etc.
Subsite (ID 3): wp_3_posts, wp_3_options, etc.
Total: ~60+ tables for 3 sites
Uploads Directory Structure
Multisite Uploads Organization:
/wp-content/uploads/
├── sites/
│ ├── 2/
│ │ ├── 2025/
│ │ │ ├── 01/
│ │ │ │ ├── image1.jpg
│ │ │ │ └── document.pdf
│ │ │ └── 02/
│ │ └── file-manager/
│ ├── 3/
│ │ ├── 2025/
│ │ │ └── 01/
│ │ │ └── photo.png
│ │ └── woocommerce_uploads/
│ └── 4/
│ └── 2024/
├── 2025/ (main site uploads)
│ └── 01/
└── 2024/ (main site uploads)
Key Points:
- Main site (ID 1): Files in
/uploads/root - Subsites: Files in
/uploads/sites/[site-id]/ - Each site can have plugins with custom upload folders
- Total uploads size = sum of all sites + main site
Backup Strategies for Multisite
Network-Wide Backups
What’s Included:
- Complete database (all network, shared, and site tables)
- All WordPress core files
- All plugins and themes
- All uploads from all sites (main + subsites)
- wp-config.php and .htaccess
When to Use:
- Before WordPress core updates
- Before network-wide plugin updates
- Before major network configuration changes
- For complete disaster recovery
- When migrating entire network to new host
Pros:
- Complete protection of entire network
- One backup for everything
- Simplifies restoration process
- Ensures network consistency
Cons:
- Large file sizes (GB to tens of GB)
- Long backup creation time
- Longer download/upload times to cloud
- Higher storage costs
Recommended Frequency:
- Small networks (2-5 sites): Daily
- Medium networks (6-20 sites): Weekly
- Large networks (21+ sites): Monthly
Site-Specific Backups
What’s Included:
- Site-specific database tables only
- Site-specific uploads folder only
- Optionally: Shared tables needed for restoration
- Optionally: Plugins and themes (shared components)
When to Use:
- Before updating content on specific site
- Before testing plugins on one site
- For client accountability (backup their specific site)
- To restore individual site without affecting others
- To migrate single site out of network
Pros:
- Smaller file sizes (MB to few GB)
- Faster backup creation
- Lower storage costs
- Granular control
- Can restore one site without touching others
Cons:
- Doesn’t include shared components (plugins, themes)
- Need network tables for full restoration
- More complex restoration process
- Potential version mismatches if restoring old subsite backup
Recommended Frequency:
- Active sites: Daily
- Static sites: Weekly
- Development sites: Before major changes
Selective Backup Approach
Recommended Strategy (Best of Both):
Tier 1 – Network-Wide Full Backup:
- Frequency: Weekly (Sunday 2 AM)
- Includes: Everything (database + all files)
- Retention: Last 8 backups (2 months)
- Purpose: Disaster recovery, migration
Tier 2 – Daily Network Database Backup:
- Frequency: Daily (3 AM)
- Includes: Complete database only
- Retention: Last 30 backups (1 month)
- Purpose: Quick content recovery
Tier 3 – Site-Specific Backups:
- Frequency: Before major site changes (manual)
- Includes: Site tables + site uploads
- Retention: Last 5 per site
- Purpose: Individual site rollback
Storage Impact Example (10-site network):
- Network full backup (5 GB): 8 backups = 40 GB
- Network database (100 MB): 30 backups = 3 GB
- Site-specific (200 MB each): 5 per site × 10 sites = 10 GB
- Total: ~53 GB cloud storage needed
Creating Multisite Backups
Backing Up the Entire Network
Using Backup Copilot Pro:
- Navigate to Backup Copilot in Network Admin
- Important: Must be in Network Admin dashboard, not individual site admin
- URL typically:
https://example.com/wp-admin/network/
- Click Create Backup tab
- Select backup components:
- ✅ Database: All network and site tables
- ✅ wp-content: All plugins, themes, uploads (all sites)
- ✅ wp-config.php: Network configuration
- ✅ .htaccess: Multisite rewrites
- Add descriptive note:
- Example: “Full network backup before WP 6.5 update”
- Click Create Backup
- Monitor progress:
- Large networks may take 10-30 minutes
- Progress bar shows current operation
- Don’t close browser until complete
- Verify completion:
- Success message appears
- Backup listed in Manage Backups table
- Check file size is reasonable (several GB for large networks)
What Gets Created:
[uuid].sql– Full database export (~100 MB for 10-site network)[uuid].zip– wp-content + wp-config + .htaccess (~5+ GB for large networks)
Backing Up Individual Sites
Method 1: Using Backup Copilot Pro (If Supported):
- Switch to individual site admin:
- Network Admin > Sites > Click site name > Dashboard
- Or navigate directly to site admin URL
- Go to Backup Copilot (site-level, not network)
- Enable “Site-Specific Backup Mode” if available
- Select components:
- ✅ Site Database Tables: Only tables for this site (
wp_X_*) - ✅ Site Uploads: Only
/uploads/sites/X/folder - ⚠️ Include Shared Tables: Recommended for restoration
- ⚠️ Include Network Tables: Recommended for restoration
- ✅ Site Database Tables: Only tables for this site (
- Create backup as normal
Method 2: Manual Site Export:
If plugin doesn’t support site-specific backups:
Database:
- Access phpMyAdmin
- Select only tables for specific site:
- For site ID 2:
wp_2_posts,wp_2_options, etc. - Plus shared:
wp_users,wp_usermeta - Plus network:
wp_blogs,wp_site,wp_sitemeta
- For site ID 2:
- Export selected tables
Files:
- Use FTP/SFTP
- Download
/wp-content/uploads/sites/2/(for site ID 2) - Optionally download plugins and themes
Method 3: WP-CLI (Advanced):
# Export single site database
wp db export site-2-backup.sql --tables=$(wp db tables --all-tables-with-prefix --format=csv --url=site2.example.com)
# Backup site uploads
tar -czf site-2-uploads.tar.gz wp-content/uploads/sites/2/
What Gets Included
Network-Wide Full Backup Includes:
Database (Complete):
- Network tables:
wp_blogs,wp_site,wp_sitemeta - Shared tables:
wp_users,wp_usermeta - Main site tables:
wp_posts,wp_options, etc. - All subsite tables:
wp_2_posts,wp_3_posts, etc.
Files (Complete):
- WordPress core:
/wp-admin/,/wp-includes/ - All plugins:
/wp-content/plugins/ - All themes:
/wp-content/themes/ - Main site uploads:
/wp-content/uploads/(year folders) - All subsite uploads:
/wp-content/uploads/sites/2/,/sites/3/, etc. - Configuration:
wp-config.php,.htaccess
Site-Specific Backup Should Include:
Minimum (Site Restoration Only):
- Site-specific tables:
wp_X_*where X = site ID - Site-specific uploads:
/wp-content/uploads/sites/X/
Recommended (Standalone Restoration):
- All of above
- Shared tables:
wp_users,wp_usermeta(for user accounts) - Network tables:
wp_blogs,wp_site(for context) - Active plugins and themes (copied from shared directories)
Restoring Multisite Backups
Network Restoration
Full Network Restore Process:
- Preparation:
- Create fresh WordPress installation (if complete rebuild)
- Or use existing network (if rolling back)
- Ensure database access and file permissions
- Restore Database:
- Drop all existing tables (if fresh install)
- Import complete backup SQL file
- Verify table count matches expected
- Check
wp_blogstable shows all sites
- Restore Files:
- Extract backup ZIP to WordPress root
- Overwrites wp-content with all plugins, themes, uploads
- Ensure wp-config.php has correct database credentials
- Verify .htaccess has multisite rewrites
- Network Configuration:
- Update
wp_options>siteurlandhome(for main site) - Update
wp_blogs>domaincolumn if domain changed - Regenerate .htaccess if using permalink structure
- Network activate essential plugins
- Update
- Verification:
- Visit main site – should load correctly
- Visit each subsite – verify content appears
- Test user logins (network admin and site admins)
- Check uploads – images should display
- Verify plugins and themes active correctly
Time Required:
- Small network (2-5 sites): 15-30 minutes
- Medium network (6-20 sites): 30-60 minutes
- Large network (20+ sites): 1-3 hours
Individual Site Restoration
Restoring Single Subsite from Backup:
Scenario: Restore site ID 3 without affecting other sites.
Process:
- Backup Current State First:
- Create fresh network backup before restoration
- Safety net in case restoration goes wrong
- Drop Site-Specific Tables:
- In phpMyAdmin, drop all
wp_3_*tables - Leaves other sites untouched
- In phpMyAdmin, drop all
- Import Site Backup:
- Import SQL file containing
wp_3_*tables - Skip shared and network tables (already exist)
- Or allow overwrites if including shared tables
- Import SQL file containing
- Restore Site Uploads:
- Delete
/wp-content/uploads/sites/3/ - Extract/upload backed up uploads folder
- Delete
- Verify Site ID in Database:
- Check
wp_blogstable has entry for site ID 3 - Domain and path should match expected values
- Check
- Test Restored Site:
- Visit site URL
- Verify content, media, menus display correctly
- Test user logins for that site
- Check other sites still work normally
Challenges:
- Must ensure site ID stays same (critical for uploads path)
- Shared user accounts may conflict if importing
wp_users - Plugin/theme versions may differ from backup time
Restoring to Different Network
Migration Scenario: Extract single site from network, restore as standalone WordPress site.
Steps:
- Prepare Standalone WordPress:
- Install fresh WordPress (single site, not multisite)
- Create database
- Database Preparation:
- Import site-specific tables (
wp_X_*) - Rename tables to remove site ID prefix:
wp_3_posts→wp_postswp_3_options→wp_options- Etc.
- Import user tables (
wp_users,wp_usermeta)
- Import site-specific tables (
- Update Site URLs:
- In
wp_optionstable:- Update
siteurlto new domain - Update
hometo new domain
- Update
- Run search-replace on database for old URLs
- In
- Restore Uploads:
- Extract from
/uploads/sites/X/(multisite structure) - Place in
/uploads/(single site structure)
- Extract from
- Install Plugins and Themes:
- Manually install plugins that were active on subsite
- Install theme that was active
- Verification:
- Site should function as standalone WordPress
- All content, media, users present
Tools to Help:
- WP-CLI for search-replace
- Search Replace DB script
- Backup Copilot Pro’s restore feature (if supports single-site extraction)
Special Considerations
Super Admin Privileges
Backup Permissions:
- Only Super Admins can access network-wide backup functions
- Site Admins may have site-specific backup capability (if enabled)
- Control access via Backup Copilot Pro settings
Security:
- Network backups contain all user data across all sites
- Encrypt backups if storing offsite
- Limit download access to trusted administrators
Domain Mapping
Custom Domains Per Site: If using domain mapping plugin (e.g., brand1.com points to subsite 2):
Backup Considerations:
- Domain mappings stored in database (
wp_domain_mappingor similar) - Must include domain mapping tables in backup
- Document which domains map to which site IDs
Restoration:
- Restore domain mapping plugin
- Re-import domain mapping tables
- Update DNS to point to new server (if migrating)
- Test each custom domain loads correctly
Storage Requirements
Calculating Network Backup Size:
Example 20-site network:
- WordPress core: 50 MB (shared)
- Plugins: 200 MB (shared)
- Themes: 100 MB (shared)
- Main site uploads: 2 GB
- 19 subsites uploads (avg 500 MB each): 9.5 GB
- Database (all sites): 500 MB
- Total: ~12.35 GB per backup
With Retention Policy:
- Weekly full: 8 backups × 12.35 GB = ~99 GB
- Daily database: 30 backups × 500 MB = ~15 GB
- Total storage needed: ~114 GB
Storage Optimization:
- Exclude development/test sites from backups
- Use database-only backups for daily snapshots
- Implement aggressive retention for high-frequency backups
Best Practices
Retention for Large Networks:
- Full backups: 4-8 weeks retention
- Database backups: 30-day retention
- Site-specific: 2-4 weeks retention
- Adjust based on storage budget and compliance needs
Monitoring Network Backups:
- Set up email notifications for backup failures
- Review backup logs weekly
- Monitor cloud storage usage monthly
- Test restoration quarterly on staging network
Testing Subsite Restores:
- Create staging copy of network
- Test restoring individual site backup
- Verify data integrity and functionality
- Document restoration procedure for team
Related Resources
- WordPress Multisite Documentation
- Multisite Database Schema
- Managing WordPress Multisite
- Multisite Best Practices
Managing a WordPress network? Backup Copilot Pro offers full multisite support with site-specific backups, network restoration, and automated scheduling for each subsite!

