refactor: inject config sources into scheduled backups

Introduce a ConfigSource interface so scheduled backups no longer need
to load host configuration directly from runtime YAML. Add a Django-backed
config source for SQL-driven backup runs, keep file-based config as the
CLI default, and make scheduled prune execution actually apply retention
after successful runs.
This commit is contained in:
2026-05-19 04:57:10 +02:00
parent 18082496e4
commit bb44f8a09c
9 changed files with 216 additions and 13 deletions

View File

@@ -145,6 +145,8 @@ Run a backup through Django while still using the existing pobsync engine:
python3 manage.py run_pobsync_backup <host> --prefix /opt/pobsync --prune
```
The Django backup command reads config from SQL directly. Runtime YAML export is kept as a compatibility tool for older CLI flows and retention planning during the transition.
Export database configs to the runtime YAML files consumed by the current engine:
```
@@ -193,8 +195,8 @@ The MariaDB profile is optional. SQLite remains the default because it is enough
Recommended next steps:
- Move config reading/writing behind a repository interface that can use YAML or Django models.
- Record `run-scheduled` results into `BackupRun`.
- Continue moving config reading/writing behind repository interfaces so YAML export can eventually disappear.
- Record more engine-side run details into `BackupRun` and `SnapshotRecord`.
- Treat SQL as the source of truth and export YAML only as a compatibility layer for the current engine.
- Run schedules from Django/Docker instead of writing host cron files.
- Add a snapshot discovery command that syncs existing snapshot metadata into `SnapshotRecord`.