Hi everyone!
I've been working on VaultSync 1.9.0 for a while now, and I wanted to share a more detailed development update.
The first beta isn't available yet. I'm currently bringing the different parts of 1.9 together and working through the remaining qualification and release requirements.
This is one of the largest updates I've worked on for VaultSync, particularly because it introduces recovery capabilities where getting something wrong could mean losing data rather than simply encountering an application error.
Here's what's changed, what the tests uncovered, and what still needs work.
What's changing in the application?
Alongside the recovery work, several improvements are coming to the regular VaultSync experience:
- Imported projects: Projects imported from backups now remain visible under Projects, with an Imported badge. Their origin is tracked separately from whether their original local folder is still available.
- Better Unity backups: Unity exclusion presets now resolve consistently throughout the workflow. Saved
.pdataprofiler captures are also excluded, alongside generated files and caches. - Navigation and History: Back/Forward navigation and restoring the last visited page are being improved. I also fixed an issue where refreshing History could discard unfinished snapshot labels, notes, and tags.
These aren't the biggest architectural changes in 1.9, but they're improvements that should make everyday use more predictable.
The recovery bug that shouldn't have made it into a release
Most of my recent work has been inside the Linux disk-recovery engine.
The recovery pipeline is designed around a fairly strict principle: verify what you're about to write before allowing any destination writes.
There are separate checks when reading the original disk image, preparing a private staged copy, and verifying the prepared bytes before writing. After writing, the destination is read back and checked again.
During negative testing, I deliberately modified a prepared recovery payload to see whether the engine would refuse it.
It exposed a real bug.
A 128 KiB read buffer could return stale data after seeking within a file. Under the tested conditions, this allowed writing to begin even though the prepared payload had been modified.
The final verification still detected the mismatch and reported failure. But that's not good enough for disk recovery.
Detecting corruption after writing has started is not the same as preventing an unsafe write.
I removed that buffer from the native read-only reopening path and repeated the mutation tests.
The corrected behavior is now:
- Modified metadata: rejected before writing.
- Modified payload: rejected before writing.
- Both 512-byte and 4096-byte sector configurations: tested.
- Destination writes before rejection: zero.
It's a relatively small implementation change, but an important safety boundary.
And for once, seeing a progress bar remain at 0% was exactly what I wanted.
What has actually passed testing?
The October 22 release-check run passed:
- 2,061 Core tests
- 285 Python tests
- 36 additional reader/staging cases in a dedicated Linux VM
The VM tests used real private files and an in-memory restore target. No personal disks were involved.
These results are encouraging, but I want to be clear about their scope.
They do not establish that full disk recovery works, that a restored operating system will boot, or that the recovery workflow is ready for general use.
Those are separate qualifications that still need to happen.
What's left before the beta?
The remaining work includes write authorization and exact destination confirmation, bootable recovery media and its interface, full recovery and interruption testing, installed-upgrade checks, package signing, and release reviews.
All four candidate disk profiles are still unqualified.
I'm also continuing research into custom compression, but there's no new production backup format being introduced in this update.
I don't have a beta release date to announce yet. I'd rather spend more time validating the recovery path than ship something that merely looks ready.
Full development diary
I've published a longer write-up with development UI screenshots, a recovery pipeline diagram, the testing results, and a more detailed explanation of their limitations.
Read it here:
https://fglabs.dev/devlog/vaultsync-190-pre-beta
The UI screenshots are genuine development captures using synthetic data, reused from earlier development diaries for this recap. They aren't screenshots of a finished disk-recovery interface.
One question for the community
For those of you who have used disk imaging or recovery tools:
What information would you want to see before confirming a destination that is about to be overwritten?
I'm particularly interested in what makes that final confirmation feel trustworthy, rather than just another warning dialog people instinctively click through.
As always, thanks to everyone following the development of VaultSync, testing releases, reporting issues, or sharing feedback. It genuinely helps shape where the project goes next.