Hey everyone,

I finally published the first proper development diary for VaultSync 1.9 — Recovery Horizon.

And I think the biggest change since I first started talking about 1.9 is this:

it is no longer just “the disk cloning update.”

The original idea was much simpler:

disk cloning → browse the clone → restore it.

But the more I worked through what a real recovery workflow actually needs, the less comfortable I became with shipping cloning as an isolated feature.

A disk image is not enough if VaultSync cannot prove that it is complete.

A restore feature is not enough if it depends on the installed OS still working.

And “bare-metal recovery” is not something I want to put on a feature list unless the complete path has actually been tested.

So the current goal for 1.9.0 is closer to:

capture → validate → boot independently → restore → validate again

That means disk/partition imaging, source and destination safety, interruption handling, image verification, bootable recovery media, offline restore, and actual recovery evidence.

The funny part: the first real 1.9 code is not cloning

The release/1.9.0 branch is already moving, but the first substantial implementation work has been a large CLI rework.

I know that is not the exciting screenshot feature 😅

But it makes sense for where VaultSync is going.

A recovery system should not depend entirely on one desktop UI, especially when 1.9 is eventually supposed to support automation, diagnostics, clean-machine recovery, portable restore, and emergency workflows.

The current development branch already adds things like:

• cleaner projects, snapshots, and recovery command groups
• project lookup by ID or name
• filtered project listings
• source-folder discovery
• a clearly separated mirror command
• snapshot inspection
• snapshot history
• bounded snapshot diffs
• versioned JSON output
• safer unattended destructive commands
• cleaner Ctrl-C/cancellation behavior
• explicit database selection for watchers
• a proper CLI introduction screen
• a bundled CLI handbook
• a generated full command reference

This is all development work, not released functionality. 1.8.9 is still the current Stable release.

Disk recovery is deliberately still gated

The destructive disk work has not started as normal product implementation yet.

That is intentional.

Before VaultSync starts writing disks, I want the architecture around the image format, supported filesystems, partition layouts, encryption, live capture, Secure Boot, recovery media, corruption states, resumability, source/destination identity and hardware qualification to be decided first.

One rule I care about a lot:

an incomplete image must never be able to look like a valid recovery point.

If VaultSync does not know that something is safe or supported, I would rather have it say exactly that than confidently guess.

The rest of Recovery Horizon

The current 1.9 family is now roughly:

1.9.0 — Disk & Bootable Recovery
Disk/partition imaging, validation, bootable recovery media and offline restore.

1.9.1 — Clone Explorer
Browse images, search them and selectively recover files.

1.9.2 — Portable Recovery
Standalone restore utility, emergency recovery kit and documented recovery formats.

1.9.3 — Offsite Protection
S3-compatible storage, Backblaze B2, SFTP, resumable uploads and clean-machine recovery qualification.

1.9.4 — Unified Recovery Experience
Bring file, project, image and storage recovery together.

1.9.5 — Continuous Recovery Assurance
Scheduled verification, recovery drills, alerts and stronger automation.

And then there is a newer addition:

Binary Source Control

Later in the 1.9 family I am also planning a VaultSync-native Binary Source Control system.

Before anyone throws Git at me:

it is not meant to replace Git.

The target is large, binary-heavy projects where assets can be huge, hard to merge, shared across multiple machines, and often stored on NAS systems.

Game development is probably the obvious example.

The architecture currently explores:

• immutable binary objects
• content-defined chunking
• deduplication
• changesets
• safe workspace sync
• exclusive path locks
• stale-workspace protection
• repository verification and repair
• encryption
• clean-machine recovery

It is deliberately placed after the core recovery work.

If BSC takes longer than expected, it is not allowed to hold disk recovery hostage.

If it does not meet the required safety gates, it stays Preview.

The UI will change too

The current direction for 1.9 is:

Protect · History · Recover · Manage

But I am avoiding a giant UI rewrite.

Existing workflows stay until their replacements actually work, preserve state, remain accessible and localized, and have feature parity.

I do not want to move every button around just because the version number starts with 1.9.

This is going to take time

And this is probably the most important expectation to set.

1.9 is not a normal VaultSync update.

I expect multiple betas.

There is a lot of architecture and qualification work before some of the headline features should even be considered safe enough for Stable.

1.7 was largely about trusting stored data.

1.8 was about understanding what was protected and proving recovery.

1.9 is about expanding what VaultSync can recover when things go properly wrong.

Files → projects → disks → machines → portable recovery → offsite recovery → eventually binary project history.

The roadmap finally feels coherent enough that I am comfortable calling it the direction for Recovery Horizon.

I wrote the full technical breakdown here:

https://fglabs.dev/devlog/vaultsync-dev-diary-01-recovery-horizon-is-bigger-than-disk-cloning

And I would really like feedback on one thing:

If your main machine died tonight, which part of the recovery chain would you trust the least?

Creating the image?

Booting recovery media?

Finding the correct recovery point?

Restoring it?

Or proving that the restored system is actually good?

[link] [comments]