hippogrief/pobsync
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Run post-backup pruning through SQL retention

Browse Source 
Stop passing prune options into the legacy scheduled backup engine from the
Django backup command. Record the completed snapshot first, then apply retention
through the SQL-backed retention service so pruning sees the same SnapshotRecord
state as the admin and retention command.

Also record prune failures on BackupRun.result instead of leaving the run in an
ambiguous state.
This commit is contained in:
Peter van Arkel
2026-05-19 11:32:32 +02:00
parent 254f915051
commit 797619acd9
3 changed files with 128 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -141,6 +141,7 @@ The public command surface is Django-first. The old YAML/cron CLI has been retir
Discovered snapshots are stored in `SnapshotRecord`, including the base snapshot metadata and a nullable SQL link to the
base record when it is known.
The Django retention command plans from `SnapshotRecord` instead of rediscovering snapshots from the filesystem.
Post-backup pruning from Django also uses the SQL retention service after the completed snapshot is recorded.
The remaining internal engine code still contains reusable backup primitives:
@@ -152,7 +153,6 @@ The remaining internal engine code still contains reusable backup primitives:
Next refactor targets:
- Surface `SnapshotRecord` data through API/admin views instead of filesystem inspection.
- Move post-backup pruning onto the SQL retention service.
- Move more snapshot lifecycle details into typed domain objects.
- Replace remaining dictionary-shaped config at engine boundaries.
- Remove legacy YAML import/export once production migration no longer needs it.