Files
vaultik/docs/TODO.md
T
sneak 718c10da10 Point links at the moved documents and config example
ARCHITECTURE.md, TODO.md and config.example.yml moved to docs/ and
configs/ on next. README.md now links to the new paths. docs/ARCHITECTURE.md
and the roadmap in docs/TODO.md link to their sibling documents by file
name, as docs/DATAMODEL.md and docs/REPOSTRUCTURE.md already do. The help
text and configs/config.example.yml name none of the old paths.

Model: fable-5-1
2026-11-11 07:01:54 +00:00

80 lines
3.4 KiB
Markdown

# Workflow
- branch (from `main`)
- do the work in Next Step
- delete Next Step from `TODO.md`
- move the top item of Future Steps into Next Step
- commit (`TODO.md` changes in the same commit as the work)
- merge to `main` if the branch is not protected, otherwise open a PR
- push
# Status
pre-1.0
# Next Step
Fix the open bugs on the issue tracker that block the release. Merging `next`
into `main` is the owner's.
# Future Steps
Work planned after 1.0, loosely ordered by priority.
## Correctness and operability
- **Outside security audit.** Before 1.0 the encryption and blob-generation code
was reviewed. Every bug the review found was fixed. The risks it accepted are
listed in [Accepted risks](REPOSTRUCTURE.md#accepted-risks). No outside audit
has been done. age, zstd and content-defined chunking are mostly off-the-shelf
pieces. The code that joins them needs an outside read:
- key handling
- recipient parsing
- manifest trust boundary
- restore-time identity validation
- **Verify restored content end-to-end in CI.** The current integration test
does this for a small synthetic snapshot but not at scale. A nightly job
against a multi-GB representative snapshot would catch silent regressions in
the chunker, packer, or restore planner.
## Performance
- **Parallel blob downloads during restore.** A restore downloads one blob at a
time now. With a fast S3 endpoint and a multi-core machine, restore speed is
bound by the fetch, decryption and decompression of each blob. Running several
of those in parallel against the disk cache would close most of the remaining
gap. This needs to interact correctly with the locality planner and the
sweeper.
- **Bandwidth limiting (`--bwlimit`).** For both upload and download. It is
useful for backing up over a shared link. It is tricky to make work correctly
with parallel downloads.
- **Restart of interrupted restore.** Today a restore can be started again, and
it then overwrites the partial output. It does not resume from where it
stopped, and it does not skip files that are already present. A `--resume`
mode that checks targets before fetching blobs would matter for very large
restores.
- **Daemon mode.** A long-running mode that watches for file changes, so that
frequent backups, such as hourly ones, skip the full scan. It adds little for
the usual backups from cron every 12 to 36 hours. See
[issue #204](https://git.eeqj.de/sneak/vaultik/issues/204).
## Usability
- **Man pages and richer `--help` examples.** Cobra generates basic help. Man
pages would be a separate target.
- **`vaultik snapshot diff <a> <b>`.** Show which files changed between two
snapshots, without restoring either.
- **Status reporting hook for `--cron`.** When a backup fails silently in cron,
the user has no idea. A configurable hook on completion, for both success and
failure, would close the loop. It could be a webhook, an email or
`notify-send`.
## Infrastructure
- **Schema migrations after 1.0.** Migrations are supported, but none are added
before 1.0 because there is no installed base yet. After 1.0, each schema
change is a new migration, so an existing local index is migrated when
`vaultik` is updated. See [`DATAMODEL.md`](DATAMODEL.md#schema-migrations).
- **Storage backend coverage tests.** S3, `file://` and `rclone://` all share
the `Storer` interface, but the rclone path is the least exercised in CI.