Skip to main content
Live with caveats. This area is real and usable, but the docs intentionally call out operational or UX limits that still matter.

​
Goal

Recover a Ghost publication from a consistent, StackShift-managed unit instead of restoring its database and files independently.

​
Prerequisites

  • A fully provisioned Ghost installation in running state
  • A running Ghost service release
  • Configured database and stack backup storage

​
Workflow

1
Open the Ghost project overview.
2
Choose Create recovery point and wait for the point to become completed.
3
Before restoring, confirm that the selected point has the intended Ghost version, timestamp, and reason.
4
Choose Restore and wait for the restore operation to complete.
5
Validate the public publication, /ghost/, content images, members, and mail settings.

​
What a recovery point contains

  • A managed-database backup ID for the Ghost MySQL database.
  • A stack backup ID containing the persistent Ghost content volume.
  • The service release ID and exact Ghost version active when the point was created.
  • The project, stack, database, creator, reason, status, and timestamps.
  • An error message when either backup half fails.

​
Consistency procedure

The publication is briefly unavailable while writes are paused and both artifacts are captured. StackShift always attempts to restart Ghost if backup work exits early, including after a database or content backup failure. A point is restorable only in completed status.
Backup sequence

​
Restore behavior

Restore is destructive to the current database and content. Create a fresh recovery point first if the current state may be needed later. The transactional sender is retained, while the private bridge credential is rotated rather than copied from backup.
Restore sequence

​
Recovery-point states

  • pending: the record exists but backup work has not started.
  • in_progress: Ghost is stopped or one of the paired backups is running.
  • completed: both backup artifacts exist and the point can be restored.
  • failed: the point is not usable; inspect its error and create a new point after fixing the cause.

​
Validation after restore

  • Load multiple public posts and verify images stored in the content volume.
  • Sign in to /ghost/ and confirm recent content and settings.
  • Check members and subscriptions that live in MySQL.
  • Send a transactional test and, if configured, verify the Mailgun newsletter connection.
  • Review the operation status and logs before resuming editorial work.

​
Expected result

The managed MySQL database, content volume, and exact backed-up Ghost release are restored together, Ghost restarts, and the project mail credential is rotated.

​
Common failures

  • Ghost or its latest service release is not running when backup starts.
  • Database backup storage is unavailable or the backup exceeds its completion window.
  • Content backup storage is unavailable.
  • A recovery point is selected before both artifacts reach completed.
  • A restore succeeds at the data layer but application behavior is not manually validated.

Create a private Ghost staging clone

Clone production Ghost data into a separate native project with a new database, new runtime credentials, generated domain, authenticated ingress, and outbound mail disabled.

Upgrade Ghost safely

Use StackShift’s curated upgrade graph, mandatory pre-upgrade recovery point, digest-pinned runtime update, and automatic rollback path.

Ghost troubleshooting and limitations

Diagnose native Ghost provisioning, database, image, routing, mail, recovery, staging, and upgrade failures using persisted operation state and clear resource boundaries.