VaultSync 1.9 has a name now, a working release branch, a release contract, and a roadmap that finally feels like one system instead of a pile of ambitious recovery ideas.
The family is called Recovery Horizon.
The simple version is that VaultSync 1.8 asked, “what was protected, what changed, and what evidence says I can recover it?”
1.9 asks a much less comfortable question:
What happens when the disk — or the machine itself — is the thing that failed?
That question is why the release has grown well beyond the original “add disk cloning” idea.
It is also why the first concrete 1.9 work is not a shiny cloning screen.
The first real 1.9 work is the CLI
As I write this on September 22, the release/1.9.0 branch is 14 commits ahead of Stable. VaultSync 1.8.9 is still the current public release; none of this 1.9 work has shipped yet.
The visible implementation work so far is a fairly large CLI rework.
That may sound like an odd place to begin a release whose headline feature is disk and bootable recovery, but it is deliberate. A recovery system that only works through one desktop UI is a weak foundation for automation, diagnostics, emergency use, and eventually clean-machine recovery.
The development branch now includes:
- grouped projects, snapshots, and recovery command families while retaining compatibility routes;
- candidate source-folder discovery;
- an explicitly named mirror command so live mirroring cannot be confused with a recorded backup;
- project inspection by literal name or explicit ID, with filtering and limits;
- versioned, opt-in JSON result envelopes for read-only project inspection;
- versioned snapshot history and bounded snapshot-diff results;
- snapshot detail inspection with History markers, change summaries, and recorded-backup references;
- rejection of snapshot IDs that belong to another project before a diff can read their paths;
- an explicit database selector for unattended watcher sessions;
- safer quiet/unattended project removal that requires an explicit --yes;
- watcher cancellation that detaches handlers, drains queued work, and returns exit 130 cleanly;
- removal of raw command-line argument logging at startup;
- a proper no-argument CLI introduction instead of dropping the user into a wall of command syntax;
- a packaged CLI handbook and an exhaustive generated command reference available through the CLI itself.
The command reference currently runs to hundreds of lines because it is generated from the registered command tree instead of being maintained as a second, slowly rotting description of the application.
There is still a lot missing. Bulk workflows, complete unattended behavior, shell completion, packaged PATH guidance, independent headless recovery, and final CLI parity all remain on the roadmap.
But this is already code, tests, documentation, and behavior on the 1.9 branch — not a mockup.
Why cloning is still behind a gate
The destructive disk work is intentionally not being implemented just because 1.9 is open.
Before VaultSync is allowed to make normal product claims about disk recovery, the roadmap requires an architecture gate covering the imaging engine, image format, platform and filesystem support, partition layouts, encryption, live capture, Secure Boot, recovery-media signing, drivers, hardware qualification, and failure behavior.
The image format itself needs rules for incomplete and resumable images, integrity records, compression and encryption descriptors, source identity, partition layout, reader/writer compatibility, and corrupt-state detection.
The important invariant is simple:
an incomplete image must never be able to look like a valid recovery point.
The same applies to destructive restore operations. Source and destination identity must be explicit. Wipe and overwrite plans must be exact. Interrupted writes need a known authoritative state. Unsupported combinations must be described as unsupported instead of being converted into optimistic green checks.
A prototype can help answer an engineering question.
It cannot become a support claim by accident.
What 1.9.0 is actually trying to prove
The 1.9.0 Stable gate is not “VaultSync can clone a disk.”
The target path is:
capture → validate → boot independently → restore → validate again
That means the first Recovery Horizon release is planned around:
- isolated disk and partition imaging;
- safe source/destination identity and capacity checks;
- interruption and resume semantics;
- block and image verification;
- bootable recovery media for supported UEFI systems;
- offline device discovery;
- restoring supported images from that environment;
- evidence tying creation, validation, boot, and restore to the source machine and tool version;
- qualification on representative real hardware and virtual machines.
This is also where I want to keep the wording disciplined.
VaultSync will not claim universal bare-metal recovery. Filesystems, encryption, Secure Boot, live capture, and hardware combinations will have an explicit supported matrix.
If a combination has not been qualified, the product should say so.
Recovery software has very little room for confident guessing.
The interface is changing, but not in one giant rewrite
There is a separate UI migration program inside 1.9.
The direction is built around four user goals:
Protect · History · Recover · Manage
I do not want that to turn into the usual “new major version means every screen moved” exercise.
The plan is staged. Existing workflows remain available until their replacement is complete, keyboard-accessible, localized, state-preserving, and proven against the same underlying operations.
The first shell work appears around Clone Explorer and the new route/state infrastructure. Dashboard and Recovery move first. History and inspection follow. Projects, Backups, and Schedule eventually converge into a clearer Protection workspace.
The legacy shell is removed only when it no longer has a job.
A new sidebar is not a recovery feature.
Portable recovery comes before the big offsite expansion
This ordering changed while the roadmap was being tightened.
Originally it was tempting to push cloud/offsite destinations earlier because they are visible, useful features.
But storing data remotely is not enough.
A clean machine must be able to discover supported data, understand its format, unlock it, restore it, and verify the result without depending on the original installation database.
That is why 1.9.2 — Portable Recovery comes before the major offsite work.
The planned pieces include a standalone restore utility, an emergency recovery kit, a published backup/encryption format specification, compatibility and migration rules, and an emergency read-only policy.
The same discipline feeds directly into later CLI recovery and Binary Source Control: important data should not become unreadable just because the original application state disappeared with the failed machine.
Offsite protection has to finish with a restore
The current 1.9.3 — Offsite Protection plan covers S3-compatible storage, Backblaze B2, SFTP, resumable transfers, remote manifest validation, incomplete-upload cleanup, immutability/retention guidance, and multi-destination health.
But the useful acceptance test is not “upload completed.”
It is closer to:
fresh machine → locate data → authenticate → restore → verify
That is the difference between remote storage and an actual recovery path.
Binary Source Control is now part of the family — later
This is probably the largest roadmap addition.
Recovery Horizon now carries a later Binary Source Control track for binary-heavy projects: game assets, media, CAD, large design files, and other workflows where huge files and merge-hostile formats make ordinary source-control assumptions awkward.
This is not Git replacement.
It is not Git LFS compatibility.
It is not VaultSync snapshots renamed to commits.
The design is a separate repository model with immutable objects, content-defined chunking, repository-local deduplication, changesets, guarded refs, workspace sync, exclusive path locks, verification, repair, encryption, and clean-machine recovery.
The architecture also borrows a lesson already learned in VaultSync's cross-machine repository work: a long-lived editing lock must not be the same thing as a short repository writer lease.
Binary Source Control is intentionally sequenced after the core recovery path so it cannot hold disk/boot recovery hostage.
And it has its own architecture gate.
No stable-format implementation should begin until repository format, collaboration semantics, encryption/recovery boundaries, GC/repair invariants, locking, conflict behavior, and backend assumptions are reviewed together.
If the safety gates are not met, BSC stays Preview. It does not get to block the earlier Recovery Horizon releases.
The current sequence
| Release | Focus |
|---|---|
| 1.9.0 | Disk and Bootable Recovery foundation + CLI command/automation foundation |
| 1.9.1 | Clone Explorer + first adaptive shell migration + CLI discovery |
| 1.9.2 | Portable Recovery + independent headless recovery |
| 1.9.3 | Offsite Protection |
| 1.9.4 | Unified Recovery Experience |
| 1.9.5 | Continuous Recovery Assurance + CLI parity/qualification |
| 1.9.6 | Binary Source Control Foundation |
| 1.9.7 | Binary Collaboration and Scale |
| 1.9.8 | Stability and LTS baseline |
The current roadmap target for 1.9.0 is March 26, 2027, with the wider 1.9 family horizon on September 24, 2027. Those are planning targets, not permission to ship an unsafe recovery path because a calendar says so.
What is actually done, and what is not
I want this part to stay very clear because roadmaps are good at making planned work look deceptively real.
Already implemented or established:
- the 1.9 release branch and release contract;
- the CLI audit and initial command/behavior contracts;
- the CLI changes described above;
- tests around the new inspection, documentation, watcher, resource, and structured-output behavior;
- the Recovery Horizon sequencing and architecture gates;
- the Binary Source Control strategy and work breakdown;
- the staged UI migration strategy;
- the existing background repository-integrity audit, which is historical 1.9 foundation work already delivered earlier.
Not implemented yet:
- disk or partition cloning;
- the 1.9 disk-image format;
- bootable recovery media;
- image-to-disk recovery;
- Clone Explorer;
- the new 1.9 shell;
- standalone portable restore;
- native S3/B2/SFTP destinations;
- Binary Source Control storage, workspaces, locks, branches, or collaboration.
That second list is the reason this is a development diary rather than a release announcement.
Why this release is going to take a while
VaultSync 1.8 spent a lot of time building evidence: verification, restore drills, Recovery Inspector state, History events, portable evidence, cross-machine coordination, interruption behavior, and increasingly strict release qualification.
Recovery Horizon is trying to reuse that work at a larger scale instead of creating a second, less careful recovery system beside it.
Files become images.
A project restore becomes an offline machine recovery path.
Repository health becomes portable recovery.
Eventually, binary project history becomes another kind of recoverable state with its own concurrency and corruption problems.
That is a lot of surface area.
I expect multiple 1.9 betas before Stable. The purpose of those betas will be qualification and real recovery feedback, not just having prerelease badges available.
The current roadmap is finally detailed enough that I can see where the boundaries are, which parts are allowed to depend on each other, and which features must stay out of the way until the recovery foundation is ready.
That is a much better place to start building from than “disk cloning would be cool.”
The documents are public
If you want the engineering version rather than this diary:
- Recovery Horizon roadmap
- 1.9.0 release contract
- CLI rework notes
- CLI handbook
- Binary Source Control strategy
The thing I am most interested in hearing from people who actually maintain backups is this:
If your main machine died tonight, which part of the recovery chain would you be least confident about — creating the image, booting recovery media, finding the right recovery point, restoring it, or proving the restored system is actually good?