UpdraftPlus - WordPress Plugin

A Practical Guide to Configuring UpdraftPlus for WordPress Backups, Restores, and Migrations

UpdraftPlus is useful not as "just another plugin in the admin area," but as a practical site recovery plan. In this guide, we will walk through how to prepare WordPress for backups, which settings to enable after installation, how to choose a schedule, where to send your archives, how to confirm that a backup is actually restorable, and what to do if the backup process stops or cannot see your remote storage.

This article is written for a site owner, administrator, developer, or editorial team that needs more than simply clicking Backup Now. The goal is to build a resilient system. That is why this guide covers not only installation, but also scheduling logic, retention of older backups, manual backups before updates, migration to another domain, restoring specific parts of a site, and diagnosing common problems.

You will not find instructions here for purchasing, bypassing licensing, or handling someone else's secrets. If you already have the free version or an installed Premium package, use these sections as a checklist for safe configuration. If you are still choosing a tool, the sections on limitations, similar solutions, and the conclusion will help you decide whether UpdraftPlus is the right fit for your site.

What Problem the Plugin Solves and Where It Helps Most

The main purpose of UpdraftPlus is to create a reproducible backup of a WordPress site and give the administrator a clear path back if an update, editor error, hosting failure, plugin conflict, or failed migration breaks the site. The plugin works with two major parts of WordPress: files and the database. Files include themes, plugins, uploads, and other directories, while the database stores posts, pages, settings, WooCommerce orders, users, and the configuration of many extensions.

In day-to-day use, the workflow looks simple: set a schedule, choose remote storage, save your settings, and periodically check the list of existing backups. But the real value only appears when the backup is not stored on the same hosting account, does not accumulate forever, and is verified before a real emergency happens. A backup should only be considered usable after a clear restore test, or at least after checking the archive contents, the log, and the remote storage location.

UpdraftPlus is especially useful for sites that change regularly but where the team does not want to maintain a separate, complex backup system. That includes blogs, corporate websites, small stores, educational projects, service websites, WordPress landing pages, and client sites where you may need to roll back quickly after a theme or plugin update. For agencies, migration, reporting, multiple remote storage locations, and the ability to schedule files and database backups separately are especially valuable.

That said, the plugin does not replace hosting snapshots, version control, security monitoring, or a staging environment. A strong setup usually includes several layers: automatic backups on the hosting side, UpdraftPlus backups in third-party storage, a manual backup before major changes, and a test restore on a separate environment. If your site generates leads or orders, relying on a single layer of protection is usually not enough.

Who UpdraftPlus Is Best For and When Another Approach Makes More Sense

UpdraftPlus is a good fit for people who want clear, manageable backups from inside the WordPress admin area. Its strength is the combination of manual backups, scheduling, remote storage, restoring from the list of existing backups, and migration. The user can see which site components are included in the archive, download individual file sets, choose what to restore, and review the log if a task does not finish as expected.

Good Use Cases for UpdraftPlus

The plugin works especially well for sites with a predictable pace of change. If content is published several times a week but the database changes more often than the files, you can set a more frequent schedule for the database and a less frequent one for files. If the site is updated before a marketing campaign, a manual backup before changes gives you a clear rollback point. If you need to move the site to another domain, the built-in search-and-replace mechanism for database URLs reduces the risk of manual errors.

• A content team manages the site, and it is important to restore posts, media files, and settings after an accidental change.
• An administrator updates themes and plugins regularly and wants a fresh rollback point before making changes.
• You need to store archives outside the hosting account, in Google Drive, Dropbox, Amazon S3-compatible storage, FTP/SFTP, or another supported service.
• The site is being moved between domains, hosting providers, or environments, and you need a clean replacement of the old address with the new one.
• You need to restore not the entire site at once, but only selected components: the database, plugins, themes, uploads, or another file set.

When One Plugin May Not Be Enough

If the site is very large, stores a lot of video, generates orders every minute, or runs on a limited hosting plan, your strategy should be broader. Backups read files and database tables, compress archives, and write them to disk before sending them to external storage. That is normal load for any WordPress backup process, but on constrained hosting it may show up as timeouts, lack of space, or slow archive uploads.

For an online store with frequent orders, it is worth considering more frequent database protection or a service that offers near-continuous backup. For a large media archive, it is better to separate media strategy, configure a reasonable archive chunk size, and avoid relying on email delivery. For team-based development, it is best to keep theme code and custom plugins in a repository, while using UpdraftPlus for the database, uploads, and emergency rollback.

Practical rule: if losing a day's worth of data is already unacceptable, do not choose a "once a week" schedule just because it is easier. Base your schedule on how many posts, orders, leads, and settings you can afford to lose during a restore.

What to Check Before Installation and the First Run

Before installing the plugin, it is better not to start with the Install Now button. First evaluate the environment. UpdraftPlus runs inside WordPress and depends on whether the hosting account has enough space, sufficient PHP execution time, access to the backup directory, a working connection to external storage, and a functioning WordPress scheduler. That is not unique to this plugin; it is simply how application-level backup systems work.

Disk Space and Site Size

Even if archives are sent to the cloud, the plugin still needs to assemble zip files temporarily on the hosting account. The larger your uploads directory is, and the more archives, videos, design source files, and imported files the site contains, the heavier the disk load will be. If the site already uses a large portion of the available space, first check your quota in the hosting panel and remove obvious clutter: old staging copies, exports, duplicate archives, and temporary directories created by other plugins.

For large sites, it is especially important not to mix up two questions: "Can the plugin technically create a backup?" and "Is this the right way to create it?" UpdraftPlus can split large archives into parts, but if your hosting environment constantly hits limits, it is better to reduce the archive part size in the expert settings, move heavy media to a separate storage system, or discuss resources with your provider.

Access to Remote Storage

Keeping a backup only inside the site directory is risky. If the site is deleted, infected, or locked, the local copy may disappear with it. So before you set up your first schedule, decide where the backup will live remotely. For a small site, Google Drive or Dropbox is usually enough. For an agency, store, or project with stricter access rules, it is better to consider S3-compatible storage, a separate FTP/SFTP server, or another option you can control independently of WordPress.

Do not share remote storage secrets with contractors unless absolutely necessary. If you are connecting an OAuth service, authorize it from an account owned by the project owner or the company. If you are using SFTP, make sure the login only has access to the required directory, not to the whole server. A backup often contains more sensitive data than the public-facing part of the site.

WordPress Scheduler and Traffic

Automatic WordPress tasks depend on the WP-Cron mechanism. On sites with little or no traffic, tasks may not run at the exact scheduled time. On private sites, staging environments, or projects behind basic authentication, automatic execution may also behave differently. If scheduling is critical, verify that the scheduler is not disabled in wp-config.php and that your hosting environment or system cron is actually triggering WordPress tasks.

For most standard websites, it is enough to start with a simple schedule and then review the log of the first automatic backup. If backups only start when the settings page is open, that is a sign to check cron, loopback requests, and hosting restrictions, not to keep clicking the manual button forever.

Installation and Initial Verification in the WordPress Admin Area

The free version installs like any standard WordPress plugin: open Plugins, click Add New, search for UpdraftPlus, install it, and activate it. After activation, go to Settings - UpdraftPlus Backups. In a Premium scenario, if the package was obtained through official channels, installation is done by uploading the ZIP file via Plugins - Add New - Upload Plugin. If the free version was installed before that, follow the official replacement instructions so that you do not end up with two versions at the same time.

After activation, do not rush into complex rules. First check three things: the plugin page opens without errors, the Backup / Restore tab shows the Backup Now button, and the Settings tab allows you to save changes. If the interface does not respond, modal windows stay dimmed, or buttons cannot be clicked, the issue may be an admin script conflict, admin-side caching, or blocking by a security module.

Minimal Manual Backup

Your first test should be manual. Open Backup / Restore, click Backup Now, enable both database and file backup, and you can leave remote storage upload disabled for now if it has not been connected yet. Wait for the process to finish and check whether archive parts appear in the Existing backups section. You will usually see separate buttons for the database, plugins, themes, uploads, and other files.

This test answers a basic question: can the site assemble a backup at all in the current environment? If it fails, there is no point in connecting Google Drive or setting up complex retention rules right away. First open the log, find the last meaningful error, and fix the issue related to directory permissions, disk space, execution time, or a conflict.

Where to Find the Log

If something goes wrong, the log matters more than a generic "failed" message. Links to logs are available in the UpdraftPlus interface, and with some settings reports can also be sent by email. If the admin area is unavailable, the log can often be found in the wp-content/updraft directory. Do not read every line in order. Focus on the last events before the process stopped: remote storage activity, zip part creation, database reading, a timeout, a write restriction, or an HTTP error.

Best UpdraftPlus Settings After Installation

Detailed configuration starts on the Settings tab. That is where you define file and database schedules, the number of stored backups, remote storage destinations, archive contents, and additional parameters. A good setup does not have to be maximal. It has to match the site's change frequency, the limits of the hosting environment, and the cost of losing data.

File and Database Schedule

UpdraftPlus provides separate File backup schedule and Database backup schedule settings. This matters because files and the database change at different rates. If you publish articles with images once a week, but comments, leads, or orders are added every day, the database needs more frequent backup than the files. For a typical site, a good starting point is daily database backups and weekly file backups. For a store, the database usually needs to run more often, especially if orders are not duplicated in an external system.

Premium features extend scheduling options: you can choose a specific start time, use incremental backups, and set more advanced retention rules. It is best to schedule backups during low-traffic hours. If you run multiple sites on the same hosting plan, do not start them all at once. Stagger their schedules by at least a few hours, otherwise the backups themselves will create a load spike.

Number of Stored Backups

The number of backups is a balance between rollback depth and storage use. Keeping only the latest backup is risky: if it was created after the site was already broken, you have nowhere to roll back to. Keeping dozens of full backups with no cleanup rules is expensive and difficult to manage. For a typical site, it makes sense to keep several recent backups and at least one older restore point. Premium retention rules let you keep fewer older frequent backups by grouping them according to age.

Check not only the remote storage but also the local directory. If temporary local archives are not being cleaned up, or the hosting account fills up, new backups may stop being created. After you configure retention, it is useful to review the results after a few cycles and make sure older sets are actually being deleted the way you expected.

Remote Storage

Choose one primary remote service and get it fully working first. Select the desired option on the Settings tab, save your changes, complete authorization, and return to WordPress to finish the connection. Then run a manual backup with upload enabled for that storage and confirm that the files appear not only in the UpdraftPlus interface but also in the storage service itself.

If you use Google Drive or Dropbox, remember that reauthorization may be required after changing accounts, removing the app, resetting a token, or encountering an access error. If you use SFTP/FTP, enter the actual host, port, login, path, and keys, not a browser page URL. Recent plugin versions also warn about some invalid host formats, but it is still best to store connection parameters in proper technical form from the start.

Archive Contents and Exclusions

By default, a backup usually includes the database, plugins, themes, uploads, and other important WordPress files. But not everything inside the site is equally useful. Caches, temporary directories, old export archives, local copies from other backup plugins, and large service files can bloat the archive without adding value. Add exclusions carefully: do not exclude uploads entirely if it contains post images, product documents, or user files.

A good way to configure this is to review the site structure over FTP or in a file manager and determine which directories are actually needed for recovery. If you are unsure, it is safer to leave a directory in the archive and optimize the schedule later than to end up with a backup that is lightweight but useless. For a site with a large media library, it is worth planning media storage and zip part size separately.

Reports and Integrity Checks

Reports are useful if you do not log in to the admin area every day. In Premium mode, advanced reports may include more diagnostic details and checksums. But even basic email reports should go to an address someone actually reads. If a failure alert goes to a shared mailbox with no responsible owner, it does not protect the site.

After saving your settings, always run a manual verification backup. Do not wait for the first overnight schedule. A manual run will immediately show whether the site has the required permissions, space, execution time, and remote storage access. After it finishes, open Existing backups, check the backup parts, download one small part or inspect the file in the cloud, and then open the log.

How to Configure Remote Storage Without Unnecessary Risk

Remote storage is not a decorative option. It is the main way to survive a problem with the server itself. If the backup only exists in wp-content/updraft, it may help after a bad update, but it offers much weaker protection against account deletion, hosting compromise, total disk loss, or blocked access. In a practical setup, at least one copy should always be stored offsite.

Google Drive and Dropbox for Smaller Sites

For a service website, blog, or small storefront, Google Drive and Dropbox are convenient because they connect through OAuth and do not require separate server-side setup. You choose the service, save the settings, complete authorization, return to the site, and finish the connection. Then create a manual backup and check the app folder in the cloud. If the file does not appear immediately, wait for all parts to finish uploading and then review the log.

The downside of this approach is dependence on a personal or corporate account. If an employee leaves, loses access, or removes the application from the cloud account, backups may stop uploading. For a company project, it is better to use an account owned by the organization and document where the archives are stored, who has access, and who receives the reports.

S3-Compatible Storage for a Managed Setup

S3-compatible storage is useful when you need control over permissions, storage region, object lifecycle, and access for multiple sites. In that kind of setup, it makes sense to create a dedicated bucket or project-specific prefix, grant only the minimum required permissions, and avoid using a key that has access to all corporate data. If the service supports storage classes, do not blindly choose the cheapest option: restoring from an archival class may be slow or incur extra cost.

If the project has personal data protection requirements, evaluate separately what goes into the WordPress database: users, forms, orders, email addresses, physical addresses, integration tokens. Premium features such as database encryption and data anonymization may be useful, but they should be validated in a test restore. Encryption without the saved key turns a backup into a file that cannot be read.

Multiple Storage Locations

The Premium option to send backups to multiple locations is useful for projects where a single failure should not break the recovery plan. For example, the primary copy might go to S3, while a secondary one goes to UpdraftVault or another independent storage destination. But more storage locations also mean more tokens, more failure points, and more oversight. Do not enable multiple destinations if nobody is going to verify that they still work.

With several storage locations, it helps to assign roles: one for fast restores, one as protection against losing access, and a third for long-term archiving if you truly need it. On paper, that sounds obvious. In practice, many problems begin with a chaotic set of connections where nobody knows which copy is the newest or where it is supposed to be found.

Backups Before Updates, Incremental Archives, and Partial Restores

UpdraftPlus includes several capabilities that distinguish a thoughtful backup strategy from a simple "save a zip once a week" routine. Not every site needs all of them, but you should understand them before a real incident happens. The most important for practical use are automatic backups before updates, incremental backups, restoring selected components, migration with URL search-and-replace, and reporting.

Automatic Backup Before Updates

WordPress, theme, and plugin updates are among the most common moments when a site breaks. An automatic pre-update backup is valuable because it gives you a short, precise rollback point. If a plugin update conflicts with the theme, you can return the site to the exact state it was in before the change, rather than relying on an overnight backup created before new leads or edits came in.

This feature is worth enabling on sites where updates are launched from the admin area and there is a real risk that an editor will click Update without manual preparation. But it is not a substitute for a staging environment. If the change is major, such as updating a page builder, WooCommerce, a store theme, or a set of business-critical plugins, it is better to test it on staging first, then create a manual backup, and only after that update the live site.

Incremental Backups

Incremental backup stores changes relative to the previous full backup instead of creating a complete archive every time. This reduces server load and storage usage, especially on large sites with heavy uploads directories. But that kind of setup requires discipline: a base full backup must exist, and the change chain must be available during restore.

For a site with a large media library, a useful combination is a periodic full backup, a more frequent database backup, and incremental file changes. For a smaller site on solid hosting, full backups may be simpler and easier to understand. Do not choose incremental archives just because the term sounds more advanced. Choose them when there is a real problem with size, execution time, or server load.

Restoring Selected Components

Restore does not always mean "bring back everything." Sometimes you only need to roll back plugins after a failed update, only the theme after a template change, or only the database after a large content error. UpdraftPlus lets you choose which components to restore. That lowers the risk of overwriting more than necessary, but it also requires understanding the consequences.

If you restore the database, you may lose new posts, orders, comments, and settings created after the selected backup. If you restore uploads, you may remove recently added media files. For that reason, before a partial restore it is wise to create a current emergency backup of the site "as is," even if it is broken. You may need it later to recover specific new data after the rollback.

Practical Scenario: Protect the Site Before an Update and Migration

Let us walk through a scenario that often comes up for WordPress site owners: the site needs to be updated and then moved from a staging domain to the primary one. The goal is to create a working backup, update plugins safely, migrate the site, and confirm that no references to the old address remain after the move.

Goal and Preparation

We need a site that can be returned to its original state if the update or migration breaks the public-facing version. Before you begin, verify access to the admin area, make sure remote storage is working, confirm available disk space, and check that the site can be opened at the new address. If this is a WooCommerce store, choose a low-activity period, warn the team, and do not migrate during a promotional peak.

Steps

1. Open Settings - UpdraftPlus Backups and on the Settings tab review the schedule, remote storage, and the number of retained backups.
2. On the Backup / Restore tab, click Backup Now, include both the database and files, and send the backup to remote storage.
3. Wait for completion, open Existing backups, and confirm that the archive parts are visible: database, plugins, themes, uploads, and other files.
4. Open the log and make sure there are no warnings about incomplete upload, timeouts, unavailable storage, or insufficient space.
5. Update WordPress, the theme, or plugins. After each critical update, test the homepage, form, cart, or any other important site workflow.
6. On the new site, install UpdraftPlus, upload or pull in the backup from remote storage, and start the restore.
7. If the migration is going to another domain, enable the database search-and-replace option for the site address so old links do not remain in content or settings.

Verifying the Result

After migration, do not check only the homepage. Open several posts, a page with a form, the login page, the media library, a product page, or the cart if WooCommerce is present. In the admin area, check permalinks, theme settings, the remote storage connection, and the list of existing backups. If internal pages return 404 errors, first resave permalinks, then confirm whether the old address was replaced correctly.

It is also worth checking the database for the old domain if you have a tool for that. The previous address can remain in widgets, builder settings, serialized data, or cache. UpdraftPlus uses a search-and-replace mechanism during migration, but after a complex move it is still wise to do a verification pass.

A WooCommerce-Specific Note

The official documentation points out that WooCommerce stores its data in the WordPress database and media files, so the mere presence of WooCommerce does not make migration impossible. The real risk is different: new orders may appear during the migration window. If the store is active, create a maintenance window, temporarily stop accepting orders, or use a workflow where the database does not diverge between the old and new sites.

How to Confirm That a Backup Is Actually Usable

The most common mistake is assuming that a green checkmark after backup means guaranteed recovery. In practice, you need to validate several layers: the archive was created, all parts are present, remote storage received the files, the log contains no critical errors, and the site can be restored on a test environment or at least imported into UpdraftPlus as a complete set.

Checking the Backup Contents

In Existing backups, you should see the parts that match your configuration: database, plugins, themes, uploads, and other components. If the database is present but uploads are missing, ask yourself whether that was an intentional exclusion. If archives exist locally but were not sent to remote storage, that is not full protection against a hosting failure. If archive parts are unusually small or missing, open the log and check whether the process stopped while reading a specific directory.

Checking Remote Storage

Log in to the storage service and locate the files from the latest backup. Do not rely only on the WordPress interface: sometimes WordPress shows the task as completed even though remote storage did not receive every part because of a network error or quota issue. For OAuth services, verify that the correct account is connected. For SFTP, check that files are in the expected directory rather than the user's home folder.

Test Restore

The ideal test is to restore the backup on a separate environment. That can be a staging site, temporary subdomain, local development environment, or a separate test WordPress installation. Do not restore over the live site just for testing unless there is a real reason to do so. On the test environment, verify admin login, public pages, media files, forms, cart behavior, and critical integrations.

Bottom line: if you have never tested a restore, you may have hope in your backup, but you do not yet have a proven recovery procedure.

Site Migration and Finding Old URLs in the Database

Migration in UpdraftPlus is built around creating a backup and restoring it in a new location. In the simplest scenario, you create a backup on the source site, move the backup set to the new WordPress installation, run the restore, and if necessary perform a search-and-replace from the old address to the new one. This is especially important when a site moves from a staging domain, local address, or temporary hosting URL to the main domain.

The free version is suitable for straightforward one-off migrations where the administrator is willing to download the archives from the original site and upload them to the destination site. Premium migration makes the process more direct and more convenient for moves between connected sites, while also adding more options for complex projects. But even in the simple version, you cannot skip post-restore verification.

What Search and Replace Does

During a WordPress migration, the database still contains references to the old address: images, internal links, theme settings, some builder parameters, widgets, menus, and cached values. Search and replace swaps the old URL string for the new one during migration. It is important to enable this option specifically when moving to a different URL, not during a standard restore on the same domain.

If you skip this step, the site may appear to open normally, but some links, images, styles, or redirects will still point to the old domain. The symptoms usually look like this: the homepage works, internal pages fail, images load from the old address, admin login redirects incorrectly, or parts of the page builder layout appear broken.

Safe Migration Order

1. Create a fresh backup of the source site and store it in external storage.
2. Make sure the destination site is clean or ready to be overwritten, because restore may replace existing data.
3. Import the archive set using Upload backup files or connect the same remote storage and run a rescan.
4. Start the restore, choose the required components, and enable address search and replace if the domain is changing.
5. After restore, resave permalinks, clear caches, and verify the public-facing pages.

If the site includes a store, forum, member area, or LMS, do not migrate it as if it were a static brochure site. Define a data freeze point, otherwise the old site may continue receiving new user activity after the backup has already been created. In that situation, maintenance mode, a temporary order pause, or a more specialized migration workflow is helpful.

Limitations, Security, and Impact on Site Performance

UpdraftPlus does not load itself into the public site like a visual plugin, but the backup process still consumes server resources. It reads files and database rows, creates zip archives, writes temporary parts to disk, and sends them to remote storage. On a small site, this may be almost invisible. On a large site with heavy media and weak hosting, it can become a noticeable operation.

Load and Timing

Schedule automatic backups during low-traffic periods. If you are on shared hosting, do not run backups at the same time as product imports, cache generation, bulk email campaigns, inventory sync, or security scans. If the site becomes slow during backup, first check archive size, zip split size, exclusion rules, and backup timing. Then decide whether you need incremental mode or stronger hosting.

Protecting Backups

A database archive may contain email addresses, physical addresses, orders, password hashes, integration tokens, payment settings, and other sensitive data. For that reason, access to remote storage should be restricted. Do not keep backups in a public folder on the site. Do not send archives over regular email if the file size and the sensitivity of the data make that a poor choice. If you enable database encryption, store the key in a reliable place and verify that the team knows the recovery procedure.

Removing the Plugin and Leftover Settings

Before removing any backup plugin, you need to understand what will happen to settings, local archives, and schedules. If you are changing backup strategy, first make sure the older archives have been moved or are no longer needed. Do not delete the backup directory until the new system has completed at least one full create-and-verify cycle.

A backup plugin is not a complete security system. It helps you recover after a problem, but it does not prevent a hack, a vulnerable extension, a weak password, or a permission mistake. Real protection requires updates, restricted administrator privileges, two-factor authentication, a security plugin or WAF, monitoring, and a clear recovery procedure.

Common UpdraftPlus Errors and How to Diagnose Them

The diagnostics section is best read before panic sets in, not during it. Most problems repeat themselves: the directory is not writable, remote storage is not authorized, the backup is too large, the server cuts the process off, the WordPress scheduler does not resume the task, or old URLs remain after migration.

The Backup Now Button Is Unavailable or the Directory Is Not Writable

Symptom: the manual start button is disabled, you see a message that the backup directory is unavailable, or the log reports a write error.

What to check: open the UpdraftPlus settings, find the backup directory parameter in the expert section, and review the path and permissions. By default, local files are often stored in wp-content/updraft. If the directory was created by the wrong user or the permissions are too strict, PHP will not be able to write the archive.

How to fix it: restore correct permissions through the hosting panel or ask hosting support to check file ownership. Do not use unsafe permissions just to get the job running quickly. After the fix, run a small manual backup and make sure the file is created.

The Backup Starts but Stops Halfway Through

Symptom: the process starts, creates one or more parts, and then stops progressing for a long time. In the log, the last lines may keep pointing to the same stage or show that no further resumes happened.

Possible cause: execution time limits, weak hosting, an oversized file, a broken scheduler, or loopback request problems. UpdraftPlus tries to split the task and resume it, but the WordPress environment must allow those resumes to happen.

What to do: reduce archive part size in the expert settings, exclude obviously unnecessary temporary directories, schedule the run at night, check WP-Cron, and ask your hosting provider about PHP limits. If the issue only happens in a huge uploads directory, consider a separate media strategy.

Remote Storage Is Not Accepting Files

Symptom: the local copy is created, but Google Drive, Dropbox, SFTP, or S3 does not receive all parts. You may see authorization errors, a full quota, or an incorrect path.

What to check: open the log and find the lines related to remote storage upload. For OAuth services, repeat the authorization. For FTP/SFTP, verify the host, port, login, path, key, and write permissions. For S3, verify the region, bucket, endpoint, and key permissions.

When to roll back the configuration: if the new storage destination keeps failing, temporarily return to a known working service, but do not leave the site without an offsite copy. One reliable external recovery point is better than three unstable connections.

Not All Pages Work After Migration

Symptom: the homepage opens, but internal pages return 404 errors, images load from the old domain, or some links still point to the staging address.

Possible cause: URL search and replace was not performed in the database, permalinks were not resaved, cached data is serving old paths, or server rules were not updated.

How to fix it: check whether you enabled the search-and-replace option when restoring to the new domain. Then resave Permalinks, clear the WordPress cache, the hosting cache, and the CDN cache. If the problem remains, search for the old domain in the database and the builder settings.

Backup Is Too Slow

Symptom: the backup takes a long time, the site becomes noticeably heavier while it runs, and the log shows large archive parts or slow upload speed.

What to check: the size of uploads, the presence of large videos and archives, remote storage speed, hosting limits, and whether other heavy tasks are running at the same time. If the site is large, reduce split part size and consider incremental backups. If the problem is a slow external service, test a different storage provider.

When UpdraftPlus Is the Right Choice

UpdraftPlus is a strong choice if you need a clear backup system inside WordPress: scheduled backups, a manual backup before changes, remote storage, restore from an archive list, and migration without manual database editing. The plugin is especially useful when the site owner wants to see exactly which parts were saved, where the files are stored, and how to return to a working version.

Before you consider the setup finished, go through a short verification checklist: a manual backup has been created, remote storage received all parts, the log contains no critical errors, schedules are spread appropriately for the site's load, the number of retained backups is reasonable, and the restore procedure has been tested at least once on a staging environment. If all of that is in place, you can move to everyday use and, if needed, get the WordPress version from the download section on the page.

If the site is large, receives frequent orders, or runs on limited hosting, do not stop at a basic installation. Set separate schedules for files and the database, plan remote storage carefully, evaluate incremental backups, document access, and run test restores regularly. In that case, UpdraftPlus becomes more than just a "create backup" button. It becomes part of a real WordPress recovery plan.