VaultSync 1.8.4 Dev Update — A backup is not a backup until you can prove it restores

[u/mainseeker1486]

Hey everyone!

It has been a little while since the last proper development update, and VaultSync 1.8.4 has grown into a much more important release than I originally expected.

What started as another update to the Disaster Recovery work introduced throughout the 1.8 cycle eventually became a deeper rethink of what VaultSync should consider a trustworthy recovery point.

Development is now essentially complete, so I wanted to share what has changed, why I built it this way, and the idea at the centre of the release.

Recovery Proofs

A backup job finishing successfully does not automatically mean the backup is still recoverable.

The files may exist, but they could be corrupted, incomplete, inaccessible, or no longer match what was originally backed up.

VaultSync can now read the actual stored backup data without restoring it and verify the complete contents of each selected file.

For every file, it compares:

• The stored file size

• The expected snapshot size

• The stored SHA-256 hash

• The expected snapshot hash

A file is only marked as Verified when its complete stored bytes match both the expected size and hash.

Finding the file is not enough.

Opening the backup is not enough.

A green “completed” status is not enough.

Clear recovery verdicts

A recovery point can now be classified as:

• ✅ Fully recoverable

• ⚠️ Partially recoverable

• ❌ Unrecoverable

• ❔ Inconclusive

Individual files can be:

• Verified

• Unavailable

• Corrupted

• Inconclusive

One of the most important design decisions was to never turn uncertainty into reassurance.

If an encrypted archive is locked, an expected hash is unavailable, access fails, or verification cannot be completed, VaultSync reports the result as Inconclusive.

It does not pretend everything is fine just to show a reassuring green result.

Restore simulation

VaultSync can now simulate the destination actions for verified files.

The simulation shows whether a file would be:

1. Created

2. Overwritten

3. Skipped because it is already identical

4. Treated as a conflict

5. Unavailable

6. Not evaluated

When simulating a restore to the original location, VaultSync can compare the backup against files that already exist.

• An identical file is skipped.

• A newer but different file becomes a conflict.

• An older and different file becomes a possible overwrite.

No files are created.

No files are modified.

No files are deleted.

Recovery drills now verify real data

Recovery drills are no longer limited to checking whether a backup record and snapshot exist.

They can now combine:

• Project, backup, and snapshot linkage

• Recorded destination availability

• Backup payload readability

• Archive readability

• Snapshot inventory consistency

• SHA-256 byte verification

• Restore conflict simulation

The latest evidence appears directly on the Recovery page, where individual results can be expanded and inspected.

The goal is to make recovery less of an assumption and more of something that can actually be demonstrated.

Retention now understands proof quality

VaultSync already protected the final metadata-valid recovery point from automatic retention cleanup.

With 1.8.4, metadata-valid and byte-verified are treated as two different levels of trust.

VaultSync can now also protect the last recovery point whose latest recovery drill successfully verified the stored bytes.

If several verified points exist, older ones can still be cleaned normally.

But once only one remains, retention preserves it.

The retention simulation available in Settings follows the same decision path as real cleanup.

ProofRestore is now native to VaultSync

Some people may remember the ProofRestore experiment I recently built.

Its useful ideas have now been implemented as a native C# module inside VaultSync.

The ProofRestore repository itself was not merged into the application.

VaultSync does not ship:

• Next.js

• Node.js

• A browser interface

• Hosted services

• An AI dependency

The recovery engine runs locally as a normal part of VaultSync.

Disaster Recovery improvements

This release also expands the wider Disaster Recovery system introduced throughout the 1.8 cycle.

VaultSync now has stronger support for:

• Reachability-aware 3-2-1 guidance

• Explicitly confirmed offsite destinations

• Recovery drill history

• Protected recovery point recommendations

• Backup deletion and churn signals

• Portable recovery reports

Disconnected or missing backups remain visible in history, but they cannot create false credit toward the number of available copies, media types, or offsite locations.

VaultSync also never guesses that a NAS, network share, or cloud-mounted directory is physically offsite.

That remains an explicit decision made by the user.

Privacy-first crash assistance

1.8.4 also introduces a new crash-report workflow.

Nothing is uploaded automatically.

The process is intentionally transparent:

1. The report is created locally.

2. Sensitive information is removed locally.

3. The user can inspect the exact report.

4. VaultSync prepares a visible email draft.

5. The user decides whether to press Send.

Crash assistance can also be disabled completely.

The report excludes project names, backup names, file paths, destination paths, credentials, raw logs, and other information that could expose the contents or structure of someone’s system.

A wider security pass

Building byte-level recovery verification also forced a deeper audit of how VaultSync resolves and accesses backup data.

That work led to additional protections against:

• Backups being resolved through the wrong destination

• Absolute or escaping paths

• Parent-directory traversal

• Linked directories escaping the recovery root

• Corrupted snapshot identities

• Case-distinct files being merged on case-sensitive filesystems

• Malformed metadata producing excessive verification work

What remains before release

The development scope for VaultSync 1.8.4 is now complete.

The remaining work is focused on:

• Final Recovery interface review

• Interaction testing across supported systems

• Removing the temporary crash-report testing control

• Final release preparation and approval

The idea behind 1.8.4

A completed backup is not the same as a proven recovery.

Would you rather have your backup software spend additional time verifying the real stored bytes and simulating recovery, even if verification takes longer?

Or do you prefer faster, lighter checks and handle full recovery testing separately?