Skip to content
DocsOpen Hub
Databases & data

Back up and recover application data

On this page

Workflow versions preserve behavior; database backups preserve data. Plan both so a code rollback does not leave you without a way to recover records or schema changes.

Define the recovery target#

For each database, record its owner, environment, backup method, storage location, retention, and restore procedure. Decide how much recent data you can afford to lose and how quickly the app needs to recover.

Managed databases and remote database services may expose different backup controls. Use the controls available for the selected resource or the database provider's supported backup process. Do not assume exporting a controller also exports its database contents.

Before a schema change#

  1. Verify that you selected the intended database and environment.
  2. Take or confirm a usable backup using the resource's supported method.
  3. Test the migration with representative sandbox data.
  4. Check compatibility with the currently released workflow and app.
  5. Prepare a recovery procedure for both schema and data.

Avoid copying an actively written SQLite file through an arbitrary file operation. Use a consistent database backup mechanism or an operationally controlled pause.

Prove that restoration works#

Restore a backup into an isolated database. Confirm tables, row counts, important records, and a representative read workflow. Record how long recovery took and any configuration that had to be restored separately.

Keep credentials, selector values, schedules, and workflow versions in the recovery inventory. A restored database alone may not be enough to run an application.

Recover from an incident#

Stop the affected writes where appropriate, preserve evidence, and identify the last known good state. Restore into a separate resource first when possible, inspect the result, then deliberately rebind the workflow or replace the affected data.

Confirm the recovered application with real client reads and a controlled write before resuming schedules. Keep a record of what was restored and what occurred after the backup so reconciliation is possible.

Need to investigate a problem? Start with troubleshooting