Back up and restore plain directories, alongside the database sources.
Files source and Archive (P0)
- `files` type: absolute path (not /), options.exclude and
options.one_file_system; walk + tar.gz with symlinks kept as links,
special files skipped, unreadable entries fail the run.
- Mirror restore: archive validated first, then everything not excluded
is wiped (mount points and special files kept) and the archive is
extracted, retrying without metadata on filesystems refusing chown/chmod.
- Windows-safe platform helpers; helm extraVolumes/extraVolumeMounts.
Universal rclone mapper (P1)
- rclone_target(storage) for s3, blob, gcs, drive, rclone and sftp; sftp
goes through it; rclone obscure reads the password from stdin.
Snapshots, restic (P2)
- restic in the image; repository per source and channel, password
derived from the master key (HKDF); stable host, bs:<row> tags,
translated excludes; exit 3 fails and forgets the snapshot.
- Mirror restore with `restic restore --delete`; restore payload carries
the encrypted channel; snapshot ids must be full ids.
- Engine in the ping and in scheduled task metadata.
One locked method per source (spec A)
- databases.json declares options.method (archive, snapshot, sync),
reported in the ping for local sources only.
- Sync: rclone sync per channel onto <folder>/sync/<id>/current, refuses
an empty source, reports transferred/deleted counters.
Local channel (spec B)
- Snapshots and Sync reach the dashboard's local storage through its
append-only restic REST server and its WebDAV server.
Security
- Strict rclone config validation: one section, no duplicate keys, no
command, credential or host-file keys, no quoted values, valid backend
type, blocked backends.
- Scheduled task metadata (decrypted storages) is no longer logged.
helm/templates/env-configmap.yaml never listed RETRY_ATTEMPTS and
RETRY_BACKOFF_MS even though values.yaml gained them, so --set
env.RETRY_ATTEMPTS=N was silently ignored by Kubernetes deployments.
Add both keys in the same explicit style as the existing entries.
src/utils/retry.rs logged its own "failed after N attempts" error on
exhaustion, on top of the terminal log each call site already writes,
producing two error entries per failure. Worse, it changed a log
level: FileLock::acquire's "backup_already_in_progress" bails through
the combinator, which now logged it as error before runner.rs got a
chance to reclassify it as the routine warn it always was. A manual
backup colliding with a scheduled one would show up as a hard error
on the dashboard instead of the harmless warn it used to be, breaking
the "fails exactly as it does today" guarantee for job records.
Drop the combinator's terminal error log and give download_backup its
own terminal error log so all three call sites (runner, uploader,
downloader) own their failure logging uniformly. Update the two tests
that asserted the removed message to assert the new behavior instead.
Adds RETRY_ATTEMPTS (3..=5, default 3) and RETRY_BACKOFF_MS
(100..=30000, default 1000) to Settings, validated with the same
panic-on-invalid contract as POOLING and CHUNK_SIZE_MB.
The combinator logs every failed attempt and any late success through
the JobLogger it borrows, so retries reach the server on the existing
job-log path with no API change. It borrows rather than clones the Arc
so Arc::try_unwrap in the backup executor keeps working. Backoff is
exponential with equal jitter, because the uploader retries storages
concurrently and would otherwise retry them in lockstep.
Charles Gauthereau