Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Recover WordPress deliberately instead of assuming a restore badge means the application is perfect.

​
Prerequisites

  • A deployed WordPress stack with named volumes

​
Workflow

1
Run backups before risky WordPress-side changes.
2
Restore the stack when recovery is needed.
3
Validate the public site, admin access, media, and plugin behavior after restore.

​
What a WordPress backup captures

A WordPress stack stores everything in named volumes: the WordPress files (including uploads under wp-content) and the bundled MariaDB data. Stack backups archive those volumes to S3, so a completed backup is the content and database together, not just one of them.

​
Restore, then validate

  • Only restore from a completed backup.
  • After restore, check the public site, admin login, media/uploads, and plugin behavior.
  • Treat the restore status as “data is back”, not “the application is verified” — confirm the site yourself.

​
Back up before risky changes

Run a backup before core updates, major plugin or theme changes, or migrations. That gives you a known-good point to restore to if an update breaks the site.

​
Expected result

WordPress recovery uses StackShift backups with realistic operator expectations.

​
Common failures

  • Backup storage is not configured for the environment, so backups cannot be created.
  • A volume archive failed, leaving an incomplete backup that should not be restored.
  • Assuming a green restore badge means the application is correct without checking the site.

Back up and restore a stack

Use S3-backed named-volume archives to protect and recover stateful stack data.

Deploy WordPress on StackShift

Launch single-site WordPress as a template-backed stack with bundled MariaDB and persistent storage.

WordPress Control Surface

A first-class operational surface for direct WordPress projects: overview, narrow safe actions, diagnostics, and recent history.