Skip to content
Jetrepo
Esc
↑↓navigate↵open⌘Jpreview
On this page

Back up and restore

Define a coordinated recovery set and prove it with an isolated restore.

Jetrepo does not provide backup or restore commands, tool selection, retention, encryption, integrity checks, RPO, or RTO. Treat this page as recovery requirements, not a drilled procedure.

Access

You need host, Postgres, object-storage, Redis, backup-destination, and deployment-secret administration. Choose tools compatible with the deployed images and prove them outside production.

Define the recovery set

  • Postgres: authoritative CMS and authentication state.
  • Object storage: originals and generated image results.
  • Redis: AOF operational state, including queues and delayed work. Decide explicitly whether to preserve it.
  • Deployment inventory: trusted release identifier, resolved image digests, non-secret configuration, and separately protected secrets.

If Redis is omitted, record that queued and delayed operations may be lost and prove how required work will be reconstructed. Queue replay after Redis loss has not been project-drilled.

Create a maintenance boundary

Stop request and background writers while leaving Postgres, Redis, and object storage available to approved online tools. Replace the placeholders with the matching service keys from the production Compose definition:

ADMIN_SERVICE=<admin-service-key>
CORE_SERVICE=<core-api-service-key>
DELIVERY_SERVICE=<delivery-api-service-key>
IMAGE_SERVICE=<image-service-key>

docker compose -f docker-compose.prod.yaml stop \
  "$ADMIN_SERVICE" "$CORE_SERVICE" "$DELIVERY_SERVICE" "$IMAGE_SERVICE" worker
docker compose -f docker-compose.prod.yaml ps -a

# Run operator-approved Postgres, object, and selected Redis backups here.

docker compose -f docker-compose.prod.yaml start \
  "$CORE_SERVICE" "$DELIVERY_SERVICE" worker "$IMAGE_SERVICE" "$ADMIN_SERVICE"

Stopping Admin and Delivery enforces a clear maintenance window. Stopping Core API and Worker stops content and upload writes. Stopping the Image service stops generated-object writes. Keep ingress in maintenance until the recovery point is complete and the services pass smoke tests.

The repository does not certify pg_dump, raw volume copies, object mirroring, or Redis backup syntax against its pinned images. Do not publish a tool command as a Jetrepo runbook until it has been drilled.

Prove a restore

  1. Restore Postgres, objects, and the selected Redis state into an isolated target.
  2. Preserve the original backup and restored state before allowing migrations to modify the target.
  3. Apply only configuration and migrations compatible with the release being tested.
  4. Verify sign-in, Data Types, entries, published delivery, original files, Worker metadata, pending or scheduled operations, and signed image transforms.
  5. Record integrity results and the exact return plan before any production cutover.

If the isolated restore fails, discard that target and diagnose it without changing the known recovery set. A production restore needs a separately tested cutover and return plan.

Logical or physical Postgres backup, object copy, Redis recovery choice, encryption, integrity checks, clean-host restore, migration interaction, and rollback all remain undrilled by the project.

Was this page helpful?