Cotton treats database backup artifacts as part of the product's operating model. PostgreSQL dumps can be chunked, stored through Cotton storage, discovered through latest backup metadata, verified, and used for startup restore when the database is empty.
Cotton can periodically create PostgreSQL dumps and store the resulting backup artifacts through its own storage pipeline. That means backup bytes are not a separate mystery folder beside the product model.
Backup discovery depends on metadata, not filename guessing. Cotton can keep manifest and pointer records for the latest backup so startup restore can find the intended artifact.
Admins can trigger a backup job on demand through the server API when they want an immediate checkpoint before a risky maintenance step or upgrade.
When restore-if-empty mode is explicitly configured, Cotton can check at startup whether the database is empty, find the latest backup manifest, rebuild the dump from stored chunks, verify hash and size integrity, and restore automatically.
The restore path should not blindly stream whatever bytes exist. Cotton can verify backup size and hash before restoring so corruption is a recovery signal instead of a silent partial import.
After auto-restore, Cotton can ensure required PostgreSQL extensions and send high-priority admin notifications with backup metadata. Operators should know that recovery ran and which artifact was used.
The backup flow is concrete: PostgreSQL dump, chunked storage artifact, latest pointer, backup manifest, hash/size verification, empty-database startup restore, extension check, and high-priority admin notification.
Cotton is easier to operate when recovery is not a README footnote. Database backups are visible as an operating model, tied to the same storage discipline that protects normal content.
Storage-native database restore is useful, but it is not a replacement for tested off-box backups. Full host loss, broken storage, wrong key custody, operator mistakes, ransomware, and disaster recovery still need an external backup plan.
Cotton's backup story is operational rather than theatrical. It gives the app a product-level recovery layer without pretending it replaces the boring external backup discipline serious operators still need.
Cotton creates a PostgreSQL dump through the server backup job.
The dump becomes chunked backup artifacts inside Cotton storage.
Latest pointer and manifest metadata identify the restore candidate.
Restore can validate hash and size before trusting the rebuilt dump.
An empty database can be restored on startup when explicitly configured.
Admins receive high-priority recovery metadata after auto-restore.
The startup restore path belongs behind COTTON_RESTORE_DATABASE_IF_EMPTY=true and an empty database check. A normal restart should not overwrite an existing database just because a backup exists.
No. The intended path is explicitly configured empty-database restore. Existing databases should not be overwritten just because the app restarts.
No. It is a useful product-level recovery layer, but serious deployments still need tested off-box backups for full machine loss, storage loss, key loss, or operator mistakes.
It keeps backup artifacts in the same protected storage model: chunks, manifest metadata, latest pointer discovery, and integrity verification instead of an unrelated loose dump file.
Admins should get a high-priority notification with enough metadata to know that auto-restore ran and which backup artifact was used.