Hi everyone!
I've published another development update on VaultSync 1.9.0, the upcoming release that introduces disk imaging, cloning, and system recovery.
This has become a much larger undertaking than a typical VaultSync update. I'm trying to build a recovery workflow that doesn't just create an image, but can also verify it, restore it safely, and demonstrate that the recovered system actually boots.
1.9.0 is still in pre-beta. There is no beta download available yet.
How the beta rollout will work
First, one important clarification: the VaultSync desktop application will continue supporting Windows, macOS, and Linux throughout the beta program.
What's being introduced gradually is the new disk recovery functionality.
- First milestone: Linux recovery, initially targeting qualified GPT/UEFI ext4 configurations.
- Second milestone: Windows system recovery on tested NTFS configurations.
- Third milestone: macOS recovery once the APFS and boot requirements have been implemented and validated.
Each milestone may require several beta builds. Every published build will have its own version number.
Offline imaging and recovery
The initial workflow uses an independent recovery environment rather than capturing a running operating system.
The source disk is kept read-only at the kernel level, and images must be stored on a different physical disk.
These are full raw images, meaning unused sectors and potentially recoverable deleted data are included. They require sufficient destination space and should be treated as sensitive data.
I've also been working on making recovery less intimidating.
Previously, the workflow expected users to know the exact location of their recovery image. That's not particularly helpful when you're trying to recover a computer that no longer boots.
The recovery interface now includes:
- A selectable list of available recovery copies.
- A refresh option.
- An advanced manual-folder selection for less common setups.
Verification and physical destination confirmation remain mandatory parts of the workflow.
What the latest test revealed
I want to be transparent about where things currently stand.
In the latest disposable virtual-machine test, VaultSync successfully captured the entire 3 GiB test disk, but the subsequent verification stage refused to continue.
No completed image was published, and the destination disk remained untouched.
I'm investigating that failure before moving forward. The full capture → verify → restore → boot validation sequence is still a requirement for the beta.
I'd rather have the software refuse an operation than report a successful recovery that hasn't actually been proven.
Other development work
Alongside disk recovery, 1.9.0 continues to receive improvements to the existing desktop experience:
- Better handling of imported projects.
- More reliable metadata refresh.
- Improvements to exclusion presets.
- Localization fixes.
- Separate compression experiments that preserve compatibility with existing backups.
The beta program will also introduce structured technical reporting, initially enabled with clear disclosure, respect for previous refusals, and controls to review or disable it.
Reports exclude file contents, paths, raw logs, memory dumps, credentials, and persistent user or device identifiers. Stable releases will continue requiring explicit opt-in.
What's next?
The priority is completing and validating the recovery workflow before publishing the first beta.
I know 1.9.0 is taking considerably longer than previous releases, but disk recovery is one of those areas where getting something almost right isn't good enough.
I'm developing VaultSync independently, and I appreciate everyone who's been following the project, testing releases, reporting problems, or sharing suggestions.
Full development article, technical details, and actual development screenshots:
https://fglabs.dev/devlog/vaultsync-190-recovery-and-beta-rollout
One question for anyone who's worked with disk imaging or recovery software:
Which failure would you prioritize testing first?
- A disk whose device identity changes between operations.
- An interrupted restoration.
- A corrupted or incomplete image.
- A restoration that finishes successfully but produces an unbootable system.
I'm particularly interested in the failures that existing recovery tools handle poorly.