Hi everyone,
One thing I’ve been trying to tighten up in VaultSync 1.9 is what words like “protected” actually mean.
Because that word can hide a lot of very different states.
A destination can be configured.
A backup record can exist.
A mirror can have run.
A file can have been copied.
But none of those automatically mean VaultSync has actually checked the data.
That distinction is becoming much more explicit in the 1.9 CLI.
Configured does not mean reachable
There is now a new opt-in:
vaultsync destinations --output json
It exposes configured destinations in a machine-readable format, while deliberately not exposing paths or credential names.
More importantly, it tells scripts what VaultSync actually knows.
For example, this is from a real disposable configuration:
{"alias":"Studio archive","active":true,"offsite":true,"accessibilityChecked":false}
That last field matters.
accessibilityChecked: false does not mean the destination is inaccessible.
It means VaultSync did not try to reach it, so it refuses to pretend otherwise.
That is the kind of distinction I want the CLI to make consistently:
configured ≠ reachable ≠ backed up ≠ verified
Existing scripts should not suddenly change underneath you
The older:
vaultsync destinations --json
still works exactly as before, including returning:
[]
for an empty configuration.
The new structured output is opt-in.
I don’t want an update to quietly replace the schema that somebody’s script already depends on.
The watcher is getting stricter too
The 1.9 watcher now observes source edits during its first snapshot and mirror, rather than only becoming useful after that initial work has completed.
Failure behaviour is also being tightened.
If a mirror or a later watcher cycle fails, VaultSync now stops with an error instead of quietly continuing as though protection were still happening.
That sounds like a small behaviour change, but for a backup tool I think it is an important one.
Silence after failure is one of the things I want VaultSync to avoid as much as possible.
A Linux AppImage issue was caught along the way
I’ve also added checks around extracted permissions in the Linux AppImage build.
There is an important limitation here:
that fix needs to be present in a future release asset.
It cannot retroactively change the already-published VaultSync 1.8.9 AppImage.
The desktop app is being reconsidered too
Alongside the CLI work, there is now an architecture draft for simplifying the desktop application around four main areas:
Protect
History
Recover
Manage
This is not a screenshot of a new interface and not a finished redesign.
It is an architecture plan.
The intention is to keep existing workflows available while replacements are built and prove that they have feature parity, rather than ripping out working parts of VaultSync just to make the navigation look cleaner.
Where 1.9 actually stands
This work is part of the draft 1.9 PR stack:
https://github.com/ATAC-Helicopter/VaultSync/pull/728
Windows, macOS and Linux build/test checks are passing on the implementation PRs involved in this work.
There is still a lot left before I would call 1.9 finished, especially:
- disk imaging
- bootable restore
- supported-system qualification
- exact upgrade testing from installed VaultSync 1.8.9 builds
So, to be very clear:
VaultSync 1.9 has not shipped.
This is still development work.
I wrote a longer version of this update on the FG Labs site, including more of the reasoning behind the CLI behaviour:
https://fglabs.dev/devlog/vaultsync-19-what-a-backup-script-can-know
I’m curious what people who actually script their backups care about most here:
Which distinction would help you most in a backup CLI: configured, reachable, backed up, or verified?