Off-site / object-storage backup target for the SQLite DB #18
Labels
No labels
area/ai
area/backend
area/frontend
area/infra
area/scheduler
area/wled
good-first-issue
priority/high
priority/low
priority/medium
type/bug
type/chore
type/ci-cd
type/docs
type/feature
type/qa
v1.0.0
v1.1.0
v1.2.0
v2.0.0
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
rbrooks/Iris-WLED#18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Optionally ship the existing timestamped SQLite backups to an off-box target (S3-compatible object storage, or a mounted remote path) so a host failure doesn't lose approved schemes and history.
Why it's valuable
v1 already creates timestamped backups before bulk operations and prunes by
BACKUP_RETAIN_COUNT, but they live on the same volume as the DB. Off-site copies make the data actually durable — important because approved schemes represent real curation effort.Sketch
BACKUP_S3_ENDPOINT/bucket/creds, orBACKUP_REMOTE_PATH).docs/troubleshooting.md.Acceptance criteria
Proposed enhancement (not in the original spec).