MainWP API Backups - WordPress Plugin

A Guide to Setting Up Backups with MainWP API Backups

This guide to MainWP API Backups will help you understand which backups the management dashboard can initiate, prepare access to supported hosting platforms, connect sites to the correct accounts, and safely verify backup creation and recovery. Rather than treating every site as a separate tab in a hosting dashboard, you will establish a clear workflow: identify the infrastructure type, link the site, run a test backup, confirm it with the provider, and plan the recovery process in advance.

The key practical point is that MainWP does not package WordPress files on the central site. MainWP API Backups communicates with a hosting provider, cloud management platform, or virtual server interface and asks it to perform whatever backup operation it supports. A reliable outcome therefore depends on two layers at once: a correct connection between MainWP and the provider, and the provider's own storage, schedule, permissions, and recovery settings.

This approach is especially useful for an administrator managing a network of client sites that already use their hosting provider's built-in restore points. However, it should not be treated as a universal replacement for an independent copy of all data. This guide explains what API Backups can handle, where MainWP's responsibility ends, how to distinguish a server restore point from a WordPress archive, and why a test run matters more than a reassuring status in a table.

How the Path from the MainWP Dashboard to a Restore Point Works

MainWP Dashboard provides a central dashboard to which child sites are connected. The API Backups extension adds another layer to this setup: for a selected child site, the dashboard knows which supported provider manages the infrastructure, uses saved credentials or an access key, and sends a request to create a backup, refresh the backup list, restore a backup, or perform another available operation. In a normal working setup, the administrator sees the site in the API Backups list instead of trying to remember which server hosts it.

The key takeaway: MainWP does not become a separate archive storage location simply because you click the backup button in MainWP. It acts as a management dashboard. The file, disk image, or restore point remains where the specific hosting provider, cloud platform, or VPS provider stores it and is governed by that provider's rules. Before your first large-scale run, answer four questions: where the backup is physically stored, how many restore points the provider keeps, what the snapshot includes, and how recovery is performed.

Three Roles You Should Keep Separate

In a straightforward setup, three parties are involved. The first is MainWP Dashboard, where you group child sites, select one or more targets, and send a command. The second is the infrastructure provider, which receives the request through its interface and performs the actual work. The third is the WordPress child site itself, whose files, database, or server image are included in the restore point depending on the service model.

This distinction helps prevent a common mistake. An administrator may see a site name, an operation date, and an available restore option in MainWP, but that does not mean MainWP independently created a portable WordPress ZIP archive. One provider may produce a full server restore point, another may create a built-in application backup, and a third may expose a set of control panel tools. Recovery may likewise be performed at the server level, application level, or within the limits of the specific platform.

Do not confuse MainWP API Backups with the MainWP REST API. The REST API is designed for programmatic interaction with the MainWP dashboard itself. API Backups uses third-party provider interfaces to manage their backup systems. These mechanisms can exist in the same project, but they solve different problems. For a standard API Backups setup, you do not need to write your own API request or expose the MainWP REST API unless your separate automation requires it.

Which Infrastructure Providers the Extension Supports

MainWP's official knowledge base lists cPanel with native backups and WP Toolkit, Plesk with WP Toolkit, Kinsta, Cloudways, GridPane, Vultr, Akamai Cloud Computing (formerly Linode), and DigitalOcean. The list should be taken literally: the child site must be hosted by a supported provider or within a supported environment. Having WordPress, MainWP Child, and administrator access does not by itself turn an arbitrary server into an API Backups source.

With a cloud management platform, the connection is usually built around a shared account: the dashboard can access the list of servers and applications, then maps a specific child site to the correct infrastructure resource. With a VPS provider, you will more often need to select the provider type and identify the specific instance. cPanel and Plesk may have their own requirements for an enabled backup service, account permissions, and available panel tools. It is safer to validate one site first than to paste one key into every field and immediately run backups across the network.

What “Backup” Means Across Different Providers

The term may sound unambiguous, but in practice it describes different mechanisms. A virtual server snapshot often restores disk or instance state rather than an individual wp-content folder. An application backup in a cloud management platform may include the files and database for a specific application. WP Toolkit is focused on a WordPress installation inside the control panel. A native cPanel mechanism may offer separate full-backup and database-backup options if the host allows them. Review the details of your own hosting plan in advance and do not rely on a feature the provider does not offer.

The snapshot level affects both recovery speed and the consequences of recovery. If a restore point rolls back an entire instance, it may affect other sites, system settings, or data hosted on the same server. If the operation applies to one WordPress installation, the scope of change is narrower. This is why you must identify the target before restoring: an individual site, application, database, or entire server. It should never remain an unstated assumption in the MainWP interface.

Storage Boundaries and the Need for a Second Layer of Protection

MainWP documentation explicitly notes that API Backups does not manage retention settings or create its own storage location for files. That is convenient when you want to use infrastructure you already pay for and understand, but it leaves the decision about backup independence with the administrator. If VPS restore points are stored in the same data center or tied to the lifecycle of the same instance, they should not automatically be considered complete protection against every type of failure.

For a critical site, a sensible approach often consists of two separate tasks. API Backups provides fast, centralized control over the hosting provider's built-in restore points before updates, maintenance, and bulk changes. A separate backup plugin with an offsite destination, or a native export of the database and files, covers cases where you need an independent archive, longer retention, or recovery of only part of WordPress. These tools do not conflict when each has a clearly defined role.

Do not treat a "Backup" button as proof that you are prepared for an incident. Proof comes only from a verified chain: the command was accepted, a current restore point is visible in the provider account, its scope is understood, and the recovery procedure has been tested on a safe target or site copy.

Who This Backup Management Approach Is For

MainWP API Backups delivers the most value to people managing multiple WordPress sites on recurring infrastructure. An agency can organize client sites into groups, while a technical specialist can see which ones are connected to Cloudways, cPanel, Kinsta, or a VPS. Instead of switching between dozens of hosting dashboards, they can perform the same verification task from one location and more quickly identify a site without an available restore point.

A strong candidate is a network owner who already understands the hosting policy and wants to reduce manual work before updates. It also suits a team where one person handles infrastructure and another handles WordPress: the first defines permitted access and retention with the provider, while the second initiates approved operations from MainWP. This separation is especially useful when not every editor should receive full access to a cloud account.

It is less suitable when all sites are hosted with an unsupported provider, when an independent archive must be stored in your own remote location, or when you need detailed control over the contents of every WordPress backup. In that case, it is often more practical to consider a dedicated MainWP integration with UpdraftPlus or WPvivid and configure backups on child sites first. API Backups does not have to be the network's only standard: it is useful specifically where it matches your real infrastructure.

Prepare the Network: Inventory Before Your First Access Key

Before installing or enabling the extension, it is worth creating a small inventory. Its purpose is not bureaucracy. It prevents one child site from receiving access to another server and prevents a successful test with one provider from creating a false sense that the entire network is ready. Maintain a working table outside MainWP with the domain, site group, infrastructure provider, backup operation type, account owner, server or application ID, storage location, retention rule, and date of the last recovery test. Do not store the secret key itself there.

This table helps separate two similar but distinct concepts: the site you see in MainWP and the resource backed up by the provider. A single server may host several WordPress installations. In Cloudways, an application is associated with a particular server and application ID. With a VPS, a restore point may apply to the entire instance. If you map these items from memory or by a similar domain name, a bulk operation may affect the wrong target.

Minimum Checklist Before Connecting

The checklist below is not intended to delay work. It is there to make the first connection safer. Complete it once for a test child site with every new provider, then use it as an internal standard.

• Confirm the platform type. Verify that it is actually cPanel, Plesk, Kinsta, Cloudways, GridPane, Vultr, Akamai Cloud Computing, or DigitalOcean, rather than only the name of a hosting reseller.
• Verify that the provider's backup service is available. On some panels and plans, backup operations are disabled, restricted by permissions, or require separate activation by the host.
• Identify the operation level. Record whether the backup covers a WordPress installation, application, database, files, or the entire virtual server.
• Create a dedicated key with the minimum required permissions. Do not use a former employee's personal key or share the main account password with multiple editors.
• Confirm the child site. Make sure it is connected to MainWP, synchronizes successfully, and is not marked as disconnected or outdated.
• Schedule a verification window. Backup creation, and especially recovery, can take time and affect resource availability. Do not run a test during a critical campaign or while customers are placing orders.

The organizational side matters as well. Decide in advance who may only start a backup, who may initiate a recovery, and who approves recovery for a client site. In a small project, this may be one person. In an agency, it is better to separate the roles at least procedurally: an operator records the symptom and restore point, the infrastructure owner confirms the recovery scope, and another person checks the public-facing site after the operation.

Why the Key Should Be Dedicated and Revocable

An API key or another access secret connects MainWP to external infrastructure. It should never appear in notes, tickets, screenshots, or messages. Create the key in the provider dashboard according to its rules, name it clearly so its purpose is obvious, and store it only in secure secret storage and in the relevant MainWP settings field. If the team changes or a test ends, the key can be revoked and replaced without requiring every administrator to change their password.

Minimum permissions do not always mean "view-only" permissions. Creating and restoring backups on the provider side may require access to backup actions and the ability to view servers, applications, or instances. Do not guess the required permissions from a toggle label. Start with the provider's recommended API profile, run a creation test, and expand access only for the specific missing capability if an error occurs. That approach is better than granting a key complete control over the account from the start.

If you use a shared Cloudways or GridPane account, separately confirm that the user who created the key can see the exact servers used by your network. When MainWP includes sites for different clients, account isolation and careful resource assignments matter more than the convenience of one shared key.

Provider Details That Affect Your Plan

For Cloudways, MainWP documentation describes mapping connected sites to a server and application. Before a bulk operation, it is useful to open one child-site profile and compare the domain, server, and application with the cloud dashboard. Modern Cloudways connections support access-token authentication, while older credentials may remain valid for existing connections. Do not change the authentication method across a working network while dealing with an urgent recovery task.

For Kinsta, the configuration depends on the account, access key, company, and environment. If one child site belongs to another account, the documentation provides for separate site-level settings instead of unconditional inheritance of global values. This is a good example of why a "one key for everything" setup is not always safe. Record exceptions explicitly and mark them in your internal inventory.

For VPS providers, MainWP requires you to assign a provider type and instance ID on the child-site edit page. This is especially easy to get wrong when a cloud account contains many similarly named servers. Before saving, compare the domain, the instance's internal name, and its purpose. A VPS snapshot may cover more than one WordPress site, so permission to restore such a resource requires additional approval.

cPanel and Plesk require special care. Having a panel account does not prove that its backup service is permitted by the hosting provider. MainWP's official documentation specifically warns that backup operations may be disabled on new cPanel installations. The safe sequence is to confirm availability with hosting support, connect one non-production site, create a restore point, and only then expand the setup.

Choosing a Test Site and an Acceptable Load

For the first run, do not choose your most important store or a site with the only current copy of a database. A quiet corporate site or a controlled project copy whose expected state you know will work well. Record the start time, resource size and type, operator name, and the planned verification point. If a backup takes a noticeably long time, that is not necessarily a MainWP error: duration depends on site size, provider speed, the provider's queue, and the type of restore point being created.

Do not start dozens of operations while heavy updates, migrations, catalog imports, or network-wide cache clearing are running at the same time. A central button makes commands easier to send, but it does not remove the physical load on the provider side. Spread your first jobs across groups, start with a small number of sites, and observe how the operation status appears in both MainWP and the infrastructure platform.

Data You May Need to Protect Separately

Even a complete server restore point does not remove the need to understand what data it contains. For WordPress, the database, uploads directory, themes, plugins, and specific configuration files are critical. For an online store, orders, payments, user accounts, and activity created after the snapshot are particularly sensitive. If you restore an earlier state of the entire site, those changes may disappear. Before a major rollback, identify the period at risk and, where possible, separately export data created after the chosen restore point.

Be especially cautious with live databases containing orders, bookings, form submissions, or customer accounts. API Backups can be excellent protection before an update, but it does not replace a business procedure for rollback situations. Agree with the site owner which new records must be preserved separately, who will verify emails and payments, and how users will be informed about the maintenance window.

Initial Connection: Start with One Provider, Then One Child Site

Once preparation is complete, do not begin by filling in settings in bulk. It is more reliable to configure the connection at two levels: first add access to one provider in the central dashboard, then assign or confirm the resource for one child site. This order lets you distinguish a key error from a server-mapping error, and a mapping error from a hosting plan that does not provide backup capabilities.

Menu labels can change slightly as MainWP evolves, but the official documentation describes a working path through MainWP > Sites > API Backups and the API settings area. In some dashboard views, the relevant page is reached through the sites and backups section. Follow the current API Backups item in your own dashboard and the visible list of supported providers rather than relying on an old screenshot from a third-party article.

Step 1. Open the Provider Settings and Add the Secret

Open the API Backups page and select API settings management. Find the tab or area for the required provider. Before pasting a key, verify the account in which it was created: agencies often maintain separate accounts for internal projects and clients. Enter only the information requested by the current form. For a cloud management platform, that may be a key or token; for Kinsta, a combination of credentials and identifiers; for a control panel, its API access details.

Save changes with Save or Save Settings, then do not immediately switch to another tab. Check whether a clear success indicator appears and whether the form has not reverted to an empty value. If the secret is hidden after saving, that is normal interface behavior rather than proof that it was lost. Do not paste the key again merely to make its characters visible.

For Cloudways, it is safer to use the authentication method supported by your current MainWP dashboard and Cloudways account. Recent MainWP updates mention support for Cloudways REST API v2 and access tokens for new connections, while older credentials for existing connections may continue to work. If the network is already in service and functioning correctly, do not treat the newer approach as a reason for an urgent migration. Planned key rotation and emergency recovery are different events.

Step 2. Link the Infrastructure to the Site Profile

Now open the specific child site through Child Site Overview and go to its edit page. MainWP documentation calls this area Backup API Provider Settings. For VPS providers, this is where you select the provider from the list and enter the instance ID. For resources where automatic mapping is not available or has not worked, this site profile determines which target will be backed up.

Do not copy an identifier from the address bar at random because it resembles an internal number from another project. Open the resource with the provider and compare at least two details: the domain name or application purpose, and the server characteristics. If an instance hosts multiple sites, add a clear note that recovery will affect more than one domain. This protects against a situation where an operator sees one site name in MainWP while the operation actually affects a shared server.

MainWP documentation identifies an exception for Cloudways and GridPane: assigning a VPS provider in the site profile is not required in the same way as it is for other supported providers. That does not mean you should skip verification. After saving, still make sure MainWP shows the expected site and that the cloud dashboard links that exact domain to the intended application or server.

Step 3. Decide Where Global and Local Settings Are Needed

A global setting saves time when many sites use the same account. However, it can be risky when the network contains exceptions. For example, most sites may use one Kinsta account while two client projects are hosted under another. For those exceptions, use separate settings in the child-site profile if the current form provides an option to override global values. In Kinsta's official MainWP description, this is expressed through Overwrite Global Settings.

The rule is simple: global values are appropriate only when the same key genuinely has permission to work with every resource inheriting it. If you are unsure, create a local configuration for one site first. A little more manual work at the beginning is less expensive than accidentally combining infrastructure for different clients.

After saving, do not remove an existing local entry unless necessary. First record which configuration is in use, run a verification operation, and only then remove outdated access according to your internal procedure. If a key stops working, you should know which provider and site are affected instead of searching through multiple identically named global fields.

Step 4. Refresh the Backup List Before Creating a New One

Once the connection is saved, open the API Backups list for the test site. Do not assume the list immediately contains current data. MainWP's Kinsta instructions specifically mention the Refresh Available Backups button; the equivalent action is also useful in other cases where the dashboard receives data through an external API. Refresh the list first, check whether existing restore points are visible, and confirm that their source matches your expectations.

If the list is empty, do not launch ten repeated attempts. Follow the chain: does the provider offer backups, are the key and identifiers correct, can the key access the intended account, is the child site mapped to the assigned resource, and is that type of operation available on the plan? Only after those checks should you create a new restore point. An empty list may mean there are no backups, synchronization is delayed, permissions are restricted, or the resource is mapped incorrectly. Those are different causes with different fixes.

Step 5. Record the Baseline State

Before creating a test backup, make a short record of what should be preserved. For an informational site, that might be a published page, a file in the Media Library, and the version of one plugin. For a store, it may be a test product and a verification record that can be checked safely. Do not alter real orders or account data for an experiment. A baseline lets you answer not merely "does the site open?" after recovery, but the more important question: "did exactly what should have returned come back, and were any critical data lost?"

The initial connection is complete not when the key is saved, but when the test site appears in the expected environment, the backup list has refreshed, and the team has a clear description of the scope of any future recovery.

Actions Available in the API Backups List

The API Backups page becomes the place for routine monitoring. It is generally used not to review every setting at once, but to find a specific site, its available restore points, and actions in the three-dot menu. MainWP's official steps describe creating a backup for one site with Backup, managing the list of restore points with Manage Backups, and recovering through Restore Backup. The placement of a menu item may change, but the sequence remains the same: select a target, request the operation, wait for its status, and refresh the list.

Single-Site and Bulk Operations Without a False Sense of Control

The most visible benefit of MainWP API Backups is that you do not need to enter every hosting dashboard to perform the same task. But a centralized button also amplifies mistakes: if the wrong set of sites is selected, the action can spread quickly across the network. In daily work, it is useful to distinguish three modes: a restore point before changing one site, a batch for a uniform group of sites, and a review of available backups without starting a new job.

One-Site Backup Before a Risky Change

Use this mode before updating a set of plugins, replacing a theme, changing code, importing content, or starting developer work. Open API Backups, find the relevant domain, and choose Backup from the action menu. After submitting the request, do not immediately proceed with the update. Wait for the provider to finish the operation, then refresh the available backup list. On some platforms, the process can take considerable time because the actual work occurs outside MainWP.

Do not only check that a row has appeared. Confirm the site match, creation time, backup type or source if shown, and the absence of an explicit error message. Then open the provider dashboard and make sure the new restore point is visible there as well. This two-system verification is especially important during initial adoption: it shows that MainWP did more than accept the command and that the external system actually reflected the outcome.

Only then should you make the site change. It is helpful to record the sequence in a maintenance log: "restore point before update - list of changes - outcome." If the update fails, you will not have to choose among unnamed backups and try to remember whether a restore point was created before or after the problematic action.

Bulk Operations Only for a Uniform Group

MainWP documentation allows you to select the required sites in the table and use Backup Selected Sites. This saves time when the sites truly share similar infrastructure and an acceptable workload. For example, you might choose a group of small client sites on one cloud management platform before an approved update. Do not include a store with active orders, a large portal, or a site connected to another provider simply because they also need a backup.

Apply three filters before a bulk action. First, the responsibility filter: you have authority to create these restore points and understand the consequences. Next, the infrastructure filter: the sites use the same well-understood backup method. Finally, the timing filter: no imports, migrations, order operations, or other work is currently taking place that could distort the verification point. If even one site is uncertain, exclude it and handle it separately.

For larger networks, it is useful to create groups based not on the client's industry but on the recovery model. For example, keep Cloudways application backups separate from WP Toolkit sites and VPS snapshots. Then a batch command means not merely "all sites in a folder," but "all sites with the same scope and expected rollback method."

Why One Status Does Not Prove That a Batch Is Complete

Even if MainWP reports that requests were sent, each provider processes them in its own queue. One site may finish quickly, while another is delayed by its size, workload, plan limitations, or a temporary API issue. After the batch, open the list and review exceptions: sites without a recent restore point, sites with an unclear status, resources whose provider or mapping has changed, and sites disconnected from MainWP.

Instead of one vague message saying "backups were completed," create a short summary: the number of selected sites, the number of confirmed restore points, a list of sites requiring manual review, and the reason for each exception. This report is useful not only for the team. It gives the site owner honest information: whether the backup operation was completed, where it was verified, and what remains uncertain.

Refreshing the List Is Part of the Operation, Not a Cosmetic Button

Refreshing available backups should become a routine step. Use it after creating a restore point, after a long-running operation, before recovery, and after changing credentials. Without refreshing, you risk selecting an outdated row or assuming a restore point is missing when it has already appeared with the provider. At the same time, do not refresh every second: give the external system a reasonable amount of time to complete the job and use its status as guidance.

When the response is slow, record the facts rather than guessing. Note the start time, selected site, provider, and action. Then check the provider page. If the operation is still running there, do not create a duplicate. If nothing has appeared, return to checking access and resource mapping. If the restore point exists at the provider but is not shown in MainWP after a refresh, that is a case for careful interface troubleshooting or a support request containing safe information and no secrets.

A Small Decision Matrix for Operators

The table works as a quick reference when actions have similar names but serve different purposes. It does not replace the specific rules of your hosting provider, but it helps identify the safest next step.

When each type of API Backups action is appropriate

Situation	Primary action	What to verify first	Readiness indicator
Updating one site	Create a restore point for the selected site	Correct resource, no critical traffic, current synchronization	A new restore point is visible in MainWP and with the provider
Scheduled work for a similar group	Select the sites and start a batch operation	A shared recovery method and an approved maintenance window	Each site has an individual confirmation of the outcome
You need to understand what is available	Refresh the restore point list	The provider connection and site profile have not changed	The list matches the external dashboard
A site starts behaving incorrectly	Open backup management; do not immediately start a rollback	The symptom, failure time, and future recovery scope	A pre-incident restore point is selected and there is a verification plan

After any of these modes, it is useful to create a short summary: which resource was handled, which restore point was confirmed, and what changed afterward. This turns API Backups from a collection of buttons into a managed workflow that can be handed to another team member without losing context.

Coordinating Updates, Cache Clearing, and Database Changes

A restore point is especially useful before changes that are difficult to undo quickly. However, it does not manage cache, store transactions, or external services on its own. If you clear cache, regenerate page-builder styles, or import data after an update, record the sequence: first a confirmed restore point, then the change, then verification of the public-facing site. Do not clear cache "beforehand" out of habit: it does not create protection and can make troubleshooting harder.

For sites with an active database, it is better to agree on a short maintenance window. Otherwise, a restore point created before an update may be technically correct, but restoring it can remove records created in the interim. Assign someone to export critical data, establish the maintenance start time, and after completion verify not only page response codes but also essential business tasks: cart behavior, forms, user login, publishing, and integrations that matter for that site.

Making the Process Clear to the Team

You do not need to write a complicated procedure dozens of pages long. It is enough to establish several fixed rules: create a verifiable restore point before a change, use bulk commands only for a uniform group, require separate approval for recovery, and record the outcome outside the interface. When these rules are known, a new operator will not make a decision based on a status color or the habit of "doing it the way we always have."

For an agency, it is useful to add neutral strategy information to the client profile: "provider restore point through API Backups before updates," "separate offsite backup on a schedule," and "recovery is approved with the owner." This record must not contain access keys, passwords, or screenshots of secret fields. Its purpose is to show the recovery path for the site and who makes the decision.

Practical Workflow: Prepare a Network for Updates Without Chaotic Hosting Logins

Imagine a typical agency task. MainWP has several dozen connected sites. Some are hosted through one cloud management platform, some run on VPS instances, and two stores are kept in a separate environment. The team plans to update a set of plugins on the first group, but does not want to open every server dashboard or lose the connection between the change and the restore point. Here, MainWP API Backups is used not as a "just in case" button, but as part of controlled preparation.

Goal and Boundaries of the Workflow

The goal is to create and confirm current native restore points for a uniform group of sites before updates, then verify the completed work and retain a clear path back for every resource. The boundary matters: this workflow does not automatically roll back every site, does not replace independent storage, and does not permit different infrastructure types to be combined. Stores with active orders and sites using another backup method are handled separately.

Before work begins, the operator receives a candidate list, and the technical owner confirms that every selected resource uses the same provider and has a clearly understood backup level. If a Cloudways group creates application-level restore points, it is not mixed with VPS snapshots. If one instance hosts several clients, the infrastructure owner decides whether a server restore point is safe for all of them. This simple filter reduces the risk of an incorrect bulk action far more effectively than another interface warning.

Preparation Before Starting

1. Separate sites by recovery method. Keep only sites in the first group whose source, key, resource, and rollback scope have already been verified.
2. Record the baseline state. Note the start time, responsible person, list of domains, and a short description of what will be checked on each site after the update.
3. Review exceptions. Remove disconnected child sites, sites with an unfinished migration, active import, or unclear local access configuration.
4. Plan for data created during the work. For a store, decide who will check new orders and how they will be preserved if a rollback becomes necessary.
5. Prepare an external log. It can be short, but it must connect the restore point, update time, and final outcome.

At this stage, do not create artificial activity on live sites merely to prove that they work. Record safe verification indicators instead: home page availability, administrator login, one key form, a product page, or another important user journey. The clearer these indicators are before a change, the faster a real problem will be identified afterward.

Create Restore Points and Confirm Them in Two Systems

The operator opens MainWP > Sites > API Backups, selects the approved group, and uses Backup Selected Sites. The task is not considered complete at the moment of clicking the button. Work at the external provider may be asynchronous, so the operations must be allowed to finish, then the available backups in MainWP must be refreshed and exceptions reviewed.

Next, the provider dashboard is opened for a sample of sites. The point of sampling is not to manually recheck every domain forever, but to confirm that the route remains consistent: MainWP shows the intended resource, and the provider has actually registered a new restore point. For the first bulk operation, it is useful to verify every site. Once the setup has been proven and has not changed, the team can move to sample verification plus review of all exceptions.

If one site does not receive confirmation, do not mark the whole group as fully ready. List it separately: "restore point not shown," "permission error," "resource connection requires review," or "operation still in progress." Updates can then continue for the confirmed subgroup or be postponed without losing clarity about what failed.

Update After the Verification Point

Once restore points are confirmed, update sites in small batches. This rhythm is more manageable than launching the entire list at once: if one plugin or theme causes a problem, it is easier to identify the pattern and stop. After each batch, check the selected verification indicators. For a corporate site, that usually means the home page, menu, contact form, and administrator login. For a catalog, search and the product page. For a store, the product page, cart, safe test checkout, emails, and record status.

Do not limit verification to the home page. Cache may show old markup, while an error appears in a form, customer account, editor, or background job. If a CDN or server cache is in use, clear it after updates only according to the accepted procedure, then repeat the test in a private window. This helps distinguish a site issue from viewing an older cached version.

What Counts as a Good Outcome

A successful outcome consists of four facts: every updated site has a confirmed pre-work restore point, updates finished without a critical error, key user journeys function correctly, and exceptions are documented rather than lost in a general status message. The phrase "everything was updated" is not a substitute for this record. It does not help a colleague who needs to know tomorrow which restore point can be relied on.

The Complication of Active Data

If new orders or submissions appear on a site during an update, a current server restore point from before the work remains useful, but it cannot be applied thoughtlessly as a universal undo button. Rolling back to it may restore the technical state while also removing newer records. For an online store, the workflow therefore needs an additional step: the operator records the time period, the business owner identifies critical new data, and before recovery the team decides whether that data can be exported, handled manually, or protected through a narrower operation.

API Backups is not making an error here: it works within the backup type provided by the infrastructure. The error occurs when the technical workflow ignores business data. The more active the site, the more important it is to separate the "pre-update restore point" from the "plan for restoring new transactions after a rollback."

Using Local Exceptions Without Confusion

Suppose eight sites use a shared Kinsta account while the ninth belongs to another client account. For the ninth site, configure local credentials confirmed for that profile and mark it as an exception in the log. Do not temporarily replace the global key before a general operation: you may disrupt access for the other resources and spend time restoring the MainWP configuration itself.

After configuring this, verify the exception separately. Refresh the available restore-point list, create one verification backup, map it to the correct environment, and only then add the site to your regular procedure. A local exception should be obvious, not invisible. Otherwise, the next operator may assume that every site on the network inherits the same configuration.

A Short Log That People Actually Use

The record can take three lines: date and maintenance window, list of sites or group, confirmation of restore points, completed changes, verified user journeys, and open notes. Add a link to an internal ticket if one exists, but do not include secrets or access details. After several cycles, such a log will show where delays occur most often, which sites need a separate procedure, and which providers do not immediately return a current restore-point list.

This feedback is what makes it possible to improve the workflow without guessing. If the same exception appears multiple times, do not hide it with another retry. Investigate whether access, the resource, permissions, child-site status, or the hosting policy changed. That is how centralized backups become a predictable practice instead of an occasional manual ritual.

Verifying the Outcome: How to Prove That a Restore Point Is Usable

Verification has three layers. The first is the interface layer: the command was sent, the list was refreshed, and the required restore point is visible. The second is the infrastructure layer: the same restore point exists with the provider and belongs to the correct resource. The third is the recovery layer: the team understands the scope and order of the reverse operation, and for critical sites that process is periodically tested on a controlled copy or safe environment.

The first two layers can be completed after every important operation. The third does not have to be repeated daily, but it cannot be postponed indefinitely. A backup that nobody has attempted to use remains an assumption. Plan recovery testing during a quiet window and on a target where rollback will not harm visitors or data.

Recovery Without a Hasty Rollback: Choose the Point, Scope, and Verification

Recovery is the most consequential operation in this guide. Do not begin by asking, "Which backup is the most recent?" First record the symptom, when it appeared, and the changes that preceded it. Then determine the scope: does the issue actually apply to one WordPress site, an application, a database, or the entire server? The broader the restore point, the more data and configuration it may change.

In MainWP, the official workflow begins on the API Backups page: find the required site, open Manage Backups, select a restore point in the table, and use Restore Backup. The interface sequence is simple, but the decision should not be reduced to four clicks. Before recovery, you need to understand what the selected provider includes in the restore point, which data appeared after it, and who will verify the outcome.

Gather Facts Before Opening the Recovery Menu

First write down what is not working. It may be a white screen after an update, a form error, missing content, an issue limited to the public-facing site, or a complete server outage. Then identify the last confirmed time when the site was working normally. That is how you choose an appropriate restore point: not the one "closest by date," but one created before the incident and after a known stable state.

Next, identify changes that may have appeared after that restore point: orders, comments, form submissions, Media Library documents, user registrations, DNS changes, email settings, or edits on neighboring sites sharing the same server. If they are critical, do not proceed with rollback until there is an approved method to preserve or manually restore them. In some situations, it is more appropriate to stop the problematic update, disable a component through its normal method, or deploy a copy for analysis instead of rolling back the primary resource in full.

Identify the Scope the Command Will Affect

An application-level backup may be limited to one site. WP Toolkit may be limited to the WordPress installation in the panel. A VPS snapshot is generally broader and may return an entire instance to an earlier state. Cloud providers also have their own restore-point and recovery models. Do not transfer an assumption from one provider to another: the same Restore label in two interfaces does not guarantee the same data scope.

If multiple sites share one server, scope is a mandatory question. Confirm whether neighboring domains, databases, scheduled jobs, web server configuration, or shared databases could be affected. If you are not sure, stop the operation and clarify the mechanism with the provider documentation or the infrastructure owner. Five minutes of caution before a rollback is usually better than several hours spent recovering unexpectedly affected projects.

Safe Sequence of Actions

1. Stop additional changes. Inform the team that troubleshooting is in progress, and prevent parallel updates, imports, and edits on the same resource.
2. Record the current condition. Safely document the symptom, time, and visible errors. If the platform allows you to create a new restore point of the current condition without making the problem worse, agree on this with the responsible person; it may help analysis.
3. Compare available restore points. Confirm their time, source, and scope. Choose a point before the incident, not simply the first row in the list.
4. Confirm the impact on current data. For stores, forms, and customer accounts, determine which new records must be preserved separately.
5. Start recovery for the correct target. Use Restore Backup only after the chosen restore point and scope have been confirmed.
6. Do not rush to repeat the command. External infrastructure may perform recovery for a considerable time. Monitor the provider status and do not create competing requests.
7. Verify the outcome. After completion, refresh the list and check the public-facing site, login, key business journeys, and data that should have been retained.

Verification After Recovery

Start with domain and dashboard availability, but do not stop there. Open several pages using different templates, check navigation, media files, forms, and authentication. For a store, safely verify the catalog and cart, and the agreed team should confirm that new orders and inquiries did not disappear unexpectedly. For a site with external integrations, check a test form submission, email, webhooks, or tasks that are critical to the operation.

Then compare the outcome with the pre-work record. If a specific update caused the incident, do not launch it again without analysis. Record the component version, condition, symptom, and selected restore point. This will help you later decide whether a different update sequence, test copy, or exclusion from bulk tasks is needed.

Verification is successful when not only the home page display has returned, but also the user actions and data for which the site exists. For a store, that means more than design; for a form, more than the presence of a field; for a customer account, more than the login screen.

How to Combine Native Restore Points with an Independent WordPress Backup

API Backups is well suited to centrally starting a backup mechanism available through the provider. However, for many critical sites, one layer of protection is not enough. The reason is not a limitation of MainWP, but the different nature of the tasks involved. A hosting restore point may be fast for rolling back infrastructure, while a dedicated backup plugin can be more convenient for offsite storage, scheduled backups, archive migration, or more detailed control over WordPress data.

A Practical Division of Roles

The clearest approach looks like this. MainWP API Backups is used as a pre-operation restore point before an update or developer work on infrastructure that supports the mechanism. A dedicated plugin on the child site creates regular independent backups to an offsite destination chosen by the organization. MainWP can centrally monitor such a plugin when a relevant integration exists, but it does not replace the plugin's own retention settings.

For example, MainWP offers integrations with UpdraftPlus and WPvivid alongside API Backups. This does not mean you must install all of them on every site at once. Choose the combination based on need: if the provider's native restore point and a short recovery period are sufficient, API Backups may be the primary operational tool. If you need storage outside the site's infrastructure, flexible archives, and scheduled WordPress backups, a separate tool complements it.

Configuration Order Without Conflicts

First fully verify API Backups on a test site: access, mapping, creation, provider visibility, and understanding of recovery. Then separately configure a backup plugin on one child site with its own offsite destination. Do not enable several independent heavy jobs at the same time. Otherwise, the server may simultaneously archive large directories, upload files to the cloud, and serve visitors, increasing operation time and the likelihood of hosting restrictions.

Separate jobs by time and purpose. For example, API Backups may be run manually before approved changes, while the independent tool operates on a schedule during a lower-traffic window. Define retention, notifications, and responsibility for both mechanisms. Do not use identical names such as "daily backup" without identifying the source, or it will be unclear where to look for the correct restore point during an incident.

What to Verify in This Combination

Confirm that the two systems do not interfere with one another: no duplicate heavy jobs run at the same time, logs are understandable, and the responsible person knows which layer covers which risk. An operational restore point through API Backups should appear in the provider dashboard. An independent backup should appear in its own log and at the offsite destination. If one layer stops working, do not declare the network protected simply because the other still shows an older successful run.

Rollback also requires a choice. If the issue concerns server configuration or an entire application, the provider's restore point may be more appropriate. If WordPress must be restored from a separate archive in another environment, use the tool that created that archive. Do not mix procedures from memory. Your internal procedure should clearly state which incident type leads to which recovery path and who confirms the decision.

A Safe Improvement Without Custom Code

There is no reason to insert a random PHP snippet or edit MainWP files for API Backups. A more reliable improvement is to keep the site profile and internal log aligned: for each child site, record the provider, resource ID, second-layer strategy, responsible person, and date of the latest test. This is reversible, does not require modifying plugin code, and provides real value when a project is handed to another administrator.

If you need to restrict staff access, use MainWP's native roles and permissions or the provider's permission model instead of emailing a shared API key. Recent MainWP changes introduced more granular permissions for API Backups actions in the team-management extension. Availability of a specific extension depends on your configuration, so first confirm which roles actually exist in your dashboard and test them on a safe site.

Troubleshooting MainWP API Backups: From Symptom to Safe Fix

Backup issues are dangerous not because they always look dramatic, but because they can easily hide behind a generic message or an outdated list of restore points. Good troubleshooting begins not with clicking the button again, but with recording the exact symptom: which site, which provider, what changed beforehand, and at what stage the issue occurred. Verification should then move from the connection and permissions to the resource, from the resource to the available operation, and only then to one controlled retry.

The Restore-Point List Is Empty or Does Not Refresh

Symptom: after opening API Backups, a site has no available restore points even though they should exist in the provider dashboard, or a new restore point does not appear immediately after it is started. Likely causes: an incorrect key, insufficient permissions, an incorrect resource ID, a delayed external operation, or a site that does not match a supported provider.

What to check: first click Refresh Available Backups or its current equivalent and allow the external operation to finish. Then verify the restore point directly with the provider. If it exists there but does not appear in MainWP, record the time, domain, provider type, and a safe description of the error. If it does not exist with the provider either, return to the key, permissions, and child-site profile.

How to fix it: update access or the resource only for the test site, then retrieve the list again. Do not delete the global configuration for the entire network if the error concerns one exception. When to revert the setting: if previously confirmed sites stop working after a key change, temporarily return to the documented working access and investigate the new configuration separately.

An Unspecified Error Appears When Starting an Operation

Symptom: MainWP displays a short error message, does not create a restore point, or the action finishes without the expected record. Such cases are discussed in the MainWP community, but the phrase "unspecified error" is not a diagnosis. It may mean a provider rejection, network issue, role restriction, incorrect mapping, or an operation-state conflict.

What to check: do not send several identical requests in succession. Open the external dashboard and determine whether the operation has already started there. Then check that the selected site matches the resource and that the key has permission to create a restore point. Compare it with a test site at the same provider. If the test site works, the issue is more likely in the local data for that child site than in MainWP overall.

How to fix it: resave only the confirmed incorrect identifier or access setting, refresh the list, and perform one repeat test. When contacting support, provide the time, operation name, a safe excerpt of the message, and provider type, but never provide keys, passwords, tokens, or a full screenshot of secret fields. When to stop: if the operation already exists or is queued with the provider, wait for its outcome instead of launching a duplicate.

cPanel or Plesk Is Connected but Backup Operations Are Unavailable

Symptom: control panel credentials are accepted, but creating or viewing a backup does not work. Likely cause: the hosting policy disables backups, they are unavailable on the specific plan, account permissions are insufficient, or the selected backup type is not provided by the server. For new cPanel installations, MainWP specifically recommends confirming that backup capabilities are enabled.

What to check: sign in to the hosting panel with an authorized account and see whether the required native feature is available outside MainWP. Ask support whether API backup operations are allowed and which restrictions apply to your account. For Plesk, confirm that the integration can access the exact feature you expect, such as WP Toolkit options.

How to fix it: first obtain confirmation from the hosting side, then repeat the test with one site. Do not try to bypass restrictions by changing WordPress files or making random control-panel adjustments. When to choose another path: if the host does not support the required mechanism, use an independent backup plugin with offsite storage rather than creating the appearance of protection through a non-functioning integration.

A Restore Point Exists but Recovery Appears Too Broad

Symptom: before clicking Restore Backup, you discover that the selected restore point applies to a VPS or shared server hosting other sites. Likely cause: a child site was selected in MainWP, but the provider itself works with a snapshot of a larger resource. This is not always a configuration error; it is often a property of the backup type.

What to check: identify which domains, databases, and services are on the instance, what new data appeared after the restore point, and whether it can first be deployed to a controlled target. Review the provider's recovery description. If the information is unclear, do not use an urgent rollback as an experiment.

How to fix it: coordinate recovery with the owners of affected sites, preserve critical new data, and choose a narrower procedure if one is available. When to avoid rollback: if the cost of losing current data or the risk to neighboring sites outweighs the expected benefit, first look for a local fix for the problematic component or a separate WordPress archive.

The Operation Takes Too Long

Symptom: there is no final status row for a long time after starting, and the team is unsure whether the job is stuck. Likely causes: a large resource, provider queue, server load, external API restriction, or a genuinely long server-side operation. MainWP notes that duration depends on site size and hosting speed.

What to check: review the status in the provider dashboard and do not duplicate the task if it is already running. Check whether a migration, import, or another heavy process is running in parallel. Confirm that you have not included sites with radically different sizes and types in one batch.

How to fix it: reduce group size for future work, spread operations across maintenance windows, and start with priority sites. If the provider confirms an issue, use its normal support channel with operation details. When to revise the organizational decision: if a bulk launch consistently overloads the infrastructure, return to small batches and remove heavy or active projects from the shared group.

Previously Connected Sites Stop Working After a Key Change

Symptom: a new secret saves successfully, but the restore-point list for several sites becomes empty or operations are rejected. Likely cause: the new key was created in another account, has fewer permissions, cannot access some resources, or global values replaced required local exceptions.

What to check: compare which sites inherit the global setting and which have their own values. Verify visibility of the servers or applications using the new key with the provider. Do not include the secret in a troubleshooting log. It is sufficient to record its safe name, creation date, and account owner.

How to fix it: restore the documented working configuration for the affected group, then migrate keys one provider and one test site at a time. When to revoke the key: if the secret may have been exposed or belongs to someone who should no longer have access, revoke it according to your security procedure after a tested replacement access method is in place.

The safest troubleshooting order is: symptom - provider verification - key and permission verification - resource mapping verification - one controlled repeat action. It is better than an endless series of repeat requests that make the actual state harder to understand.

Questions That Come Up Before the First Recovery

Do I need a backup plugin on every child site?

The API Backups model works differently: MainWP sends a request to a supported host, cloud management platform, or VPS provider. The MainWP community notes that this approach does not require an additional backup plugin on the child site. However, that does not remove the need for MainWP Child to manage child sites, and it does not prevent you from using a separate plugin as an independent protection layer if needed.

Where Does MainWP API Backups Store the Backups It Creates?

The extension does not define its own storage location. After a MainWP command, the external provider performs the backup and applies its own retention rules. That is why the question "where is the backup stored?" should be directed to the hosting dashboard or cloud-platform documentation. In MainWP, verify that the connection and list are available; in the provider policy, verify retention time, snapshot scope, and recovery capability.

Can I Configure Every Site in the Network with One Key?

Only if all sites genuinely use one provider account and the key has the required permissions for every resource. If some sites belong to another account, run on a separate server, or require different identifiers, use local settings for the relevant child site. A global configuration is convenient, but it must not hide real boundaries between client infrastructures.

Why Does a Restore Point Exist at the Host but Not Appear in MainWP?

First refresh the available restore-point list and wait for the external operation to complete. Then check the key, permissions, and resource mapping. If the restore point is confirmed with the provider but the MainWP list does not change, retain safe troubleshooting details: domain, provider, operation time, restore-point type, and error text. Do not include an access token in a support request or screenshot.

Is API Backups Suitable for a Site with an Active WooCommerce Store?

It can be useful as a confirmed restore point before technical work, but recovery to an earlier state may affect orders, customers, and other current records. Such a site needs a separate plan: who records orders created after the restore point, how the rollback period is handled, and which actions are checked after recovery. Do not use a server snapshot as an unconditional undo button without coordinating with the store owner.

Can a Server Snapshot Be Considered an Independent Disaster-Recovery Copy?

Not always. With different providers, restore points may be stored within the same infrastructure, retained only briefly, exclude attached volumes, or not allow direct archive downloads. For example, VPS-provider documentation describes snapshot limitations separately and recommends treating them as part of a layered strategy. For a critical site, it is useful to add an independent backup in a separate destination and verify both layers.

Do I Need to Test Recovery Regularly?

Yes, although not necessarily on the live site. Plan periodic tests on a controlled copy or another safe target. The goal is to verify more than the presence of a row in a list: confirm the scope, operation timing, verification sequence, and data consequences. After changing a provider, key, or resource setup, repeat this test sooner than the next scheduled review.

A Video That Demonstrates API Backups in Practice

MainWP's official walkthrough shows how API Backups connects the central dashboard to provider backup features and how to create and restore backups from the dashboard. It is useful to watch before your first setup so you can compare the menus with your current dashboard and see the basic path from connection to verification point. The video supports the question of how to use MainWP API Backups, but it does not replace checking the limits of your plan and chosen provider.

While watching, focus on three points: where access to supported infrastructure is added, how the correct resource is assigned to a child site, and which action refreshes the available restore-point list. Then repeat only those steps on a test site, not across the entire production group.

When MainWP API Backups Is a Strong Choice

MainWP API Backups is suitable for a WordPress site network that already uses supported hosting, a cloud management platform, or a VPS provider and needs one safe path to those providers' native backup operations. It provides the most practical value when you do more than create restore points: connect them to changes, confirm them with the provider, and understand the recovery scope in advance.

Start with one test child site: inventory the infrastructure, create dedicated access with the necessary permissions, link the correct resource, refresh the list, run a verification operation, and record the outcome. Then add uniform groups, separating sites by recovery model and avoiding combinations of active stores with ordinary informational projects.

If you need an independent WordPress backup with separate storage, do not treat that as a reason to reject MainWP API Backups. Separate the roles: API Backups for convenient management of native infrastructure restore points, and a separate backup tool for another protection layer. This is more honest than promising that one button will protect against every type of loss.

Once your test chain has been confirmed and the procedure is clear to the entire team, you can download MainWP API Backups and introduce it into your real maintenance process. Establish outcome verification and recovery authority first, then scale management across the whole network.