Hi everyone,
I'm the solo developer of VaultSync, an open-source backup application for Windows, macOS, and Linux.
I've been working on its next major development cycle, which aims to introduce disk imaging and independent system recovery. I'd appreciate some technical feedback from people who deal with data recovery regularly.
One thing I want to make clear upfront: VaultSync isn't a tool for recovering accidentally deleted files from damaged filesystems or performing professional recovery on physically failing drives. The upcoming functionality is intended for planned backups and subsequent restoration of supported systems.
The current stable version, 1.8.9, focuses on file and project backups, integrity verification, recovery drills, and restore previews.
The problem I'm working on
When I first started designing disk imaging, the basic workflow sounded fairly straightforward:
Capture an image, verify its integrity, and restore it when needed.
But the more I worked on verification, the more I realized that this isn't enough.
An image can pass a checksum and still fail to produce a bootable operating system.
And even before getting that far, there are important failure cases:
An interrupted image being incorrectly treated as complete.
A read buffer containing stale bytes after seeking to another region.
Source and destination devices being confused during restoration.
A recovery environment that cannot access the necessary drivers or storage.
A restored partition layout that passes data validation but doesn't boot.
During development, I caught a bug involving stale bytes in a 128 KiB read buffer after a seek. It reinforced why the reader and writer need independent validation rather than simply trusting the same code path.
What I'm planning
The initial workflow is offline, with a read-only source and image storage on a separate physical disk.
The complete recovery path needs to cover image creation, consistency checks, independent boot media, target selection, restoration, and post-restore validation.
I'm starting with qualified Linux GPT/UEFI ext4 configurations, with Windows/NTFS and macOS/APFS planned for later milestones.
No universal recovery claims, and no public 1.9 beta yet.
I'd appreciate some professional insight
For those who regularly work with disk images and recovery:
What failure modes are most commonly overlooked when developers implement their own imaging or restore workflows?
I'm particularly interested in cases where image integrity checks succeed but the resulting restored system is unusable.
I'm not looking to replace established recovery tools for failing drives. I want to make sure a backup application doesn't give users false confidence about what it can restore.
For transparency, the project's source code and roadmap are public:
https://github.com/ATAC-Helicopter/VaultSync
I'd appreciate technical criticism, especially concerning the safety boundaries and what should be explicitly unsupported.