A backup matters when restoration works
An operator accidentally deletes a production workspace. A running Postgres container and a persistent volume cannot recover the previous state by themselves. Taskboard needs a backup and a tested restoration path.
Persistence keeps current data across process replacement. A backup preserves recoverable data separately. Replication can improve availability, but a replica may copy the same accidental deletion.
Choose the recovery objective
Recovery point objective, or RPO, describes acceptable data loss. A daily backup can lose changes after the latest backup. Recovery time objective, or RTO, describes acceptable restoration time.
RPO: at most one hour of lost changes
RTO: service restored within two hours
These are example requirements, not Taskboard's measured guarantees. Achieving them depends on backup frequency, storage, database size, automation, and practiced restoration.
Postgres supports logical dumps, filesystem-level approaches, and continuous archiving for point-in-time recovery. These strategies have different tradeoffs. Postgres backup and restore overview.
A restore rehearsal loads a backup into an isolated database, applies the correct runtime configuration, and checks domain records and constraints. Backup job success alone cannot prove that the resulting file is complete or restorable.
Restoration can repeat old work
An older backup may contain an email job that has since completed. Restoring that state can make the job pending again. Starting the worker immediately could resend messages. The same restore may contain outdated subscription state.
A recovery procedure therefore pauses external side effects first. Operators inspect restored jobs, reconcile provider billing state, decide what to replay, and then resume normal execution. Stable provider keys help only within the provider's retention and matching rules.
Backups contain tenant data, password hashes, session hashes, and possibly token-bearing job payloads. Encrypt storage, restrict access, and define retention. Deletion obligations also need a policy for historical backups rather than an assumption that deleting a current row removes every copy.
Taskboard's schema shows what a backup contains in Read api/src/schema.ts. Worker behavior after restart is in Read api/src/jobs.ts. Automated backup scheduling and restore drills remain deployment responsibilities.
Define how much data and downtime are acceptable. Test restoration, and review restored external work before restarting workers.
Why is copying the Docker volume while Postgres runs not automatically a safe backup?
The copy may capture files at inconsistent moments. A backup method must follow Postgres's consistency requirements, and the result still needs a restore check.