One of the things I really do not want VaultSync to do is show a green checkmark for something that has never actually been proven to recover.
That matters a lot more now because 1.9.0 is starting to lay the groundwork for disk imaging.
A disk image can validate perfectly and still leave you with a machine that does not boot, cannot see the disk, fails to unlock encryption, or comes back in a state that is technically restored but practically useless.
So before implementing the actual imaging engine, I have been working on the qualification system that will eventually decide whether a disk-recovery path is allowed to be considered supported.
Right now the repository deliberately gives these two different results:
$ python3 scripts/disk_support.py check Disk qualification plan valid: 4 profiles, 0 qualified; structural checks do not prove recovery. [exit 0] $ python3 scripts/disk_support.py check --require-qualified No qualified disk profile; stable disk support remains gated. [exit 1]
And that second failure is intentional.
The qualification plan itself is structurally valid.
Actual disk recovery is not qualified yet.
For a profile to pass, the evidence has to cover the whole chain:
capture → validate image → independent boot → restore → validate restored system
And all of that evidence has to belong to the same qualification run, image, builds and environment.
A successful boot from another test cannot be reused. A simulated result does not count. A VM test cannot be used as evidence that physical hardware works.
I also found and fixed a hole in the checker today.
It was possible to submit evidence where the disk capture happened before the recorded approval of the engine being tested. The checker now rejects that ordering, along with invalid approval artifacts.
All 124 Python tests are passing locally.
Those tests use synthetic qualification reports to make sure the rules themselves work. They are not treated as evidence that an actual machine was restored.
That distinction is pretty important here.
A hash can prove that a report has not changed.
It cannot prove that what the report claims actually happened.
First proposed disk profile
The first engine proposal is intentionally boring and narrow:
- offline Linux recovery media
- GPT / UEFI
- ext4 or NTFS
- 512 / 4096-byte sectors
Things like live capture, Secure Boot, encryption and less common layouts are outside that first proposal.
The actual imaging engine still needs to be selected and approved.
There is no disk imaging engine or recovery medium implemented yet. Stable is still VaultSync 1.8.9.
The CLI work from the earlier 1.9 development is still there as well. The current roadmap has discovery continuing in 1.9.1, with resource automation later in 1.9.5.
1.9.0 is the first step in that sequence, and the PR is still a draft:
https://github.com/ATAC-Helicopter/VaultSync/pull/736
Full dev update, including the qualification/evidence details:
https://fglabs.dev/devlog/vaultsync-190-when-a-green-check-is-not-recovery
For anyone here who has actually had to restore an entire machine from an image:
what failed after the image itself had already verified successfully?
Bootloader? Disk detection? Encryption? Drivers? Or did the machine boot but the actual application/system state was wrong?
Those are exactly the failures I want this qualification process to catch before VaultSync ever calls a disk-recovery path “supported.”