Production is dumped nightly, checked by a restore, encrypted and kept off the VPS #371

New issue

Closed

opened 2026-10-11 16:26:14 +00:00 by root · 8 comments

root commented

2026-10-11 16:26:14 +00:00

(Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#371, opened by @amaurycoudr on 2026-10-11 16:26 UTC.

Parent

#354

What to build

Stories 12 and 13 of #354. A nightly workflow, scheduled like the preview reaper, dumps production's database in Postgres's custom format through the SSH Docker connection. It restores the dump into a throwaway Postgres on the runner to prove it is usable. It then encrypts the dump with age to a public key committed in the repo, whose private key only the owner holds, and uploads it as an artifact kept 30 days. A failed dump, restore check or upload fails the run. A manual trigger beside the schedule lets the owner run it on demand.

The deploy README gains the restore procedure: download the artifact, decrypt it, and restore it into production's database. Add the key-pair step to the owner wizard. See #354, Backup.

Seam: the backup verification: the dump restored into a throwaway Postgres.

Acceptance criteria

The workflow fails when the dump, the restore check or the upload fails.
A dump that cannot be restored fails the run.
The uploaded artifact is encrypted to the committed public key and kept 30 days; nothing unencrypted is uploaded.
The deploy README's restore procedure covers download, decryption and restore into production.
After the spec merges, the first manual run is green and is recorded on #354.
The gate is green.

> _Imported from GitHub [amaurycoudr/chess-project#371](https://github.com/amaurycoudr/chess-project/issues/371), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-11 16:26 UTC._  --- ## Parent #354 ## What to build Stories 12 and 13 of #354. A nightly workflow, scheduled like the preview reaper, dumps production's database in Postgres's custom format through the SSH Docker connection. It restores the dump into a throwaway Postgres on the runner to prove it is usable. It then encrypts the dump with `age` to a public key committed in the repo, whose private key only the owner holds, and uploads it as an artifact kept 30 days. A failed dump, restore check or upload fails the run. A manual trigger beside the schedule lets the owner run it on demand. The deploy README gains the restore procedure: download the artifact, decrypt it, and restore it into production's database. Add the key-pair step to the owner wizard. See #354, *Backup*. Seam: the backup verification: the dump restored into a throwaway Postgres. ## Acceptance criteria - [ ] The workflow fails when the dump, the restore check or the upload fails. - [ ] A dump that cannot be restored fails the run. - [ ] The uploaded artifact is encrypted to the committed public key and kept 30 days; nothing unencrypted is uploaded. - [ ] The deploy README's restore procedure covers download, decryption and restore into production. - [ ] After the spec merges, the first manual run is green and is recorded on #354. - [ ] The gate is green.

root commented

2026-10-11 16:26:14 +00:00

(Migrated from gitlab.core-project.space)

GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links).

Parent (sub-issue of): #354
Blocked by: #369
Blocking: #372

> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._  - Parent (sub-issue of): #354 - Blocked by: #369 - Blocking: #372

root commented

2026-10-13 08:39:44 +00:00

(Migrated from gitlab.core-project.space)

mentioned in issue #372