# Disaster recovery and rollback

For a bad application release, retain the database and roll back to the prior commit/image first. Restore the database only when data or schema is the problem; restoring loses newer rows. For an incident, preserve logs/manifests, stop repeated deploys, identify the exact failed component, and use an isolated restore rehearsal before a production restore.

The repository-side rollback path is implemented, but a real failure-injection rehearsal on the production topology remains blocked by operator access and authorization. See [known issues](../roadmap/known-issues.md).