MainWP UpdraftPlus - WordPress Plugin

MainWP UpdraftPlus Guide: Centralized Backups for a Network of WordPress Sites

MainWP UpdraftPlus is not meant to replace UpdraftPlus itself. Its job is to bring UpdraftPlus into your MainWP workflow. In this guide, we'll look at how to prepare the Dashboard and child sites, where to find the right settings, how to run backups safely, how to verify the results, and which issues most often get in the way of centralized backup management.

This guide is intended for anyone managing multiple WordPress sites, running a client site network, or developing across several projects who already understands why backups matter and wants to stop logging into each site one by one. It does not cover buying a license or bypassing activation. The focus here is the practical use of an extension you already have access to and an UpdraftPlus plugin that is already installed.

The core idea is simple: a central dashboard is only useful when every child site is properly prepared. If UpdraftPlus is not installed on one site, external storage is not configured on another, and MainWP sync failed on a third, the unified list becomes misleading. That is why this guide moves from baseline checks to settings, a real-world workflow, troubleshooting, and finally the download decision.

Exact versions and release dates are listed in the sources and notes files. In the guide itself, the working logic matters more: what the administrator should see, which toggles actually matter, when to use global settings, and when to enable an override for a specific site.

What Problem This Extension Solves in a MainWP and UpdraftPlus Setup

UpdraftPlus itself handles backups, restores, and, depending on the version and available modules, migration, extra storage destinations, incremental backups, reporting, encryption, or data anonymization. MainWP UpdraftPlus adds a different layer: the ability to manage those features from the MainWP Dashboard. That matters for a site network where manually logging into each admin area becomes a risk. One site gets overlooked, another has an outdated schedule, and a third stores backups only locally.

MainWP documentation describes the extension as an integration add-on: it is installed on the Dashboard site, while UpdraftPlus itself must be installed and activated on the child sites. Once that is done, MainWP can display sites with UpdraftPlus installed, manage settings, trigger backup and restore actions, define schedules, and open per-site parameters. This is not a cloud service that suddenly starts backing up every site on its own. It is a central control panel that sends commands to already connected child sites.

That leads to one practical rule: if the problem exists inside UpdraftPlus on a child site, for example Google Drive authorization failed, disk space is low, the server interrupts the archiving process, or remote storage is unavailable, MainWP UpdraftPlus does not magically fix it. The extension helps you see the status and jump to the right action faster, but backup reliability still depends on the settings and resources of the individual site.

When Centralized Management Actually Saves Time

MainWP UpdraftPlus shows its real value not on a single blog, but across a group of sites. For example, an agency manages ten client sites and wants to quickly confirm that each project has a recent backup before updating plugins. Without MainWP, the administrator opens each site, goes into UpdraftPlus, starts a backup, waits, checks the log, and repeats the cycle. With MainWP, the workflow changes: the site list and statuses live in the Dashboard, and individual actions are available through the connected interface.

A second useful scenario is when different sites need different policies. A corporate site with infrequent publishing may need file backups less often and database backups more often. An online store or lead-generation site needs a more cautious schedule, a separate pre-update check, and external storage. MainWP UpdraftPlus supports both global settings and per-site parameters through overrides, so you do not have to force every site in the network into one blunt template.

A third scenario is post-change control. After installing UpdraftPlus on child sites, you need to sync MainWP. Otherwise, the Dashboard may not know that the plugin is already active. This step often looks minor, but without it the extension may not show the expected site in the list or offer the right actions. That is why this guide treats synchronization as a required part of installation, not as a formality.

Where MainWP UpdraftPlus Stops Being Responsible

It is important not to assign the extension responsibilities that belong to UpdraftPlus itself or to separate premium add-ons. MainWP documentation clearly separates the layers: the extension manages settings and actions, while the availability of some options depends on the version of UpdraftPlus running on the child site. For example, advanced database table selection, incremental backups, anonymization, or certain premium features only appear when the corresponding version or module is active on the child site itself.

The reliable approach is this: first make sure UpdraftPlus works correctly on each important site locally, then add centralized control through MainWP. That does not slow down rollout. It reduces the number of false problems. If a local backup already runs successfully and uploads to external storage, MainWP becomes a convenient management layer. If the local backup fails, the central dashboard just shows the same symptom somewhere else.

Practical check: before rolling out settings across the network, choose one non-critical child site, create a backup through its regular UpdraftPlus interface, confirm the archive appears in external storage, and then repeat the action through MainWP. That lets you separate an integration issue from a backup-process issue.

Who MainWP UpdraftPlus Is For, and When Another Approach Makes More Sense

MainWP UpdraftPlus works best when you already have a MainWP Dashboard and several connected WordPress sites. If you manage only one site, it is usually simpler to use the standard UpdraftPlus interface inside that site's own admin area. Centralized integration becomes worthwhile when you start repeating the same tasks: identical checks, similar schedules, recurring updates, client reporting, and the need to see backup status in one place.

The extension is especially useful for agencies and administrators who want to standardize maintenance. It helps you avoid keeping everything in your head: which sites have UpdraftPlus installed, which need plugin activation, which need updates, where to open settings, and where to run backup or restore. In that role, the Dashboard becomes an operational log, not just a list of links.

It also fits developers who create safety backups before making changes. If the network contains sites with different levels of business risk, you can define a baseline policy and then separately configure projects with WooCommerce, large media libraries, or stricter retention requirements. A key advantage is being able to jump into site-specific parameters without breaking the overall setup just to handle one exception.

When This Product May Not Be the Right Fit

There are cases where MainWP UpdraftPlus becomes an unnecessary extra layer. If you only have one site, no MainWP Dashboard, and no plan to manage a network, the integration adds more infrastructure than value. If your organization already uses a separate cloud-based site management service with built-in backups, you need to compare not just features, but the responsibility model as well: MainWP remains a self-hosted tool, while many SaaS solutions take over part of the storage and monitoring on their side.

Another case involves sites with strict operational policies where backups are already handled at the hosting, server, or dedicated recovery-system level. In that situation, MainWP UpdraftPlus can still be useful as an extra layer, but it should not disrupt the approved process. For example, if backups must be stored in a specific destination, encrypted, and verified according to a formal procedure, first align UpdraftPlus with that policy, then centralize control.

Finally, the extension will not solve weak hosting. UpdraftPlus documentation directly links some failures to resource shortages, timeouts, archive size, SSL issues, or problems accessing remote storage. If the server cannot build the archive reliably, moving the button into MainWP does not change the underlying reality. In that case, it is better to reduce archive chunk size, exclude heavy folders, run backups during off-peak hours, or talk to the hosting provider about available resources.

A Three-Question Rollout Decision

• Do you have a MainWP Dashboard that syncs reliably with child sites?
• Is UpdraftPlus installed on the sites that need a centralized backup policy?
• Have you tested real backup and restore actions on at least one staging, test, or low-risk site?

If the answer to all three is yes, the integration usually delivers clear value. If not, fix the weak point first: MainWP setup, child-site connectivity, local UpdraftPlus functionality, or external storage.

What to Check Before Installing and Connecting Child Sites

With this product, preparation matters more than polished settings. MainWP UpdraftPlus sits between two systems: the MainWP Dashboard and child WordPress sites running UpdraftPlus. A problem at either layer shows up as an incomplete site list, a missing button, unavailable premium options, a failed backup, or an incorrect schedule.

Start with the Dashboard itself. MainWP recommends using a dedicated WordPress installation for the management panel rather than an active public site. That reduces conflicts with themes, public-facing plugins, and visitor traffic. For a client network, this matters even more: the management panel should be a service site with access restricted to administrators.

Basic Pre-Installation Checklist

• The Dashboard site is stable, child sites are connected, and synchronization completes without errors.
• You have administrator-level access on the child sites and can install or activate plugins.
• UpdraftPlus is installed on the child sites that will be part of the backup workflow.
• An external storage provider has been chosen in advance: Google Drive, Dropbox, Amazon S3-compatible storage, FTP/SFTP, or another supported option.
• Each important site has enough free disk space for temporary archives, especially if the media library is large.
• You know which sites require premium features and which can run on the free version of UpdraftPlus.

This checklist should not turn into bureaucracy. Its purpose is to identify limits before they surface at the worst possible time. For example, if remote storage requires initial authorization on the child site, MainWP can help with ongoing management, but the first authorization still needs to happen wherever the provider requires it.

Why External Storage Is Better Than Local-Only Storage

UpdraftPlus can store backups in several locations, and MainWP documentation specifically notes that some remote storage providers may require initial authorization on the child site. In practice, that means you should not treat a backup as reliable just because it appears in a list. If the archive exists only on the same server that could crash, get compromised, or be wiped by accident, recovery is still vulnerable.

For a typical site, the minimum sensible setup is to send the database and files to external storage while using local disk space only as a temporary working area. For a large site, it also makes sense to review archive chunk sizes, exclusions for cache folders, and how regularly old backups are removed. If retention is not configured, the backup directory can grow until it creates its own storage problem.

How Not to Mix Different Access Layers

MainWP Dashboard has its own permissions and security settings, and UpdraftPlus on the child site has its own. Do not store storage access keys in articles, tasks, or external instructions. If you need S3, Google Drive, Dropbox, or FTP/SFTP, enter secrets only through the site's proper interface or the product's own built-in UI. For an outside writer or contractor, it is enough to say that storage must be configured and verified without handing over any keys.

Reliable preparation is not about a long to-do list. It is about verifying the chain: the Dashboard can see the child site, UpdraftPlus is installed, storage is authorized, a test backup runs successfully, and the archive ends up where it is supposed to.

Installing the Extension and Running the First Sync

Installing MainWP UpdraftPlus has two parts. The extension is installed on the MainWP Dashboard, and UpdraftPlus must be installed on the child sites. This is a common point of confusion: users install the add-on on the Dashboard and expect backups to appear automatically across all sites. But the Dashboard cannot create a backup unless UpdraftPlus is active on the child site.

Step 1. Install the Add-on on the MainWP Dashboard

On the Dashboard site, install the extension as a normal MainWP add-on. In MainWP documentation, the general path for add-on management is MainWP > Add-ons > Manage Add-ons. After installation, the extension should appear in the backup integration group and provide access to the MainWP > Add-ons > UpdraftPlus page. Menu labels may vary slightly depending on the menu structure, but the logic is the same: the extension lives on the Dashboard, not on every child site.

After activation, do not rush straight into running backups. First verify that the Dashboard can see the connected sites, that there are no connection errors, and that the add-ons list opens correctly. If MainWP itself is not syncing properly, UpdraftPlus settings are a secondary concern.

Step 2. Install UpdraftPlus on Child Sites

MainWP documentation offers two paths: install UpdraftPlus through the Dashboard on selected child sites, or log into a specific site and install the plugin through the standard WordPress Plugins > Add New screen. For a network, bulk installation through MainWP is more efficient, but for an initial test it is sometimes better to choose one site and go through the process carefully.

1. Open MainWP > Plugins > Install > Upload if you are installing the ZIP through the Dashboard.
2. Upload the UpdraftPlus archive or install the plugin normally on the child site itself.
3. Select the required child sites and enable activation after installation if that option is available.
4. Wait for the installation to finish and confirm that the plugin is active.
5. Return to the Dashboard and run a MainWP sync.

Syncing after installation is required. MainWP documentation specifically notes that after installing UpdraftPlus, you need to synchronize the sites so the Dashboard can detect the new state. If you skip this step, the site may not appear in the UpdraftPlus list or may look as if the plugin is still inactive.

Step 3. Check the Overview List

Open MainWP > Add-ons > UpdraftPlus > Overview. This page should display the child sites where UpdraftPlus is installed. If the plugin is deactivated, the documentation describes an Activate action appearing in that site's row. If an update is available, you may see an Update action in the same row. These states are useful as a quick audit before you start configuring schedules.

If a site does not appear, do not start with a reinstall. First run synchronization again. Then confirm that the child site is still connected to MainWP, that UpdraftPlus is active on the site itself, and that there are no connection errors. Reinstalling the extension is rarely necessary. More often, the issue is that the Dashboard has not received fresh data yet or the child site is not responding.

Quick takeaway: installation is only complete when the Dashboard can see the required sites in UpdraftPlus Overview and the local UpdraftPlus instance on the child site can create at least one test backup.

Global Settings: Schedules, Backup Contents, and Remote Storage

The settings area is the core of working with MainWP UpdraftPlus. This is where the administrator decides what to back up, how often to do it, where to send archives, and which notifications to receive. The goal is not to enable every possible toggle, but to build a policy that matches the site's actual workload and the value of its data.

MainWP documentation lists the main groups of parameters: file schedule, database schedule, file inclusion and exclusion, database parameters, notifications, remote storage, and advanced debugging options. For the premium version of UpdraftPlus, there is also a separate Use Premium Version toggle that reveals premium-dependent parameters. If a child site is running the free version, you should not expect premium add-on features to appear in the Dashboard.

File and Database Schedules

UpdraftPlus separates file backups from database backups, and that is useful. Site files, including themes, plugins, uploads, and extra directories, can be large, but they do not always change at the same frequency. The database contains posts, settings, orders, leads, comments, and other dynamic data. On a site with infrequent changes, you may back up files and the database on the same schedule. On a store, booking site, or active blog, the database often needs more frequent backups than the file set.

With MainWP UpdraftPlus, schedules are configured centrally, but the frequency should be based on how much loss the site can tolerate. If losing one day of leads is unacceptable, a daily database backup may not be enough. If the site is mostly static, overly frequent full file backups only add load and consume storage. UpdraftPlus documentation supports both manual and scheduled backups, and MainWP documentation shows separate intervals for files and database backups.

Typical Starting Setup

• For a standard informational site: back up the database more often than files, and retain several recent copies.
• For a site with leads or orders: back up the database more frequently, run file backups on schedule, and always create a backup before major changes.
• For a site with a large media library: configure file backups with archive size in mind and exclude temporary directories.
• For a site before migration or a major update: create a manual milestone backup and mark it as important if the relevant retention option is available.

Do not try to force one frequency across every site just to keep the Dashboard tidy. A site network is almost never uniform. One of MainWP UpdraftPlus's strengths is that it lets you combine a shared standard with site-specific exceptions.

What to Include in the Backup

In the Backup Now dialog, MainWP documentation describes the basic toggles: include the database, include files, and send the backup to external storage. Advanced parameters are available through the link next to the database or file options. For files, you can choose the components reported by the child site: plugins, themes, uploads, other directories in wp-content, must-use plugins, and extra paths if configured.

In practice, this helps you avoid backing up junk. Cache folders, temporary exports, heavy logs, old archives, and service directories can dramatically increase backup size. UpdraftPlus supports path exclusions, and wildcards can be used at the beginning or end of an entry. But exclusions need to be handled carefully: you should not exclude any directory the site cannot be restored without. It is safer to begin with clearly temporary folders and then test restore viability in a staging environment.

Database and Premium Table Selection

For premium workflows, MainWP documentation describes database table selection. The key actions there are Select all, Select all (this site), and Deselect all. If multiple WordPress installations share one database, selecting all tables may capture unrelated data. For a normal restore of the current site, it is safer to focus on tables that use that site's prefix unless you have a deliberate reason to include more.

Non-WordPress tables may still appear, but they should not automatically be treated as part of the site. If they belong to a store, an integration, or a custom application, the decision should be documented. If they belong to another project in the same database, including them adds unnecessary risk and increases archive size.

Remote Storage and Initial Authorization

Remote storage is a required part of any serious backup strategy. MainWP documentation warns that due to the security requirements of some providers, the initial authorization may need to happen on the child site itself. After that, some of the ongoing configuration can be handled through the Dashboard. This explains a common situation: the administrator can see remote storage in the settings, but cannot finish the connection centrally until the child site has completed the required authorization.

When configuring storage, do not only check whether the form saved successfully. Create a manual backup, wait for it to complete, open the storage destination, and verify that the files are there. If the site is large, confirm that every archive part was uploaded, not just the database or a single ZIP file. UpdraftPlus troubleshooting documentation includes cases where only part of the backup reached cloud storage, so visual confirmation is more reliable than a single green success message.

Retention and Backups That Should Not Be Auto-Deleted

Retention controls how many copies to keep and when old ones are removed. If retention is too short, you may not notice a problem until the last working copy has already been pushed out. If retention is too long, storage can fill up. In the MainWP dialog for an individual backup, there is an option to mark a copy so it is deleted only manually. This is useful for milestone events: before a major update, migration, theme switch, database cleanup, or site handoff to another contractor.

Retention does not replace restore testing. Even if you have many archives, only a backup you can locate, download, and restore has real value. During routine maintenance, periodically choose one low-risk site and test the restore workflow in a staging environment.

Site-Specific Settings: When to Enable Override General Settings

A global policy is convenient while sites are similar. But MainWP UpdraftPlus is built for a network, and networks almost always include exceptions. MainWP documentation describes the path to site-specific settings through MainWP > Sites: under the child site URL, you can open the UpdraftPlus Backup/Restore link, go to that site's parameters, and enable Override General Settings. Once you do that, the site gets its own settings instead of the shared global scheme.

You should enable site-specific settings not because "it is more flexible," but because you have a concrete reason. For example, a WooCommerce site has a database that changes more frequently than a corporate landing page. A site with a large media library may need different archive splitting and temporary-folder exclusions. A project with its own S3 storage has its own credentials and retention. A staging site may use short retention, while production requires a more conservative policy.

Override Decision Matrix

How to Use Overrides Without Creating Chaos

Before enabling Override General Settings, record the reason. A simple note in your internal documentation is enough: "store, database every few hours," "large uploads, exclude cache," "separate client storage." If no one remembers a month later why a site was pulled out of the standard policy, that override becomes a source of mistakes.

After saving the site-specific settings, run a manual backup for that site specifically. Confirm that MainWP launches the action, UpdraftPlus accepts the parameters, the archive is created, the storage destination receives the files, and the schedule appears as expected. If you only changed the settings form and never verified the result, the override has not proven itself yet.

The Use Premium Version Toggle

If the child site uses the premium version of UpdraftPlus, MainWP documentation recommends setting Use Premium Version to YES so that premium options become visible. The important thing here is not to confuse the interface with licensing: this toggle does not turn a free installation into a premium one. It simply tells the extension to display and use the parameters that are already available on a site with premium functionality.

If the expected parameters still do not appear after enabling premium mode, check the child site itself: is the correct version of UpdraftPlus active, are the required add-ons installed, has MainWP synchronization completed, and are there any update failures or admin-side conflicts? Do not include license secrets in the article or internal instructions. It is enough to note that premium features depend on the plugin state on the child site.

Backup Now and Restore: A Manual Workflow Before Updates

Manual backup is the best way to confirm that the whole chain is working. Even if you plan to rely on automatic schedules, the first useful test should be manual: pick a site, run Backup Now, review the parameters, wait for completion, and make sure the backup can actually be found. In MainWP UpdraftPlus, this is especially valuable before bulk WordPress, theme, or plugin updates.

Goal of This Practical Example

Imagine you need to update plugins safely on a client site. The goal is to create a fresh backup of both the database and files, send it to external storage, confirm that the archive completed successfully, and only then move on to the update. We are not testing licensing, purchasing, or migration here. We are validating a normal operational workflow that an administrator repeats before risky changes.

Preparation

• The child site is connected to MainWP and syncs correctly.
• UpdraftPlus is installed and active on the child site.
• Remote storage is already authorized, or you understand why the backup is temporarily staying local.
• The server has enough free space for temporary archives.
• You know which components need to be included: database, files, or both.

Steps in MainWP

1. Open MainWP > Sites > Manage Sites.
2. Find the required site and go to its actions or edit screen.
3. Open the UpdraftPlus tab or the UpdraftPlus Backup/Restore link.
4. On the status tab, click Backup Now.
5. Leave Include your database in the backup and Include your files in the backup enabled if you need a full snapshot.
6. Enable sending to remote storage if the destination is configured and available.
7. Expand additional parameters only when needed: file exclusions, table selection, separate storage destinations, milestone retention.
8. Start the backup and wait for the process to finish.

If the goal is only to save the database before a content change, you can temporarily exclude files. If the goal is a theme or plugin update, it is better to include both files and the database. On large sites, do not change too many parameters in the first test. First get a standard backup working, then optimize exclusions and archive chunk size.

Verifying the Result

After the backup completes, open the backup history or storage destination and verify the actual files. A full backup usually includes separate parts for the database, uploads, themes, plugins, and other components if they were included. If you expected the backup to reach remote storage but the files remain local only, the setup is not finished.

Success criteria: MainWP shows a completed backup, UpdraftPlus on the child site shows a fresh backup set, external storage contains all expected archive parts, and the log does not contain fatal errors, timeouts, or low-space warnings.

When to Use Restore

The Restore button should not be treated like a casual interface check. Restore is an action with consequences. It can replace files, the database, or individual site components. For that reason, on a production site it is safer to test restoration first on a copy, in a staging environment, or in a separate installation. UpdraftPlus documentation explains restore through component selection, and MainWP lets you reach restore from the site's tab, but the decision to run it should be deliberate.

Before starting a restore, confirm that you selected the correct backup set, that you understand what the archive contains, and that you still have access to the Dashboard even if the restore fails. If the site is business-critical, create a fresh backup of the current state before rolling back. That may sound excessive, but sometimes you need to return not only to the old state, but also to the state immediately before the failed restore attempt.

Backup Schedules and Controlling Data Freshness

An automatic schedule is only useful if you can verify it. MainWP UpdraftPlus lets you define file and database schedules through Extension Settings and then review status on the Scheduled Backups tab. MainWP documentation also points to the Reload Data button for fetching fresh data from selected sites. That matters: the Dashboard shows status, but the administrator needs a reliable way to refresh it before drawing conclusions.

How to Choose Frequency Without Going Overboard

Backups that run too rarely are dangerous. Backups that run too often add load and can fill storage quickly. Frequency should answer one question: how much data can you afford to lose without serious impact? For a site with contact forms, losing a full day of submissions may be unacceptable. For a static showcase site, losing a week of media files may be tolerable if changes are rare. For a store, the database and order tables require a more cautious approach, especially if the site is active around the clock.

In UpdraftPlus, files and the database can use different intervals. MainWP makes that easy to control centrally. If a child site uses premium incremental backups, keep MainWP documentation's limitation in mind: incremental backups apply to files, while database changes still require a separate database backup. That is not a weakness. It is an important separation. Files and databases change in fundamentally different ways.

Checking Scheduled Backups

After saving a schedule, open the Scheduled Backups tab. Confirm that the sites appear there, the intervals match the policy you selected, and the next run time looks reasonable. If the data looks outdated, select the needed sites and click Reload Data. Do not assume the schedule is broken based on an old Dashboard snapshot.

WordPress cron depends on visits or on a system-level cron trigger, so a scheduled backup does not always start at the exact second you expect. UpdraftPlus documentation separately explains missed schedules and scheduling delays. For low-traffic sites or sites with weak cron handling, it is better to configure a server-side cron job or at least account for the fact that backups may start later than expected. MainWP can show you the status, but the scheduling source is still the child site.

How This Connects to Updates and a Safe Workflow

Before bulk updates, it is useful to create a manual backup for the higher-risk sites. The automatic schedule may have run too long ago or may not include the most recent changes. A safe workflow looks like this: verify Dashboard sync, refresh scheduled backup data, run a manual backup on critical sites, confirm the files are in external storage, and only then move on to update tasks. It takes more time than clicking one update button, but it dramatically lowers the chance of a painful restore later.

If you produce client reports or maintain an internal service log, do not record only that "backup is configured." Record the outcome of the latest verification as well. Recovering your reputation after a failure is usually harder than maintaining the discipline of one extra checkpoint.

An Operating Procedure for Agencies and Network Administrators

When MainWP UpdraftPlus is introduced into a client site network, interface settings alone are not enough. You need a short operating procedure so that any administrator knows what to do before an update, after a failure, when changing storage, and when handing off a project. Without that procedure, the Dashboard quickly turns into a collection of buttons: each specialist runs backups differently, labels milestone copies differently, and interprets warnings differently.

The procedure does not need to be a long document. One page is enough to start: where MainWP UpdraftPlus is opened, which sites are considered critical, where the external storage list is kept, what the default file and database frequency is, which sites have overrides, who verifies restore, and how the result is recorded. This kind of document is especially useful when maintenance is handled by a team rather than one person.

Weekly Review

Once per maintenance cycle, open Overview and Scheduled Backups. Confirm that important child sites are syncing, UpdraftPlus is active, no plugins were unexpectedly deactivated, and there are no pending updates that might affect compatibility. Then refresh schedule data with Reload Data for the selected sites. If the Dashboard is showing old information, do not assume there is a problem until the data has been refreshed.

After that, choose several sites of different types: one simple informational site, one with forms, and one store or large catalog if you have them. Open their backup history and confirm that the latest copies contain the expected components. This spot check does not replace monitoring, but it quickly reveals system-wide issues: storage quota is full for every site, a new security plugin blocks uploads, or cron stopped running after a hosting change.

Review Before Bulk Updates

Before bulk updates to WordPress core, themes, or plugins, use a stricter sequence. First sync MainWP, then review UpdraftPlus Overview, then create manual backups for the critical sites. If the update affects WooCommerce, payment forms, memberships, bookings, or any site with active orders, a normal scheduled backup may not be enough. You need a fresh copy created immediately before the change.

For higher-risk sites, add a short pause between the backup and the update: open the storage destination and confirm that the file set is really there. If the backup never reached storage, do not continue just because the Dashboard is already open. A delayed update is cheaper than a restore attempt without a working backup.

After the Update

Do not delete the milestone backup immediately after the update. Check the public-facing site, forms, member login, checkout, email delivery, key pages, and any admin areas that matter for the project. If everything works, keep the milestone backup until the next scheduled review or until the retention period defined in your backup policy. If an issue appears, you will have a clear rollback point.

If the update succeeds, record it in the operational log. A short note is enough: site, action, backup created, storage checked, update completed, smoke test passed. That kind of note helps you understand a week later why a manual backup is still in storage and whether it is safe to remove.

Handing Off a Site to Another Administrator

When transferring a site to a new administrator, do not stop at providing a WordPress login. Pass along the backup procedure as well: where backups are stored, which storage accounts are in use, which directories are excluded, whether there are premium-dependent settings, and how often restore is tested. If storage is tied to the client's account, make sure the new administrator has access not just to WordPress, but also to the archive storage location.

The biggest handoff mistake is assuming that the installed plugin will explain the full history on its own. It will not explain why a specific folder is excluded, why the database is backed up more frequently than files, why one copy is marked as manual, or why another site uses a separate bucket. Those decisions need to be documented in plain language.

Restore and Migration Limits in This Setup

MainWP UpdraftPlus makes it convenient to reach the restore workflow, but restoration is still a serious operation. It can replace files, database tables, settings, plugins, or the media library. If the backup is old, restoring it may roll back recent orders, leads, comments, or user actions. That is why restore on production should only be started after evaluating the consequences.

Be especially careful with sites that contain dynamic data. For example, if a store received new orders after the backup point, restoring the database to that older moment may remove those records from the live database. In cases like that, it is better to restore a copy in staging first, understand the scope of the problem, manually export any missing data, or agree on a maintenance window. MainWP helps you reach the button faster, but it does not remove the business implications of recovery.

What to Check Before Restore

• You selected the correct backup set, not just the closest-looking one.
• You understand which components will be restored: database, plugins, themes, uploads, others.
• You have access to the Dashboard, hosting account, or file manager in case the site does not come back after restore.
• You have a fresh backup of the current state before rollback if the site continued to receive changes.
• You verified that remote storage is accessible and that the required archive parts can be downloaded without errors.

If any one of these checks fails, stop and prepare a safer path. Restoring "and hoping for the best" is acceptable only on a test environment or a site where losses do not matter. On a client-facing production site, it is too risky.

The Line Between Backup and Migration

UpdraftPlus can help with migration, and premium features expand those transfer workflows further. But in this guide, MainWP UpdraftPlus is treated first and foremost as a way to manage backups and restores across a site network. If your main task is moving a site to a new domain or server, you should separately review UpdraftPlus migration documentation, search-and-replace requirements, file permissions, permalinks, SSL, and WooCommerce-specific behavior.

Do not mix routine backup policy with a migration project. Ongoing maintenance needs stable schedules, storage, and restore verification. Migration needs separate backups, a staging environment, URL control, and checks for login, email, cron, cache, and indexing. MainWP can still be part of the administrator's workspace, but the transfer itself requires its own plan.

How to Learn Restore Safely

The best way to learn restore is not to wait for a real emergency. Take a low-risk site or a staging copy, create a backup, then restore individual components and verify the result. See what the log looks like, where warnings appear, how long the process takes, and which files are downloaded from storage. After one exercise like that, the Restore button stops feeling abstract, and the team understands the real consequences.

For an agency, it is useful to repeat this check whenever the team changes or the hosting infrastructure changes. A new hosting provider, a new storage provider, new security rules, or a new caching layer can change backup behavior. If the infrastructure changes, test restore again.

Remote Storage, Exclusions, and Large Sites: Practical Nuances

Large sites are usually what break the ideal picture of backup management. They have lots of uploads, heavy images, cache data, old exports, temporary files, and sometimes multiple WordPress installations sharing one database. MainWP UpdraftPlus does not hide that complexity, but it does give you a place where you can document and manage it in a controlled way.

File Exclusions Without Breaking Restore

Exclusions are useful when they prevent you from backing up data that can be recreated. That usually means cache folders, temporary directories, old archives, logs, or files generated by optimization tools. But you should not blindly exclude the entire uploads directory if it contains the site's media library. You should not exclude the active theme if you expect to restore the site's design. You should not exclude must-use plugins if they control critical functionality.

A good approach is to change exclusions one type at a time and run a test backup after each change. If the archive becomes much smaller, verify that the reduction makes sense. If an important part of the site disappears, roll the exclusion back. MainWP can apply a shared policy, but for large sites it is often more reasonable to use site-specific settings through overrides.

Remote Storage with Multiple Destinations

If a child site has several remote destinations configured, MainWP documentation describes the option to expand cloud options and choose a specific destination. That is useful in scenarios where routine backups go to one storage target, while a milestone backup before migration goes to another. Do not create complexity for its own sake, but do not limit yourself to one local directory on a production site either.

For S3-compatible storage, FTP/SFTP, and cloud providers, verify not only that credentials were saved, but that the archive actually uploads. Access errors, SSL certificate issues, quotas, incorrect endpoints, and timeouts often appear only when the transfer starts. If storage shows only part of the file set, the backup should not be treated as complete.

Split Archives and Resource Limits

UpdraftPlus supports large sites, but its troubleshooting documentation emphasizes that the process still has limits, especially on weak hosting. If backups keep stopping, archives are too large, or the process repeatedly hits timeouts, reduce ZIP chunk size in UpdraftPlus expert settings, exclude temporary directories, and run backups during lower-traffic periods. MainWP does not replace those settings. It simply makes the process easier to manage from the Dashboard.

Do not use backups as a server stress test. If every backup fails, find the technical cause first: memory, disk space, timeouts, cron, remote storage, a security conflict, or hosting limits. Only then should you treat the schedule as a normal recurring process.

Verifying Results: How to Know a Backup Is Actually Useful

The most dangerous mistake is treating a green status line in the interface as sufficient proof. A backup is only useful if it completed, contains the right components, is stored in an accessible location, is not corrupted, and can actually be restored. In a site network, you do not need to inspect every archive manually every day, but verification needs to be built into the maintenance process.

Four Levels of Verification

1. Status in MainWP: the Dashboard sees the site, the action completed, and there is no obvious warning about a deactivated plugin or a required update.
2. UpdraftPlus history on the child site: the backup set is listed, the components match the selected parameters, and the log contains no fatal errors.
3. External storage: the files were actually uploaded, all expected parts are present, and storage is not reporting quota or access problems.
4. Restore test: in a safe environment, you have verified that the archive can be read and restored in at least one typical scenario.

For small sites, you can periodically test a full restore. For larger projects, it may be enough to test restoration in a staging environment after major changes. Either way, verification needs to be part of the maintenance process, not something you only think about after a failure.

What to Look for in the Log

The UpdraftPlus log helps you distinguish a genuinely successful completion from a partial result. Look for messages about insufficient space, inability to open a file, SSL errors, timeouts, cloud storage issues, unavailable tables, corrupted ZIP archives, or a stopped process. If the same error repeats on the same site, MainWP is acting as a path to the problem, not as the fix itself.

If the backup was created before an update, do not delete it immediately after the update succeeds. Wait until the site passes a functional check: homepage, forms, cart, account area, key pages, and admin screens. Sometimes a problem shows up later, and an overly short retention period can remove the rollback point before you understand how serious the failure is.

How to Document a Backup Policy

For each important site, it is useful to keep a short record: database frequency, file frequency, storage destination, retention, exclusions, whether premium features are used, and the date of the most recent test restore. This does not have to be a complicated spreadsheet. But without a record like this, any new administrator will end up guessing why one site is configured differently and whether it is safe to change the settings.

The real outcome of configuring MainWP UpdraftPlus is not a neat list of sites. It is a clear, testable, repeatable backup policy.

Common MainWP UpdraftPlus Problems and Troubleshooting

Most problems in this setup fall into one of three layers: MainWP cannot see the correct child-site state, UpdraftPlus on the child site cannot complete the backup, or remote storage does not accept the files. It is best to troubleshoot from the top down so you do not reinstall plugins for no reason.

The Site Does Not Appear in UpdraftPlus Overview

Symptom: you are sure UpdraftPlus is installed on the child site, but the site is missing from MainWP > Add-ons > UpdraftPlus > Overview or looks inactive.

Likely cause: the Dashboard has not synchronized the latest state yet, the child site is temporarily unavailable, the plugin is installed but not activated, or the MainWP connection to the site is unstable.

What to check: open the child site directly, confirm that UpdraftPlus is active, then return to MainWP and run synchronization. Check the overall connection status for the child site. If MainWP cannot complete a normal sync, the problem is not the UpdraftPlus extension.

How to fix it: restore the MainWP connection to the child site first, then run sync again. If the site appears, check whether the row shows Activate or Update. Leave reinstallation for last, only after you have confirmed that sync works but the status is still wrong.

Remote Storage Cannot Be Configured from the Dashboard

Symptom: the settings show remote storage, but authorization does not complete or some parameters are unavailable.

Likely cause: the provider requires initial authorization on the child site itself. MainWP documentation warns that because of the security requirements of some storage providers, the first connection may need to be completed locally.

What to check: open UpdraftPlus on the child site and complete storage authorization there. Then create a test backup and make sure the archive uploads successfully. After that, return to MainWP, sync the site, and see whether the parameters now appear.

How to fix it: do not try to pass keys through external instructions or Codex tasks. Enter credentials only in the site's proper interface or the provider's official flow. If storage still fails, check the endpoint, quota, SSL, and access permissions.

The Backup Stops Midway

Symptom: a manual or scheduled backup starts but never completes. The log may show timeouts, memory errors, interrupted archiving, upload problems, or resource warnings.

Likely cause: weak hosting, a large uploads directory, oversized ZIP chunks, low free disk space, PHP limits, unstable storage connectivity, or a security-related conflict.

What to check: free disk space, media library size, whether cache folders are being included in the archive, the UpdraftPlus log, PHP limits, cron behavior, and remote storage availability. If the problem happens on only one site, compare its size and settings to sites that work correctly.

How to fix it: reduce archive chunk size in UpdraftPlus expert settings, exclude temporary directories, run backups during lower-traffic periods, verify storage behavior, and discuss hosting resources with the provider. If the backup succeeds after reducing the chunk size, refine the settings gradually rather than reverting everything at once.

Premium Features Do Not Appear

Symptom: you expect to see table selection, incremental backups, anonymization, or other premium-dependent options, but MainWP only shows the basic settings.

Likely cause: the required UpdraftPlus version or add-on is not active on the child site, Use Premium Version is not enabled, or the Dashboard was not synced after the change.

What to check: the UpdraftPlus state on the child site, whether the needed add-on is present, the Use Premium Version toggle, and MainWP synchronization. For incremental backups, remember that they apply to files, while database changes still require a separate database backup.

How to fix it: enable premium mode only on sites that actually support those features, run sync, and review the settings again. Do not describe premium parameters in your operating procedure as mandatory for every site if part of the network uses the free version.

The Schedule Exists, but Backups Do Not Appear on Time

Symptom: the schedule is configured, but the backup starts later than expected or appears to have been missed.

Likely cause: WordPress cron depends on traffic or an external cron trigger. On low-traffic sites, tasks may run with a delay. Storage errors, server limits, or stale Dashboard data can also be involved.

What to check: the Scheduled Backups tab, the Reload Data button, the UpdraftPlus log, WP-Cron or server cron status, and the most recent successful backup set.

How to fix it: refresh the data in MainWP, review the local log, configure a server-side cron job for critical sites, and run a manual backup before important updates. If the schedule keeps failing, do not rely on it until the root cause is fixed.

Only Part of the Files Reached Storage

Symptom: the cloud storage contains the database or a few ZIP files, but some uploads, themes, plugins, or other components are missing.

Likely cause: the upload was interrupted, storage quota is full, a timeout occurred, exclusions were configured incorrectly, or the network connection dropped during transfer.

What to check: the file list in storage, the backup log, provider free space, exclusion settings, and archive chunk size. If the storage destination shows a quota error, deleting old backup sets may be required.

How to fix it: resolve the storage issue, reduce the chunk size, run the backup again, and confirm that the full file set is present. If the incomplete backup was created before an important update, do not use it as a restore point.

Safe Workflow Improvements Without Editing Code

With MainWP UpdraftPlus, there is no need to invent snippets or hooks if the official documentation does not require them for normal operation. It is far more useful to improve the process itself: define naming, retention, verification steps, and pre-update rules. That is safer than injecting code into production sites for the sake of questionable automation.

Naming Milestone Backups

If a label field is available through the reporting add-on, use short, clear labels. MainWP documentation describes the Your label for this backup (optional) field for cases where the UpdraftPlus Reporting add-on is active. A label up to 40 characters helps distinguish a pre-update backup from a normal scheduled backup. If that field is not available, record the milestone in your internal maintenance log instead.

Good labels are short and specific: before-plugin-update, before-migration, pre-theme-change. Do not include client personal data, secrets, keys, or internal passwords. The label is for orientation, not for storing confidential information.

The Two-Check Rule Before Bulk Updates

Before bulk updates in MainWP, use two checks. The first is at the Dashboard level: all required sites are synced, UpdraftPlus is active, and there are no obvious update or deactivate warnings. The second is at the backup level: critical sites have a fresh backup in external storage or a newly created manual copy. That approach is better than blindly trusting an old schedule.

Documenting Exclusions

Every override needs a reason. If a site excludes a cache folder, that is straightforward. If it excludes part of uploads or some database tables, you need a record of who made that decision and why. When administrators change, those are exactly the exclusions that turn into incidents: the new person sees "backup successful" but does not realize the archive is intentionally incomplete for restoring a specific function.

Rolling back a questionable setting: if the backup becomes incomplete after changing exclusions or storage settings, revert to the previous configuration, run sync, start a manual backup, and compare the archive contents. Do not leave an experimental setting in the schedule until it has been verified.

When MainWP UpdraftPlus Is the Right Choice

MainWP UpdraftPlus is worth using if you already have a MainWP Dashboard, several connected WordPress sites, and a clear reason to centralize backups. The extension is especially useful when backup policy needs to be an ongoing operational process rather than a one-time setup: before updates, after changes, for client reporting, for storage oversight, and for quickly jumping into the settings of a specific site.

Before rolling it out, verify three things: the Dashboard syncs reliably, UpdraftPlus is installed and working on the child sites, and remote storage actually accepts the archives. Then define a global policy, identify the sites that need overrides, create a manual backup before an important update, and document how verification is done. In that order, the extension becomes more than another button. It becomes a controlled recovery system.

If, after reading this, you know which sites need to be connected, which storage destinations need to be checked, and which schedules need to be defined, you can move on to installation. To get started, use the page's download section: get the WordPress version, then test the extension on one low-risk child site before applying the configuration across the entire network.

Do not try to build the perfect setup on day one. Start with the verified minimum: a full manual backup, external storage, a clear schedule, and one restore test. Then add premium options, site-specific exclusions, milestone labels, and stricter retention rules only where they are actually needed.