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:
@@ -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`.
|
||||
|
||||
Reference in New Issue
Block a user