3 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	9e5f6e183a	fix(backup): refuse another schema before reading the dump; tests read settings directly (#5815) ... - restore_in_place checks the backup's migration heads before pg_restore writes anything, so a backup from another schema is refused at once. - The integration tests read their own setting rows directly: get_all_settings knows only Steward's own keys. - check.py: drop an import left unused by the move to pgdata. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 10:56:57 -04:00
bvandeusenandClaude Opus 5.5	aab8581f20	feat(backup): restore a same-version backup in place, history kept, all or nothing (#5815) ... #5815 "Restore engine: in place for a same-version backup". restore_in_place (steward/backup/restore.py) runs in one transaction: 1. It keeps aside what Steward records as it runs: ACTIVITY columns of rows that come back, and STATE_SETTINGS. 2. It drops every foreign key touching a replaced table. 3. It truncates the replaced tables and COPYs the backup's rows in unparsed, through asyncpg. 4. It puts the kept state back and moves sequences past their rows. 5. It puts right the rows whose parent didn't come back, by each key's own ON DELETE. A RESTRICT key that may be empty is cleared, so a run whose user is gone keeps its record. 6. It re-adds the keys, which checks every row. A failure anywhere rolls the whole restore back. A backup made at another schema is refused with NotSameSchema ("older": a full replace is the way; "newer": update Steward). The COPY-text reading moves into steward/backup/pgdata.py, shared by the check and the restore. The integration tests stand in for pg_restore with this database's own COPY output: - settings come back while the audit log and the history of what remains stay; - history of what didn't come back goes; - a failure part-way changes nothing; - a newer schema is refused. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 10:53:38 -04:00
bvandeusenandClaude Opus 5.5	e8b75143f1	feat(backup): check a backup against what is in place, changing nothing (#5823) ... #5823 "Check a backup: compare what it would restore with what is in place, without restoring". - steward/backup/check.py: pg_restore writes the backup's rows as COPY text with no database involved. The rows in place go out through COPY in the same form. Tables are compared on their primary keys, over the columns both sides have, and grouped by area. - Sealed values are opened with each side's own key and compared as plaintext digests, so a secret sealed twice still matches. They are never shown. A backup whose key can't open its own secrets fails the check. - What Steward records as it runs (last-seen times, a schedule's last run, backup history, scraped UniFi fields) is left out of the comparison: contents.ACTIVITY, STATE_SETTINGS and HAND_SET_ONLY. - Settings → Backups: - a Check button on each sent backup, which fetches it from the bucket (new s3.get_file); - "Check a file" to upload one, with the size limit raised before the CSRF check reads the form; - a results page. - Each backup Steward sends checks itself once written, and its history row says how that went. - New CLI command `steward check-backup FILE`. CI's image smoke step checks a real backup against its source and expects a match. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 10:48:48 -04:00