> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Ghost recovery points and restore

> Capture Ghost’s MySQL data, persistent content, and exact runtime release as one coordinated recovery point, then restore the complete set through a durable operation.

<Warning>
  **Live with caveats.** This area is real and usable, but the docs intentionally call out operational or UX limits that still matter.
</Warning>

## 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

<Steps>
  <Step>
    Open the Ghost project overview.
  </Step>

  <Step>
    Choose Create recovery point and wait for the point to become completed.
  </Step>

  <Step>
    Before restoring, confirm that the selected point has the intended Ghost version, timestamp, and reason.
  </Step>

  <Step>
    Choose Restore and wait for the restore operation to complete.
  </Step>

  <Step>
    Validate the public publication, `/ghost/`, content images, members, and mail settings.
  </Step>
</Steps>

## 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.

```text Backup sequence theme={null}
1. Validate that Ghost and its current service release are running
2. Mark the recovery point in progress
3. Stop Ghost to pause writes
4. Start and await the MySQL backup
5. Back up the persistent content volume
6. Restart Ghost
7. Mark the recovery point completed only when both artifacts exist
```

## 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.

```text Restore sequence theme={null}
1. Stop Ghost
2. Restore the paired MySQL backup into the managed database
3. Restore content and the backed-up service release
4. Validate that the restored runtime is still digest-pinned
5. Generate and install a new project-bound mail credential
6. Deploy Ghost and record the backed-up version as current
```

## 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

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

## Common failures

<Warning>
  * 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.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Create a private Ghost staging clone" href="/ghost/private-staging-clones">
    Clone production Ghost data into a separate native project with a new database, new runtime credentials, generated domain, authenticated ingress, and outbound mail disabled.
  </Card>

  <Card title="Upgrade Ghost safely" href="/ghost/safe-ghost-upgrades">
    Use StackShift’s curated upgrade graph, mandatory pre-upgrade recovery point, digest-pinned runtime update, and automatic rollback path.
  </Card>

  <Card title="Ghost troubleshooting and limitations" href="/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.
  </Card>
</CardGroup>