Hi everyone,
I’ve been spending quite a bit of time on the VaultSync 1.9 CLI rework, and it’s finally reached the point where I can show an actual end-to-end workflow instead of just talking about commands that are being added.
The goal is pretty simple: the CLI shouldn’t feel like a secondary interface that exists only because it can.
It should be useful on its own, understandable when you open it for the first time, and safe enough to use for real recovery work.
Opening vaultsync now gives you a small introduction, a few useful starting commands, and direct links to the website, GitHub repository, releases, and documentation.
The CLI handbook is also bundled with VaultSync, so:
vaultsync docs --full
works offline too.
The more important part: actual backup → verify → restore workflow
The bigger piece of work has been the recorded folder-backup workflow.
From the CLI you can now:
- create a recorded backup at an explicit destination
- inspect the backup record and snapshot history
- verify the stored payload against its recorded hashes
- preview exactly what a restore is going to change
- perform the recovery only after that preview
A live mirror also has its own explicit command and terminology now.
That distinction is intentional.
Mirroring the source as it exists today is not the same thing as creating a recorded recovery point, and I don’t want VaultSync hiding that difference behind vague terminology.
Machine-readable output is getting proper attention too
The CLI can return a versioned JSON result rather than forcing scripts to parse human-readable terminal output.
For example, verification exposes things such as:
- backup and snapshot IDs
- files checked
- pass/fail counts
- whether the payload was actually checked
- verification failures
- whether the failure list was truncated
- process exit code
That matters quite a bit for where VaultSync is going.
The CLI should eventually be useful not only interactively, but also for automation, NAS/server workflows, and external tooling without turning normal terminal output into an unofficial API.
Still development work
This is currently in draft PR #683:
https://github.com/ATAC-Helicopter/VaultSync/pull/683
This is development work, not a VaultSync 1.9 release.
Local tests and package checks are passing.
Some hosted platform validation is currently waiting because I’ve exhausted the available GitHub Actions minutes, so I’m deliberately not pretending those checks have run when they haven’t.
Also, this CLI work is only one part of 1.9.
The larger disk imaging / cloning and bootable recovery work is still separate release work and remains one of the major pieces being built for the full 1.9 update.
1.9 is a much larger update than the usual VaultSync release, and I’m trying to build and test the underlying pieces properly before pushing deeper into the parts that can actually touch entire disks and recovery environments.
There will most likely be multiple 1.9 beta builds before the final release because this is not something I want to rush.
I wrote a longer dev diary about the CLI work, some of the decisions behind it, and a few of the bugs the work exposed:
https://fglabs.dev/devlog/vaultsync-19-cli-worth-opening
I’d especially like feedback from people who actually use backup tools from terminals or scripts:
What would make you trust a backup CLI more: a very clear restore preview, machine-readable verification evidence, or a better way to verify/check many backups at once?