UpdraftPlus (Premium)

Source

Private (Premium) — baked from the licensed zip

Purpose

Scheduled backup of database + uploads to offsite storage; restore

Special infra

Dedicated backup PVC; restore-staging emptyDir

Install

UpdraftPlus Premium is not on wordpress.org. Bake the licensed zip (root folder updraftplus/) into the image and activate it in bootstrap:

unzip -q packages/updraftplus-*.zip -d web/app/plugins

Licence activation

There is no licence file. The Premium code is the baked zip; activation is a one-time online connect in UpdraftPlus → Premium / Extensions — logging in with the account registers the site and stores the connection in the database, so it survives every pod restart. Do it once after first deploy. Remote-storage providers (OneDrive, S3, Dropbox, Google Drive, …) are likewise authorised once via OAuth in the settings and persisted in the DB.

Storage — the two directories that matter

UpdraftPlus touches two writable locations. Getting the volume types right is essential.

Backup directory — its own PVC

The backup directory defaults to wp-content/updraft. It must be its own PVC, mounted at web/app/updraft:

- name: updraft
  mountPath: /var/www/html/web/app/updraft   # own PVC, sibling of uploads

Do not implement it as a subPath of the uploads PVC. Doing so places the backups at the uploads-PVC root, where they surface as wp-content/uploads/updraft — inside the media tree. A media restore then collides with UpdraftPlus' own backup folder (Delete …​/uploads/updraft: Failed), and the uploads archive ends up containing the backup store recursively. A dedicated PVC makes updraft a true sibling of uploads. UpdraftPlus honours absolute paths too, but the default location on its own volume is the simplest correct answer.

Restore-staging directory — an emptyDir

Restores unpack archives into wp-content/upgrade. UpdraftPlus deletes and recreates that directory between steps, so it must be an emptyDir, not a PVC subPath — a subPath bind mount goes stale the moment the app `rmdir`s it (writes then fail with the directory reporting a link count of 0). See the writable-path traps.

- name: upgrade
  mountPath: /var/www/html/web/app/upgrade   # emptyDir

Schedule

Backups run on WordPress cron, which on an immutable site is driven by the out-of-band CronJob (see WP-Cron). The interval and report email can be seeded in bootstrap:

wp option update updraft_interval 'daily'
wp option update updraft_interval_database 'daily'
wp option update updraft_email '<ops-address>'

The exact time-of-day and the remote-storage connection are set once in the admin.

A dev site needs none of this: it takes no backups. It still needs the updraft PVC, though — Migrator stages the archive it is about to send in wp-content/updraft whether or not a schedule exists.

Migrator — moving content between a dev site and production

Content — posts, pages, builder layouts, media — is the one thing with no worthwhile declarative form. It moves through UpdraftPlus' Migrator add-on, which opens a direct RSA/RPC connection between two sites and pushes a selected set of components.

The licence model is what makes this affordable

Migrator is licensed separately from Premium, and activating it does not consume one of the Premium site slots. That is the difference that makes a dev site viable: it can run the same baked UpdraftPlus zip, activate Migrator only, and take part in the content lane without paying for a second Premium activation for backups nobody wants.

Activate Migrator on the dev site. Do not perform the Premium connect there — that is the action that consumes a slot.

There is no published dev-or-staging URL exemption for UpdraftPlus Premium itself. Some vendors publish one; this is not one of them, and forum answers point at requesting a one-off slot reset rather than a standing allowance. Do not assume a dev. hostname is free.

The free version can still restore selected components from a manually uploaded backup set, so a site without Migrator is not completely cut off — it is just a manual archive shuffle.

The two directions are not symmetric

Direction Components Why

production → dev

database + uploads

The high-value direction: it makes the dev site realistic. Follow it with wp search-replace '<prod-host>' '<dev-host>' and then a scrub — the pull brings real customers, real orders and the live payment and API settings with it.

dev → production

uploads (and others) only

Production’s posts, users and order tables are authoritative. See the warning below.

Never restore a database forward into a live site

A forward database restore replaces production’s wp_posts, wp_users and the WooCommerce order tables with the dev site’s. Every order taken since the dev site was populated is gone, along with the customers who placed them, and UpdraftPlus offers no partial-merge alternative — its database component is all or nothing.

Deselect the database on any dev → production push. Move authored content deliberately, one change at a time, rather than by copying a database over a live store.

Selecting plugins, themes or core in either direction is separately pointless — see below.

Immutability boundary

UpdraftPlus can restore the database and uploads — both are writable. It cannot restore plugins, themes or core: those directories are baked read-only. Recover code by redeploying the matching image tag, not through UpdraftPlus. Deselect the code components when restoring.

Backups taken before the backup dir was moved to its own PVC contain a nested uploads/updraft subtree in their uploads archive. They still restore, but leave harmless junk; take a fresh backup after the storage layout is correct for a clean restore.