← Knowledge library

IT & integrations

Operate a versioned deployment and verify recovery

Treat plugins, workers, database backups and readiness as part of the supported installation.

Current source · source reviewed · 7 min read

Before you begin

1. Inventory the actual release

Record core/frontend versions, enabled apps, feature/entitlement configuration and environment. Match knowledge instructions and API schema to the installed version.

2. Verify service dependencies

Check the deployed database, background processing, storage and integration queues according to the installation runbook. A responsive website alone does not prove asynchronous exchanges are being processed.

3. Verify backup creation

The supplied Docker backup guide describes PostgreSQL dumps, a configured backup directory and retention. Confirm the real deployment’s schedule, destination and retention rather than assuming documentation defaults are active.

4. Test restore in an isolated environment

Use an approved recovery plan and a separate test target to verify a backup can be read and the application can start with its expected data and plugins. Retain witnessed recovery evidence.

5. Check readiness after release

Run enterprise readiness and inspect queue/certificate/financial blockers after a core or integration change. Keep rollout and recovery references available to support.

Recovery scope

The source backup guide primarily covers the database. It does not by itself prove object-store, secret-manager, fiscal-vault, attachment or configuration recovery. Include the actual deployment’s dependencies in the approved recovery plan.

No destructive shortcut in public training

Database replacement commands belong to the approved operator procedure and authorized recovery window. A public knowledge guide should explain the scope and evidence, not encourage restoring over production to test a backup.

Troubleshooting

Backups exist but recovery has never been demonstrated

Schedule and witness an isolated restore with the deployment owner, then verify representative records, attachments and integration state against documented acceptance criteria.

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.