feat(ops): protect complete pre-deploy recovery set
CI and Deploy / test (push) Successful in 6m56s
CI and Deploy / deploy (push) Successful in 1m10s

This commit is contained in:
cesnimda
2026-09-01 20:06:25 +02:00
parent bf3dc2d06e
commit bd7fa05b8c
6 changed files with 223 additions and 11 deletions
+9 -7
View File
@@ -86,9 +86,10 @@ MYSQL_PWD='<pw>' mariadb --host=<host> --user=<user> --default-character-set=utf
## Production access
A sanitized read-only host inventory was completed on 2026-08-15. It verified the integrity of the
existing compressed database dumps without reading private rows or restoring data. The newest
observed dump was dated 2026-08-02, and the set is database-only: it does not prove recovery of owned
files, data-protection keys, configuration, or account-deletion tombstones.
then-existing compressed database dumps without reading private rows or restoring data. The newest
observed dump was dated 2026-08-02, and that set was database-only. Current deployments now create a
verified database backup plus application-data and deletion-tombstone volume archives before any
build or replacement. A scratch restore is still required before recovery is considered proven.
**Authorized production steps still required:**
@@ -98,10 +99,11 @@ files, data-protection keys, configuration, or account-deletion tombstones.
- table count (~42) and row counts for `AspNetUsers`, `JobApplications`, `Companies`,
`CareerProfiles` match production;
- a real record containing `æ`/`ø`/`å` reads back correctly (the check above).
3. Build and restore a complete recovery bundle covering the `jobtracker_data` volume and deployment
data-protection keys as well as MariaDB. Preserve the separately mounted
`jobtracker_deletion_tombstones` volume across application-data restores; never overwrite it with
an older backup capable of resurrecting a deleted identity.
3. Restore the matching `jobtracker_data` archive alongside the database dump. It contains owner
files and deployment Data Protection keys.
4. Verify the separately archived `jobtracker_deletion_tombstones` ledger, but preserve the newest
ledger across application-data restores; never overwrite it with an older backup capable of
resurrecting a deleted identity.
Until that is done, backup/restore is proven **on the mechanism and on synthetic Norwegian data**, not
on the production dataset.