Backups and Rollbacks for Stateful Web Applications

Reverting a web server image does not reverse the orders written while that image was running. A stateful application has several histories: application code, database schema, customer records, uploaded files, and external transactions. A recovery plan must explain which history is being changed and what happens to legitimate work created afterward.

Separate rollback from restoration

An application rollback replaces a release with a previously supported version. Database restoration rebuilds stored state from recovery material. A compensating action records a new business operation that corrects an earlier one, such as releasing a reservation. These are different tools, and combining their names into one “undo” button hides important consequences.

Inventory the state before choosing a backup product. Include the primary database, object storage, uploaded files, job queues, encryption keys, configuration, and external provider identifiers. Some caches can be rebuilt; an unprocessed queue may contain work that exists nowhere else. Classify each store by whether it is authoritative, derived, or temporarily holding an obligation.

Define a recovery point objective as the amount of recent data loss the business can tolerate, and a recovery time objective as the acceptable restoration time. These are targets to validate, not guarantees supplied by installing backup software. A daily backup cannot by itself meet a requirement to lose only a few minutes of writes.

Choose a database-aware backup method

PostgreSQL distinguishes SQL dumps, filesystem-level backups, and continuous archiving in its backup and restore documentation. The existence of several approaches matters: copying a live database directory without satisfying the database's consistency requirements is not interchangeable with a supported backup method.

Record the exact engine version, backup tool, configuration, and restore requirements. Include roles and permissions if the selected method does not capture them automatically. Protect recovery credentials and keys independently enough that losing the application host does not make its backups unreadable.

For point-in-time recovery, PostgreSQL combines a base backup with the required write-ahead log history. Its continuous archiving guide explains replay and recovery targets. A missing segment or expired base backup can break the recovery chain. Monitor archive completeness and retention together rather than counting backup files.

Design releases that can coexist with old code

Schema compatibility often determines whether an application rollback is possible. An additive change, such as introducing a nullable column while old readers continue to work, is easier to stage than renaming a column and immediately requiring every process to use the new name.

Use an expand-and-contract sequence where appropriate: add compatible structures, deploy code that can handle the transition, migrate data, verify the new path, and remove obsolete structures only after old code and workers are retired. This is an engineering method, not a promise that every migration can be made reversible.

List irreversible operations explicitly. Dropping a column, rewriting values destructively, or sending external notifications may require restoration or a forward correction rather than code rollback. Define the last safe rollback point before beginning the release, and make it visible to the person who authorizes each stage.

1. Stop the harmful operation and identify affected state.
2. Preserve evidence and record the current write boundary.
3. Choose compatible code rollback, forward repair, or isolated restoration.
4. Reconcile records and external effects created after the recovery point.
5. Validate business operations before resuming normal writes.

Restore somewhere safe before switching traffic

A restore rehearsal should use an isolated environment with controlled access. Disable outbound email, payment actions, scheduled jobs, and webhooks unless the rehearsal explicitly needs safe test versions. Restoring production data into a broadly accessible staging service creates a new exposure even when recovery itself succeeds.

Verify more than server startup. Check expected record ranges, relationships, representative attachments, permissions, and one business transaction that can be performed safely. Record the elapsed recovery time and missing prerequisites during an actual rehearsal; do not infer readiness from the backup job's green status.

Document the cutover decision. If writes continue on the old system while the restored copy is prepared, decide how they will be captured or when writes will pause. Two writable copies can diverge. Routing traffic to the restored database without accounting for that interval may lose legitimate customer changes.

Hypothetical example: an invoice migration fails

In this hypothetical example, a small subscription service releases code that writes a new invoice format. Older code can still read both formats, so a display bug can be mitigated by reverting the application. No database restoration is necessary merely because the release was faulty.

A different migration accidentally overwrites invoice totals. The team pauses the affected write path and restores a pre-migration copy in isolation. It compares damaged records with the restored values and reviews invoices created after that point. Restoring the entire live database immediately would also remove those new invoices.

Payment records at the external provider are reconciled using stable identifiers. Restoring a database cannot reverse a charge. The repair plan records which corrections are applied and which require a separate business action. This scenario illustrates decision boundaries; it reports no tested recovery outcome.

Stateful recovery checklist

• Are authoritative stores, queues, objects, and decryption requirements inventoried?
• Does the backup method match the database's consistency rules?
• Are recovery targets supported by a complete retained chain?
• Can old application versions read the current schema and records?
• Are restored environments prevented from causing live side effects?
• Who accounts for writes after the selected recovery point?
• Has an actual restore verified business behavior and measured the recovery time?

Keep the runbook close to the release process and name the person who can pause writes. Backups provide options; compatibility and reconciliation determine whether those options can be used without creating a second incident.