Configuring scheduled WordPress backups with UpdraftPlus (free vs Premium)

UpdraftPlus is the most-installed WordPress backup plugin, with more than 3 million active installations on the WordPress.org directory. Most operators install it, click Backup Now once, and assume scheduled backups are running off to remote storage on autopilot. They usually are not. The plugin defaults to local-only storage, the schedule depends on a part of WordPress that frequently fails to fire, and the word "incremental" in UpdraftPlus marketing means something narrower than most readers expect. This article walks through the configuration that actually produces a scheduled, off-site, verifiable backup, and is explicit about which features need a Premium licence and which do not.

If you are still deciding what to back up and how often before reaching for a tool, start with WordPress backup strategy: what to back up and how often. This article assumes you have already made those decisions and now need to translate them into a working UpdraftPlus configuration.

What "incremental" means in UpdraftPlus (and what it does not)

This is the section I wish someone had given me before I bought a Premium licence expecting rsync-style differentials. Two facts to be precise about.

Incremental backup is a Premium-only feature. The free version takes a full backup every time the schedule fires. TeamUpdraft's free vs Premium comparison and the incremental backups documentation state this plainly: incremental capability is exclusive to UpdraftPlus Premium. If you are on the free tier, every scheduled run produces a complete copy of plugins, themes, uploads, and wp-content/others, regardless of whether anything has changed since the previous run.

Even on Premium, "incremental" applies to files only. The database is always full. UpdraftPlus's incremental tickboxes are limited to plugins, themes, uploads, and other directories inside wp-content. Database dumps cannot be incremental. The vendor explains the design constraint in their own words: tracking changes at the level of individual records and transactions would be "complex and resource intensive" and would require a dedicated change-tracking system that the plugin does not implement. So even on Premium, every scheduled database backup is a complete mysqldump of every WordPress and plugin table.

This matters for two reasons. First, it changes the storage and bandwidth math: for a site with a 500 MB database and a 50 GB uploads directory, "incremental" mostly saves uploads bandwidth, not database bandwidth, because the database dump is small relative to the uploads in the first place. Second, the marketing phrase "incremental backups" anchors a different mental model than what UpdraftPlus actually does. If you want true incremental database protection (binary log shipping, point-in-time recovery, or per-row change capture), UpdraftPlus is not that tool, and no WordPress plugin in this category is. That is a job for the database server.

For most WordPress sites the practical takeaway is simple: pick a schedule that produces a complete backup at the cadence you can recover from, and treat "incremental" as a Premium optimisation that reduces upload time on large media libraries, not as a feature that fundamentally changes how often you can take backups.

Choose what to back up: files, database, both

UpdraftPlus splits backups into two independent streams that you schedule separately: a database backup and a files backup. The reason is operational, not cosmetic. The database changes constantly on an active site (every comment, every WooCommerce order, every plugin option write); the uploads directory changes slowly. Treating them as one unit wastes bandwidth pushing unchanged uploads to remote storage every time a comment is approved.

The default "files backup" set in UpdraftPlus contains four checkboxes, all under wp-content:

• Plugins (wp-content/plugins/): every plugin file. Free plugins can be reinstalled from wordpress.org, but commercial plugins require a licence lookup. Always include this.
• Themes (wp-content/themes/): your active theme, child theme, and any uploaded but inactive ones. If a developer built you a custom theme, this is the only copy of their work.
• Uploads (wp-content/uploads/): every image, PDF, video, and media attachment ever uploaded. This is normally the largest single directory and the only one that cannot be reconstructed from anywhere else.
• Others (everything else inside wp-content/): mu-plugins/, languages/, custom drop-ins, and anything plugins have written outside the standard directories. Leave it ticked unless you have a specific reason not to.

Note what is not included by default. UpdraftPlus does not back up WordPress core files (wp-admin/, wp-includes/, the root PHP files), because those can be reinstalled from wordpress.org. It does not back up wp-config.php by default either, although there is an Include in files backup option to add it. The TeamUpdraft restore documentation is explicit about this: "UpdraftPlus only backs up what is specific to your site: database, media, plugins and themes. It does not back up [WordPress core] files." A full disaster recovery therefore needs an UpdraftPlus restore on top of a fresh WordPress core download, not just an UpdraftPlus restore on its own.

Install UpdraftPlus and set the global schedule

Prerequisites:

• A WordPress site running 5.6 or newer (UpdraftPlus 1.26.x supports WordPress 5.6+). On a current site you are almost certainly on 6.x.
• PHP 7.4 or newer.
• Administrator access to the WordPress dashboard.
• A free Google account, Dropbox account, or other supported destination ready to receive backups.

Steps:

1. In the WordPress dashboard, go to Plugins > Add New Plugin. Search for UpdraftPlus and install the plugin authored by David Anderson / Team Updraft. Activate it.
2. Go to Settings > UpdraftPlus Backups. The plugin opens on the Backup / Restore tab.
3. Click the Settings tab.
4. Under Files backup schedule, choose your cadence. The free tier offers Manual, Every 2 hours, Every 4 hours, Every 8 hours, Every 12 hours, Daily, Weekly, Fortnightly, and Monthly. These intervals are listed on the UpdraftPlus WordPress.org page. Set Retain this many scheduled backups to a value that gives you at least two weeks of history; 14 is a sensible minimum for daily files backups.
5. Under Database backup schedule, set the cadence independently. Database backups are smaller and faster, so a higher frequency is cheap. Daily is the floor for any active site; every 4 hours is reasonable for a busy publisher; hourly is appropriate for a WooCommerce shop. Retention 30 for database backups is a good default.
6. Leave the four file-type checkboxes (Plugins, Themes, Uploads, Others) ticked under Include in files backup. Do not untick Others unless you know exactly what is in there and have a reason; it includes things like mu-plugins, language files, and custom drop-ins.
7. Scroll to the bottom of the page and click Save Changes.

Expected output: The page reloads and the Settings tab now shows your selected schedules. Above the schedule fields, a notice will appear stating that the next scheduled backup will run on a specific timestamp. Do not assume that timestamp is accurate. It is the time at which UpdraftPlus has registered a scheduled event with WordPress, but whether that event actually fires depends on WP-Cron, addressed in the verification section below.

A note about Premium scheduling. The Premium tier adds Choose the specific time of day from which to start your backups so you can pin runs to off-peak hours, plus a separate incremental backup interval that runs in between full file backups. The free tier runs whenever the next interval lapses after the previous run, which usually drifts. The TeamUpdraft scheduling documentation covers both behaviours.

Connect a remote storage destination

A backup that lives in wp-content/updraft/ on the same server as the live site is not a backup. The first compromise that gives an attacker write access to wp-content/ gives them the ability to delete the backups; the first hardware failure that loses the server loses the backups with it. UpdraftPlus stores backups locally by default, and they only move off-server after you configure a remote destination.

The free vs Premium split for destinations matters here, because the brief I see most often (and probably what brought you to this article) does not match what UpdraftPlus actually offers for free.

Free tier destinations (per the WordPress.org listing and the free vs Premium page):

• Google Drive
• Dropbox
• Amazon S3 (or S3-compatible)
• Rackspace Cloud Files
• DreamObjects
• OpenStack Swift
• FTP
• Email

Premium-only destinations:

• Microsoft OneDrive
• Microsoft Azure
• Google Cloud Storage
• Backblaze B2
• SFTP
• SCP
• WebDAV
• pCloud
• UpdraftVault (UpdraftPlus's own hosted storage)

A common misconception worth flagging: Amazon S3 is in the free tier. Plain S3 with credentials and a bucket name works on the free version. What you lose without Premium are the S3 Enhanced features: the Infrequent Access storage class (around 40% cheaper for backup-shaped data), automatic server-side encryption configuration, and the IAM helper that creates a restricted user with access to only the backup bucket. You can still configure all of those manually in the AWS console while running UpdraftPlus free; you just have to set them up by hand instead of through the plugin UI.

The honest tradeoff for SFTP. SFTP is the natural choice for "back up to my own VPS over an SSH key" and the absence of SFTP from the free tier is the single most common reason people end up paying for Premium. There is no free SFTP workaround inside UpdraftPlus. If you have SSH access to a remote server and want SFTP without paying, the practical alternative is to leave UpdraftPlus on local-only storage and pull the backups off with rsync from the remote box on its own schedule. That moves the offsite-storage responsibility out of WordPress and into a server-level cron job, which is fine, just different.

Steps to connect Google Drive (the most common free choice):

1. Stay on the Settings tab in UpdraftPlus Backups.
2. Under Choose your remote storage, click the Google Drive icon. The free tier limits you to one selected destination at a time; Premium allows multiple simultaneous destinations.
3. Scroll to the bottom of the page and click Save Changes.
4. The page reloads with a yellow notice at the top of the Settings tab: Follow this link to authorize access to your Google Drive. Click that link.
5. Complete the Google OAuth flow. Grant UpdraftPlus access to its own application folder on Drive (not your full Drive). Confirm the redirect back to your WordPress site, where UpdraftPlus will display Success: you have authenticated your Google Drive account.

Steps to connect Dropbox or FTP follow the same pattern: pick the destination icon, save, follow the authorization prompt. For FTP, you enter host, username, and password directly into the UpdraftPlus settings rather than completing an OAuth flow.

Verify the destination works: click Backup Now from the Backup / Restore tab, tick both Include the database in the backup and Include any files in the backup, then Send this backup to remote storage, and run. After the backup completes, refresh the Existing Backups section and click the cloud icon to confirm the upload status. A successful run shows a green tick next to each component (Database, Plugins, Themes, Uploads, Others) and the Google Drive folder path in the upload metadata.

Verify the schedule actually fires (the WP-Cron dependency)

This is the part of UpdraftPlus that catches most operators by surprise, and the part that is responsible for the largest share of "my backups stopped working" support tickets.

UpdraftPlus does not run on its own clock. It registers events with WP-Cron, which is WordPress's built-in pseudo-scheduler. WP-Cron is not a real cron daemon. It only fires when a visitor lands on the site, and it has well-documented failure modes that mean scheduled events can silently never run on low-traffic sites or sites where the loopback HTTP request is blocked. The official WordPress Plugin Handbook entry on WP-Cron is explicit: "Scheduling errors could occur if you schedule a task for 2:00PM and no page loads occur until 5:00PM."

For UpdraftPlus this means: if your site gets one or two visitors a day, and they happen to visit at noon every day, but you scheduled a 02:00 backup, the backup runs at noon (when the next visit triggers WP-Cron), not at 02:00. Or, if something is blocking WordPress from making a loopback HTTP request to itself, scheduled backups silently never run at all, and there is no error message anywhere in the dashboard to tell you.

How to check whether UpdraftPlus's scheduled events are registered. UpdraftPlus 1.25.2 (released 26 February 2025, per the changelog) added a Cron events tab inside Advanced Tools for exactly this diagnosis. To use it:

1. Go to Settings > UpdraftPlus Backups.
2. Click the Advanced Tools tab.
3. Click Cron events. UpdraftPlus shows a list of its registered events with their next scheduled run time.

Expected output: at least one entry called updraft_backup (file backups) and one called updraft_backup_database (database backups), each with a Next run timestamp in the near future based on the schedule you set. If either is missing, the schedule did not register and the plugin will not run scheduled backups.

How to check whether the events actually fire. Registered is not the same as fired. Two practical checks:

1. After you set the schedule, wait until just past the registered next-run time, then refresh the Existing Backups list and look for a new entry with that timestamp. If nothing new appears, WP-Cron did not fire the event in time.
2. From the wp-admin dashboard, install the WP Crontrol plugin (free, on the directory). After activating it, go to Tools > Cron Events. WP Crontrol shows every WP-Cron event with its registered next-run time and lets you trigger one manually. If updraft_backup consistently shows a Next run timestamp that is in the past every time you check, WP-Cron is broken on your site.

If WP-Cron is broken, that is a separate problem with its own diagnosis path. The full failure-mode list and the replacement procedure (running WordPress's wp-cron.php from a real system cron job instead) is in WordPress wp-cron: why it fails and how to replace it. On a low-traffic or strictly-firewalled site this is not optional; it is the only way to get scheduled UpdraftPlus backups to fire reliably.

How to confirm the latest backup actually uploaded

A backup that finished writing to local disk but never reached remote storage is invisible to most operators because the dashboard shows "backup successful" either way. The actual question to ask is: did the upload to remote storage complete?

In the Existing Backups list, each row has columns for each component (Database, Plugins, Themes, Uploads, Others). Each component shows either a green tick or a yellow warning icon. Hovering over the icon reveals the upload status. A complete upload to Google Drive shows Database: backed up; Sent to: Google Drive and similar for the four file components. A backup that ran locally but never uploaded shows the green tick for "backed up" but is missing the Sent to: line.

Two failure modes worth knowing about. First, UpdraftPlus does not verify backup integrity after upload on the free tier. It does not download the file back, it does not compute a checksum, it does not compare what arrived in Google Drive against what left the server. The cryptographic-checksum verification feature is Premium-only, per the features page. On the free tier, "the backup uploaded" means the upload HTTP request returned a success response; whether the bytes that arrived match the bytes that left is your responsibility to spot-check.

Second, UpdraftPlus deletes backups according to retention only after the upload is confirmed by the remote provider. If your Google Drive is full, or your Dropbox quota is exceeded, or your FTP credentials silently became invalid, the plugin keeps producing local backups but they never leave the server. Eventually the local wp-content/updraft/ directory grows large enough to itself become a problem.

Once a month, do this manual check:

1. Open the cloud destination directly (Google Drive in your browser, the Dropbox app, the S3 console).
2. Confirm a backup file from yesterday or the day before is present, and roughly the size you expect.
3. Download one of the smaller archives (-themes.zip or -others.zip are usually small) to your laptop and unzip it. If the archive opens and contains the files you expect, the upload is real. If it is corrupt, your retention policy will have already destroyed any earlier good copies and you have a problem to solve.

Five minutes a month, and you find broken backups while they are still recoverable instead of during an actual incident.

What gets backed up (and what does not)

A precise inventory, because the gap between what people assume UpdraftPlus does and what it actually does is where most "I had a backup but the restore was broken" stories come from.

Included in a default UpdraftPlus backup:

• The full WordPress database (every table, including custom tables created by plugins like WooCommerce).
• wp-content/plugins/
• wp-content/themes/
• wp-content/uploads/
• wp-content/ other directories (mu-plugins, languages, custom drop-ins, anything else under wp-content/ that does not match the previous three boxes).

Not included by default, but available as opt-in:

• wp-config.php. Add it via the Include in files backup section by ticking Any other directories found inside wp-content/ and additional paths. This file contains database credentials and secret keys, so make sure your backup encryption is on (Premium) or your destination is private (any tier) before adding it.
• Files outside wp-content/. UpdraftPlus has a manual entry for Include any other directories? where you can list extra paths. This is the path for custom upload directories (some sites use wp-content/cdn/ or a sibling assets/ directory) and for .htaccess.

Never included, by design:

• WordPress core files (wp-admin/, wp-includes/, index.php, wp-load.php, etc.). The expectation is that you reinstall core from wordpress.org during a restore.
• Server-level configuration (Apache vhosts, nginx server blocks, PHP-FPM pools, system cron jobs, MTA configuration). These live outside the WordPress install and are your hosting environment's responsibility to back up.
• Files outside the WordPress installation directory.

For the practical implication during a restore, see How to restore WordPress from a backup. The short version: an UpdraftPlus restore plus a fresh WordPress core download from wordpress.org plus your wp-config.php from your password manager equals a complete site. UpdraftPlus alone does not.

When scheduled backups fail

The five most common reasons scheduled UpdraftPlus backups stop working, in rough order of frequency.

1. WP-Cron is not firing. Symptom: the Next backup time in the UpdraftPlus settings is in the past, sometimes hours or days in the past. The schedule was registered correctly, but WP-Cron never triggered the event. Cause: low site traffic, blocked loopback HTTP, or DISABLE_WP_CRON set in wp-config.php without a real cron replacement. Fix: follow the diagnosis in WordPress wp-cron: why it fails and how to replace it. Replace WP-Cron with a real system cron job that hits wp-cron.php every 5 to 15 minutes.

2. PHP max_execution_time is too low. Symptom: the backup starts in the log but never finishes; eventually a new entry appears and the previous one is abandoned. Cause: the PHP request running the backup is killed by the server before the backup completes. UpdraftPlus is designed to resume across multiple requests, but when max_execution_time is below 60 seconds and the backup has thousands of files to compress, it cannot make forward progress. Fix: ask your host to raise max_execution_time to 600 or 900 seconds for the WordPress site, or move to a host that lets you set it yourself in php.ini.

3. Out of disk space. Symptom: the backup log shows Could not write to file or the backup truncates mid-archive. Cause: the local wp-content/updraft/ directory has filled the disk, often because old backups are not being deleted (which happens when the upload to remote storage fails silently, see point 4). Fix: SSH or use the hosting file manager to empty wp-content/updraft/ of old archives, then run a fresh backup and confirm the upload completes.

4. Remote storage credentials silently broke. Symptom: backups complete locally with green ticks, but never appear in the remote destination, and Existing Backups shows the upload status as failed when you hover. Cause: an OAuth token expired, a Google account password change invalidated the connection, an FTP password was rotated, an S3 IAM key was rotated. UpdraftPlus surfaces this in the log but rarely in a way that screams. Fix: go to Settings > UpdraftPlus Backups, scroll to the destination, click Reauthorize (Google Drive, Dropbox) or update the credentials (FTP, S3), and run a manual backup to confirm.

5. The backup completes but the database table set is wrong. Symptom: a restore later turns out to be missing some plugin's tables. Cause: UpdraftPlus by default backs up only tables prefixed with the WordPress table prefix from wp-config.php (typically wp_). If a plugin uses a different prefix (rare but possible), or if you manually changed $table_prefix after installing the plugin, those tables are skipped. Fix: in Settings > UpdraftPlus Backups > Settings, scroll to Database options and check what the database table inclusion looks like. There is no UI option in the free tier to include tables outside the WordPress prefix; you would need a plugin author to fix their prefix or a manual mysqldump alongside.

If a backup fails and you cannot tell which of these caused it, the diagnostic data to gather before asking for help: the contents of the UpdraftPlus log file (downloadable from the Existing Backups section), the WordPress and PHP versions, the contents of the Cron events tab in Advanced Tools, and the most recent error from your server's PHP error log. With those four artefacts in hand, the cause is usually obvious within five minutes.

Common misconceptions

A short list of beliefs about UpdraftPlus that I have had to walk people back from, and why they are wrong.

"My daily UpdraftPlus backup automatically goes to remote storage." Only after you have configured a remote storage destination and confirmed the OAuth or credentials are valid. Out of the box, UpdraftPlus stores backups locally in wp-content/updraft/ on the same server as the site. That is not offsite storage. The configuration is in Settings > UpdraftPlus Backups > Settings > Choose your remote storage, and you must run at least one successful backup to confirm the upload works.

"UpdraftPlus free does rsync-style differentials so my backups will be small." No. The free version takes a complete backup every scheduled run. Incremental backups (Premium) only avoid re-uploading unchanged files; they do not change the size of any single backup archive. If your uploads directory is 50 GB, every free-tier backup uploads 50 GB. The first Premium incremental run also uploads 50 GB; subsequent runs only upload the changed files.

"Backup verification is automatic." Not on the free tier. UpdraftPlus does not download the backup back from remote storage to verify the bytes; it does not compute or compare checksums; it does not test that the database dump can be re-imported. The only signal that the upload happened is the HTTP response from the remote storage API. Cryptographic checksum verification is a Premium feature, per the features page. Spot-check uploads manually once a month.

"Incremental means smaller database backups." No. The database is always full, on both free and Premium. The vendor explains this design choice: tracking row-level changes in WordPress tables would require a tracking system that the plugin does not implement, so even Premium incremental backups produce a complete mysqldump every time. Incremental applies only to plugins, themes, uploads, and other wp-content directories.

"If the dashboard shows 'backup successful', I am safe." Not necessarily. "Successful" means the local archive was written and the upload HTTP request returned success. It does not mean the archive is restorable, the upload reached the destination uncorrupted, or your retention policy is keeping enough history. The only way to know a backup is real is to restore it to a staging environment. If you have not run a restore drill in the last 90 days, your backups are an unverified hope rather than a tested control. The procedure is in How to restore WordPress from a backup.