Open EPM ← Back to openepm.dev

Backup, restore and cleanup

Use the operator-controlled host and matching signed release. Confirm the source project, release manifest, identity configuration, and schema. The configured EPM_BACKUP_EXPORT_DIR is the independently mounted, protected export destination. Keep the backup encryption key separately and verify free space for the bundle and restore staging.

Export and verify a bundle

epmctl backup

Expect backup=complete, bundle and source_project. Record the returned bundle name and the release identity. Under the export directory, check the completed bundle’s manifest.json and encrypted payload inventory. The utility authenticates the manifest and payloads and publishes the final bundle after encryption. Treat any reported partial or failed result as an incomplete backup.

Restore to a fresh target

Choose a fresh Compose project name distinct from the source. The target needs empty databases and fresh auxiliary storage for the selected profile. Keep the source running during this verification step. Use the returned bundle name as BUNDLE and substitute your approved target project.

export EPM_RESTORE_TARGET_PROJECT=openepm-recovery
epmctl restore "$BUNDLE"

Expect restore=verified with the same bundle, source and target. This verifies the migration chain, required runtime privileges, target service logins, control databases and restored auxiliary content. The controller records a protected restore-ready marker bound to the bundle, target, prior project, release manifest digest and profile. Verify representative data, metadata and receipt identities in the isolated target before approving service cutover.

Activate the verified target

After operator approval, confirm that only the verified database services are running in the target, the source release is still running, and the external Python build sandboxes are quiescent. Use the same bundle and target.

epmctl activate-restored "$BUNDLE"

Expect activation=verified and confirm the target and prior project names. The controller stops the prior release, starts the target and verifies health. On a failed target start, failed health check or activation marker failure, it attempts to restart the prior release and reports the outcome. After activation, verify the browser and MCP access paths with the intended identities, representative data and receipts before retiring the source.

For a qualification rehearsal, remove the owned temporary credentials, staging files, disposable databases and recovery bundles after capturing the evidence. For an accepted operational release, the deployment owner sets retention and recovery objectives. Maintenance and upgrade procedure

Discussion

Discussing Backup, restore and cleanup

The discussion service requires JavaScript and a connection to Firebase.