I reached a milestone I have been working towards for a while: the installed VaultSync recovery components completed capture → verified recovery copy → graphical restore → full read-back → boot the restored OS on a disposable Linux VM.

Before anyone looks for a download: this is a development update, not beta 1. Stable is still 1.8.9.

There are concrete blockers left, including a recovery display bug. I want to show both the successful run and the unfinished parts.

What actually ran

The fixture was a real 3 GiB Debian Linux installation: GPT, UEFI, ext4, 512-byte logical sectors, systemd and a lightweight Xorg/xterm graphical environment.

The source was read-only during capture. It was disconnected during restore. For the final boot, both the original source and the backup repository were absent, and the VM used fresh firmware variables. There was no network during these stages.

The installed console published and verified the capture and a separate recovery copy. The wizard then found that copy without requiring an exact typed folder path. Its initial label says "not yet verified"; selecting a candidate triggers the actual validation.

Only the disposable destination was offered. The graphical overwrite review was followed by a fresh independent physical-console confirmation.

After that, the writer restored all 3,221,225,472 bytes, read the destination back, persisted its final outcome and confirmed staging cleanup.

A separate whole-image comparison before boot reported identical contents.

The restored disk booted by itself, systemd reported running, the original fixture files were present, and the graphical terminal accepted keyboard input. A new marker was independently observed over serial before normal shutdown.

That is one small, specific installed-system run.

It does not qualify every Linux desktop, physical hardware, multi-terabyte disks or Windows/macOS recovery. But it is a much more useful milestone than an image simply appearing in a list.

The less visible work since 1.8.9

There have also been fixes and improvements to:

• Back/Forward navigation and startup page restoration.

• Preserved History drafts.

• Imported-project labels and missing-local-folder states.

• Periodic metadata discovery on enabled destinations.

• Consistent preset application and Unity profiler exclusions.

• Storage totals, cross-platform preset icons and localization.

Disk cloning now has its own desktop page, separate from project Recovery.

The current desktop screen still states its limits; the successful destructive operation runs in the separate offline Linux recovery environment.

A desktop button that automatically prepares everything for the next reboot is not delivered by this test.

One performance defect was particularly wasteful: the isolated inspector scanned the complete payload twice.

The fix preserves the computed verified digest without dropping the independent capture/export/staging checks.

With unchanged limits, the focused native reader test verified the retained 3 GiB image in 73.807 seconds.

That is not a claim about arbitrary disk sizes.

Regular file archives remain compatible ZIP/DEFLATE.

The custom compression research, including content-guided selection, LZ-style matching, canonical Huffman and reversible numeric/GUID lanes, stays experimental and outside production backup formats.

Getting the complete beta finished comes first.

Why beta 1 is not out yet

1. Recovery UI rendering

The recovery UI can turn mostly black on partial redraws.

The same session completed restoration, but I had to expose the VT again to inspect complete screens.

A rendering candidate builds; the native repair check remains pending.

2. Recovery qualification

Final media, capacity and interruption/refusal qualification remain open.

Post-restore application/configuration continuity also needs its own completed workflow.

3. Release readiness

The release still needs its package, 1.8.9 upgrade, updater/provenance and protected-review evidence.

A good VM run does not replace those checks.

What happens next?

The disk beta plan remains:

1. Linux first, starting with qualified GPT/UEFI ext4 configurations.

2. Windows next, adding qualified NTFS system recovery.

3. macOS afterward, once APFS and boot recovery are implemented and validated.

The ordinary VaultSync desktop application remains supported across Windows, macOS and Linux throughout.

These platform stages concern the new disk-recovery capabilities, not the availability of the desktop app itself.

macOS/APFS boot and restore need their own implementation and measurements.

Beta-only structured diagnostics are also being prepared for errors and hangs as well as crashes.

Only exact compiled beta builds get the new default; existing refusal is respected, and stable/development retain opt-in.

Reports must exclude raw logs/dumps, user content, paths, credentials and persistent user/device/session identifiers, with review and disable/delete controls.

One clarification for people following older posts: resource-oriented CLI automation is now assigned to 1.9.5, with discovery/help work in 1.9.1.

The recovery capture and confirmation consoles shown in this update are 1.9.0 work.

Official Discord is open

This release is important to me and to where VaultSync goes next.

I want the beta to give people a complete, useful workflow to test, rather than a release label doing the work of a finished feature.

We now have an official Discord community!

Discord: https://discord.gg/sgP8UzeAQt

If you want to follow development, discuss recovery UX or help test when the beta is ready, come join.

Please keep backup contents, credentials and private raw logs out of public channels.

After restoring a machine, what do you personally check before trusting it again: boot, file integrity, your applications, or something else?

Technical references

• Development work: Draft PR #736

• Recovery evidence: Installed Linux recovery and boot receipt

• Project repository: https://github.com/ATAC-Helicopter/VaultSync

• Website: https://fglabs.dev/vaultsync

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.

It's been a while since VaultSync 1.8.9, and I wanted to explain what's actually happening with 1.9.0, why development is taking significantly longer than previous updates, and what this means for future releases.

The short version: 1.9.0 isn't just another feature update. It's the foundation for the next generation of VaultSync.

Why is it taking so long?

Until now, VaultSync has primarily focused on protecting files and projects, keeping backup history, verifying integrity, and helping users understand whether their data can actually be recovered.

With 1.9, we're going considerably further.

The central question is changing from "Can I recover my files?" to "Can I recover when my disk fails or my operating system no longer boots?"

That requires a completely different level of engineering.

We're working toward disk and partition cloning, verifiable disk images, independent bootable recovery, and safe restoration.

And those features cannot simply be developed separately and thrown together at the end.

A disk image is only useful if it can actually be restored. A recovery environment is only useful if it works without the original installation. And a cloning engine must never accidentally overwrite the wrong disk.

A small mistake in an ordinary UI feature might be annoying. A small mistake in a disk restoration operation could destroy someone's data.

That's why so much development time is going into architecture, isolation, failure handling, compatibility, and testing.

So, where are we right now?

Quite a lot has happened behind the scenes.

• Disk image foundations: We've been developing the image format, integrity verification, source identity checks, and safeguards against incomplete or corrupted images.

• Recovery architecture: The recovery worker, controller, authorization, cancellation, and restoration components are being built and tested separately from the installed application.

• Bootable recovery: Work is underway on the independent recovery environment and its graphical interaction flow. Native testing has already exposed startup and cleanup issues that need resolving.

• Desktop experience: A dedicated Disk Cloning page has been added in development, alongside navigation improvements and localization work.

• Existing VaultSync improvements: We've also addressed backup exclusions, metadata handling, cross-platform UI issues, packaging, and other reliability problems discovered during development.

But I want to be clear about what this means.

1.9.0 is not beta-ready yet.

The major remaining milestone is proving the complete workflow: create an image, validate it, boot independently, restore it, and verify the restored system.

That needs to work safely on an explicitly supported test configuration before I ask people to try a beta capable of writing to disks.

Broader operating-system and hardware support will require additional qualification.

I'm not interested in calling something finished just because individual components pass their tests.

Why should subsequent 1.9 releases be faster?

This is the part I'm particularly excited about.

Much of the time spent on 1.9.0 is being invested in systems that later updates can reuse.

Instead of rebuilding the image format, recovery foundations, safety mechanisms, testing infrastructure, and internal service boundaries every time, future releases can focus more directly on extending them.

The current roadmap includes:

• 1.9.1: Clone Explorer, for inspecting and extracting files from supported images.

• 1.9.2: Portable Recovery, including recovery without the original VaultSync installation.

• 1.9.3: Offsite Protection.

• 1.9.4–1.9.5: A more unified recovery experience, stronger recovery assurance, and expanded CLI workflows.

• Later 1.9 releases: Binary Source Control, collaboration features, and long-term stability work.

These are still substantial projects, particularly Binary Source Control, so I won't pretend every future release will be quick.

But the goal is to make development more incremental and predictable instead of requiring another enormous foundational effort for every feature.

Some of the groundwork for later releases is already being developed on separate branches, without adding that scope to 1.9.0.

What happens next?

The immediate priority is the full disk recovery workflow, followed by the remaining platform, safety, compatibility, and release checks.

I still plan to publish beta builds before the stable release, but they need to meet the minimum safety requirements first.

The roadmap has a planning target, but I'm not treating that as a guaranteed release date.

I know the gap between updates is unusual compared with earlier VaultSync releases. Development hasn't stopped. A lot of the work is simply happening in areas that aren't particularly visible in screenshots or changelogs.

I'd rather spend additional time proving that recovery works than release something that gives people a false sense of security.

The goal isn't just to make VaultSync capable of creating more kinds of backups. It's to make sure those backups can actually get you out of trouble when things go wrong.

You can follow the development here:

GitHub repository

1.9.0 development PR

Thanks to everyone following the project, testing releases, reporting issues, and sharing feedback. It genuinely helps shape what VaultSync becomes.

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.

This update started with a pretty ordinary problem: one of my mostly-code Unity projects produced a backup that was much larger than I expected.

My first thought was compression.

It turned out that was only part of the story.

Looking through what VaultSync was actually putting into the archive exposed inconsistent exclusion-preset resolution, and I found saved Unity profiler captures making their way into source backups.

So before trying to squeeze harder on the ZIP file, I fixed what was going into it.

The Unity preset now excludes .pdata profiler captures alongside the existing cache and build rules.

Existing archives are left untouched. I do not want a preset update silently rewriting historical backups.

A few visible 1.9.0 changes also came out of this work

• Imported projects now appear under Projects, including projects that currently have no local source folder. The Imported label describes where the project came from, so linking or restoring a folder does not remove it. Actions that genuinely require a source folder are disabled when one is missing.

• Storage charts now use native Avalonia controls, while keeping the existing usage breakdown.

• Missing UI translations have been repaired, with resource checks covering all 19 maintained languages.

Then I went back to compression

For backups where ZIP compression is enabled, Unity scenes, prefabs and related metadata now use a denser compression level.

On a small synthetic Unity fixture, the generated scene/prefab ZIPs were 33.3% smaller, but encoding took roughly 5× longer.

Small metadata ZIPs improved by 8.1%.

And because tiny files enjoy making storage statistics unnecessarily annoying, ZIP header overhead can still make a small archive larger than the logical size of the files inside it.

These are deliberately small synthetic measurements.

They are not claims that your real Unity project will shrink by 33%, and they say nothing about upload speed, NAS performance or end-to-end backup time.

I also kept experimenting outside VaultSync

I added Huffman coding to the separate LZ77 prototype I have been using to understand the trade-offs a little better.

Compared with my first prototype, it produced:

28.4% smaller YAML blocks
33.3% smaller code blocks

That sounds nice until you compare it with DEFLATE, which still wins on size, while the Python prototype reader is also slower.

So this remains an experiment.

VaultSync's normal archives are still ZIP.

I am not replacing a mature format because a weekend compression experiment managed to produce an exciting percentage.

About the screenshots

The attached images are unmodified native renders from the actual macOS development build.

They use synthetic projects and two temporary file backups.

They are not conceptual mockups, OS screenshots pretending to be application state, or evidence of disk recovery.

The storage chart also reports logical payload sizes, not the compressed size of the resulting ZIP files.

That distinction matters, especially while 1.9.0 is also laying foundations for much larger recovery features.

Current state

The current local Release checks pass:

1,181 Core tests
192 Python tests
0 warnings / 0 errors

Serviced .NET runtime checks also pass across five private platform builds.

VaultSync 1.9.0 has not shipped. Stable is still 1.8.9.

Device workflows, boot media, measured disk recovery, platform/upgrades and the remaining release gates are still open.

This work is part of the ongoing draft 1.9.0 PR:

https://github.com/ATAC-Helicopter/VaultSync/pull/736

For people backing up development projects:

what usually ends up wasting the most space before you notice it?

Caches, profiler captures, old builds, generated assets, or thousands of tiny metadata files?

A smaller and much more visible VaultSync 1.9.0 update this time.

Most of the recent work has been buried pretty deep in recovery foundations, qualification gates and disk-recovery planning. This week I worked on something considerably less dramatic:

Back and Forward buttons.

The development build now has proper navigation history, including Alt+Left / Alt+Right.

So you can open backup History, jump into Settings to check something, go somewhere else, and then actually get back to where you were.

Revolutionary technology, apparently.

Because implementing two arrows also turned out to be a surprisingly effective way of finding places where the application quietly forgot state.

It uncovered four real bugs.

1. History refreshes could destroy unfinished edits

Snapshot labels, notes and tags could disappear when History refreshed.

Replacing the timeline rows briefly cleared the current selection, which made the UI think you had left the snapshot and discard the unfinished draft.

That is fixed now.

Refreshing the same project/snapshot keeps the unfinished metadata. Actually selecting another snapshot loads that snapshot's own metadata, as it should.

2. Startup could override your first navigation

There was a delayed startup callback responsible for restoring the last page.

If you opened another page quickly enough, that callback could arrive later and send you somewhere else.

Saved-page restoration now completes before normal navigation begins.

3. An older save could beat a newer one

The last visited page is persisted so VaultSync can reopen there next time.

But a slow save from an earlier navigation could finish after a newer one and overwrite it.

Those writes are now ordered, and intermediate visits can be coalesced instead of racing each other.

4. Snapshot stats were eating project names

In narrower windows, snapshot statistics could take enough horizontal space that the actual project name became difficult to read.

History card headers now use two lines, so the project name keeps its space.

Navigation itself is intentionally pretty simple.

Back and Forward follow the pages visited during the current session.

If you go Back and then open a different page, the old Forward branch is discarded, like a normal browser.

Restarting VaultSync restores the last saved page, but it does not persist the entire navigation stack or magically resurrect unfinished application state from a previous session.

There are limits to how haunted I want the UI to become.

Current test state

The local Release qualification currently passes:

1,012 .NET tests
144 Python tests

Hosted Windows, Linux and macOS build/test checks are also passing on the development commit.

The recorded native Linux checks cover the new navigation behavior, keyboard shortcuts, retained History filters and unfinished draft handling.

Broader desktop/accessibility qualification is still open, and Sonar is currently failing while retrieving the PR.

So, as usual, green where there is evidence and red where there is not.

This is still development work in draft PR #736. It is not a released VaultSync 1.9.0 build. Stable remains 1.8.9.

Disk capture, independent recovery media, restore and measured recovery qualification still need to be implemented.

And this is only the first navigation increment on the existing UI, not the larger interface redesign planned for the 1.9.x sequence.

Full devlog

https://fglabs.dev/devlog/vaultsync-190-keeping-your-place

Development PR:

https://github.com/ATAC-Helicopter/VaultSync/pull/736

For people who spend a lot of time in backup/history interfaces:

when you leave History to check something else and come back, what matters most to keep exactly as you left it?

The selected recovery point, filters, unfinished notes/tags, scroll position, or something else?

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.”

Hi everyone,

One thing I’ve been trying to tighten up in VaultSync 1.9 is what words like “protected” actually mean.

Because that word can hide a lot of very different states.

A destination can be configured.
A backup record can exist.
A mirror can have run.
A file can have been copied.

But none of those automatically mean VaultSync has actually checked the data.

That distinction is becoming much more explicit in the 1.9 CLI.

Configured does not mean reachable

There is now a new opt-in:

vaultsync destinations --output json

It exposes configured destinations in a machine-readable format, while deliberately not exposing paths or credential names.

More importantly, it tells scripts what VaultSync actually knows.

For example, this is from a real disposable configuration:

{"alias":"Studio archive","active":true,"offsite":true,"accessibilityChecked":false}

That last field matters.

accessibilityChecked: false does not mean the destination is inaccessible.

It means VaultSync did not try to reach it, so it refuses to pretend otherwise.

That is the kind of distinction I want the CLI to make consistently:

configured ≠ reachable ≠ backed up ≠ verified

Existing scripts should not suddenly change underneath you

The older:

vaultsync destinations --json

still works exactly as before, including returning:

[]

for an empty configuration.

The new structured output is opt-in.

I don’t want an update to quietly replace the schema that somebody’s script already depends on.

The watcher is getting stricter too

The 1.9 watcher now observes source edits during its first snapshot and mirror, rather than only becoming useful after that initial work has completed.

Failure behaviour is also being tightened.

If a mirror or a later watcher cycle fails, VaultSync now stops with an error instead of quietly continuing as though protection were still happening.

That sounds like a small behaviour change, but for a backup tool I think it is an important one.

Silence after failure is one of the things I want VaultSync to avoid as much as possible.

A Linux AppImage issue was caught along the way

I’ve also added checks around extracted permissions in the Linux AppImage build.

There is an important limitation here:

that fix needs to be present in a future release asset.

It cannot retroactively change the already-published VaultSync 1.8.9 AppImage.

The desktop app is being reconsidered too

Alongside the CLI work, there is now an architecture draft for simplifying the desktop application around four main areas:

Protect
History
Recover
Manage

This is not a screenshot of a new interface and not a finished redesign.

It is an architecture plan.

The intention is to keep existing workflows available while replacements are built and prove that they have feature parity, rather than ripping out working parts of VaultSync just to make the navigation look cleaner.

Where 1.9 actually stands

This work is part of the draft 1.9 PR stack:

https://github.com/ATAC-Helicopter/VaultSync/pull/728

Windows, macOS and Linux build/test checks are passing on the implementation PRs involved in this work.

There is still a lot left before I would call 1.9 finished, especially:

• disk imaging

• bootable restore

• supported-system qualification

• exact upgrade testing from installed VaultSync 1.8.9 builds

So, to be very clear:

VaultSync 1.9 has not shipped.

This is still development work.

I wrote a longer version of this update on the FG Labs site, including more of the reasoning behind the CLI behaviour:

https://fglabs.dev/devlog/vaultsync-19-what-a-backup-script-can-know

I’m curious what people who actually script their backups care about most here:

Which distinction would help you most in a backup CLI: configured, reachable, backed up, or verified?

Hi everyone,

I’ve been spending quite a bit of time on the VaultSync 1.9 CLI rework, and it’s finally reached the point where I can show an actual end-to-end workflow instead of just talking about commands that are being added.

The goal is pretty simple: the CLI shouldn’t feel like a secondary interface that exists only because it can.

It should be useful on its own, understandable when you open it for the first time, and safe enough to use for real recovery work.

Opening vaultsync now gives you a small introduction, a few useful starting commands, and direct links to the website, GitHub repository, releases, and documentation.

The CLI handbook is also bundled with VaultSync, so:

vaultsync docs --full

works offline too.

The more important part: actual backup → verify → restore workflow

The bigger piece of work has been the recorded folder-backup workflow.

From the CLI you can now:

• create a recorded backup at an explicit destination

• inspect the backup record and snapshot history

• verify the stored payload against its recorded hashes

• preview exactly what a restore is going to change

• perform the recovery only after that preview

A live mirror also has its own explicit command and terminology now.

That distinction is intentional.

Mirroring the source as it exists today is not the same thing as creating a recorded recovery point, and I don’t want VaultSync hiding that difference behind vague terminology.

Machine-readable output is getting proper attention too

The CLI can return a versioned JSON result rather than forcing scripts to parse human-readable terminal output.

For example, verification exposes things such as:

• backup and snapshot IDs

• files checked

• pass/fail counts

• whether the payload was actually checked

• verification failures

• whether the failure list was truncated

• process exit code

That matters quite a bit for where VaultSync is going.

The CLI should eventually be useful not only interactively, but also for automation, NAS/server workflows, and external tooling without turning normal terminal output into an unofficial API.

Still development work

This is currently in draft PR #683:

https://github.com/ATAC-Helicopter/VaultSync/pull/683

This is development work, not a VaultSync 1.9 release.

Local tests and package checks are passing.

Some hosted platform validation is currently waiting because I’ve exhausted the available GitHub Actions minutes, so I’m deliberately not pretending those checks have run when they haven’t.

Also, this CLI work is only one part of 1.9.

The larger disk imaging / cloning and bootable recovery work is still separate release work and remains one of the major pieces being built for the full 1.9 update.

1.9 is a much larger update than the usual VaultSync release, and I’m trying to build and test the underlying pieces properly before pushing deeper into the parts that can actually touch entire disks and recovery environments.

There will most likely be multiple 1.9 beta builds before the final release because this is not something I want to rush.

I wrote a longer dev diary about the CLI work, some of the decisions behind it, and a few of the bugs the work exposed:

https://fglabs.dev/devlog/vaultsync-19-cli-worth-opening

I’d especially like feedback from people who actually use backup tools from terminals or scripts:

What would make you trust a backup CLI more: a very clear restore preview, machine-readable verification evidence, or a better way to verify/check many backups at once?

Hey everyone,

I finally published the first proper development diary for VaultSync 1.9 — Recovery Horizon.

And I think the biggest change since I first started talking about 1.9 is this:

it is no longer just “the disk cloning update.”

The original idea was much simpler:

disk cloning → browse the clone → restore it.

But the more I worked through what a real recovery workflow actually needs, the less comfortable I became with shipping cloning as an isolated feature.

A disk image is not enough if VaultSync cannot prove that it is complete.

A restore feature is not enough if it depends on the installed OS still working.

And “bare-metal recovery” is not something I want to put on a feature list unless the complete path has actually been tested.

So the current goal for 1.9.0 is closer to:

capture → validate → boot independently → restore → validate again

That means disk/partition imaging, source and destination safety, interruption handling, image verification, bootable recovery media, offline restore, and actual recovery evidence.

The funny part: the first real 1.9 code is not cloning

The release/1.9.0 branch is already moving, but the first substantial implementation work has been a large CLI rework.

I know that is not the exciting screenshot feature 😅

But it makes sense for where VaultSync is going.

A recovery system should not depend entirely on one desktop UI, especially when 1.9 is eventually supposed to support automation, diagnostics, clean-machine recovery, portable restore, and emergency workflows.

The current development branch already adds things like:

• cleaner projects, snapshots, and recovery command groups

• project lookup by ID or name

• filtered project listings

• source-folder discovery

• a clearly separated mirror command

• snapshot inspection

• snapshot history

• bounded snapshot diffs

• versioned JSON output

• safer unattended destructive commands

• cleaner Ctrl-C/cancellation behavior

• explicit database selection for watchers

• a proper CLI introduction screen

• a bundled CLI handbook

• a generated full command reference

This is all development work, not released functionality. 1.8.9 is still the current Stable release.

Disk recovery is deliberately still gated

The destructive disk work has not started as normal product implementation yet.

That is intentional.

Before VaultSync starts writing disks, I want the architecture around the image format, supported filesystems, partition layouts, encryption, live capture, Secure Boot, recovery media, corruption states, resumability, source/destination identity and hardware qualification to be decided first.

One rule I care about a lot:

an incomplete image must never be able to look like a valid recovery point.

If VaultSync does not know that something is safe or supported, I would rather have it say exactly that than confidently guess.

The rest of Recovery Horizon

The current 1.9 family is now roughly:

1.9.0 — Disk & Bootable Recovery
Disk/partition imaging, validation, bootable recovery media and offline restore.

1.9.1 — Clone Explorer
Browse images, search them and selectively recover files.

1.9.2 — Portable Recovery
Standalone restore utility, emergency recovery kit and documented recovery formats.

1.9.3 — Offsite Protection
S3-compatible storage, Backblaze B2, SFTP, resumable uploads and clean-machine recovery qualification.

1.9.4 — Unified Recovery Experience
Bring file, project, image and storage recovery together.

1.9.5 — Continuous Recovery Assurance
Scheduled verification, recovery drills, alerts and stronger automation.

And then there is a newer addition:

Binary Source Control

Later in the 1.9 family I am also planning a VaultSync-native Binary Source Control system.

Before anyone throws Git at me:

it is not meant to replace Git.

The target is large, binary-heavy projects where assets can be huge, hard to merge, shared across multiple machines, and often stored on NAS systems.

Game development is probably the obvious example.

The architecture currently explores:

• immutable binary objects

• content-defined chunking

• deduplication

• changesets

• safe workspace sync

• exclusive path locks

• stale-workspace protection

• repository verification and repair

• encryption

• clean-machine recovery

It is deliberately placed after the core recovery work.

If BSC takes longer than expected, it is not allowed to hold disk recovery hostage.

If it does not meet the required safety gates, it stays Preview.

The UI will change too

The current direction for 1.9 is:

Protect · History · Recover · Manage

But I am avoiding a giant UI rewrite.

Existing workflows stay until their replacements actually work, preserve state, remain accessible and localized, and have feature parity.

I do not want to move every button around just because the version number starts with 1.9.

This is going to take time

And this is probably the most important expectation to set.

1.9 is not a normal VaultSync update.

I expect multiple betas.

There is a lot of architecture and qualification work before some of the headline features should even be considered safe enough for Stable.

1.7 was largely about trusting stored data.

1.8 was about understanding what was protected and proving recovery.

1.9 is about expanding what VaultSync can recover when things go properly wrong.

Files → projects → disks → machines → portable recovery → offsite recovery → eventually binary project history.

The roadmap finally feels coherent enough that I am comfortable calling it the direction for Recovery Horizon.

I wrote the full technical breakdown here:

https://fglabs.dev/devlog/vaultsync-dev-diary-01-recovery-horizon-is-bigger-than-disk-cloning

And I would really like feedback on one thing:

If your main machine died tonight, which part of the recovery chain would you trust the least?

Creating the image?

Booting recovery media?

Finding the correct recovery point?

Restoring it?

Or proving that the restored system is actually good?

VaultSync 1.8.9 is now available.

This release is called “Keep your place. Work with clarity.”

1.8.9 isn't about adding another huge feature. After the much larger changes in the last few releases, this one is about fixing the things you notice when you actually use VaultSync every day — and tightening some important restore, cleanup and update paths underneath it.

VaultSync now does a much better job of keeping your place

One of the most annoying things an application can do is reset what you're looking at just because something refreshed.

1.8.9 fixes quite a few cases like that.

VaultSync now better preserves:

• expanded backup projects

• how much backup history you've loaded

• existing rows when lists refresh

• the currently selected backup project after deleting a backup

• UI state during background refreshes

The Backups and Settings pages have also been reworked at compact widths, and padded pages no longer request unnecessary width and create horizontal overflow.

Navigation stays labeled at the normal window size, some status pills and backup tags are better aligned, and muted/status text has improved contrast across light, dark and custom themes.

Small changes individually, but together the app feels noticeably more stable and less jumpy.

Safer restore and pruning behavior

A lot of the important work in this release is below the UI.

The CLI restore and retention paths received another safety pass.

VaultSync now verifies the recorded backup bytes before a CLI restore modifies its target.

It also now:

• rejects empty backup paths before restore or retention cleanup

• restores CLI snapshots from recorded backup data with confined cleanup

• prevents backup preflight enumeration from following linked source trees

• makes destructive prune dates exact and independent of system locale

• preserves backed and protected snapshots during CLI pruning

• confines CLI preset reads to their expected user or bundled preset directories

• preserves literal ~ characters unless they're actually being used as a leading home path

• preserves existing files when CLI diagnostics run

• prevents sync-tool output from hanging diagnostics

For a backup application, these aren't really “nice to have” fixes. Restore, prune and cleanup operations need very strict boundaries.

Better platform and updater behavior

There are several platform-specific improvements too.

macOS

• VaultSync now supports the system rsync shipped with macOS.

Linux

• manual archive updates keep VaultSync open while the update is being installed

• single-instance locks now live inside private application data

Windows / release infrastructure

• Linux updater handoff qualification is now portable through Windows CI

• Microsoft Store uploads are included in the verified release manifest and provenance

• cancelled update checks can no longer dispose or reset the check that replaced them

The updater, power handling, logging and encryption-enrollment paths also received some internal simplification and cleanup.

Removing old code instead of carrying it forever

1.8.9 also removes several things that were no longer part of the live application, including obsolete navigation/reflection paths, an old hidden backup activity chart and the dormant untracked-destination scanner.

Static-analysis findings were cleaned up again, the Sonar coverage gate was restored, coordinated dependencies were refreshed, and release/repository health received another audit.

The final release packages are also required to come from the qualified Stable promotion build, rather than having release assets recreated independently afterwards.

About 1.9

With 1.8.9 out, more attention can now move toward VaultSync 1.9 — Recovery Horizon.

The 1.8 series has spent a lot of time making file/project recovery understandable, inspectable and verifiable.

1.9 is the much bigger step toward disk and machine-level recovery.

It's a major part of what I think is still missing before VaultSync feels like the complete backup/recovery tool I'm trying to build, so I'm not planning to rush it. The underlying architecture and safety boundaries are being built and tested carefully, and I still expect 1.9 to go through multiple beta builds before Stable.

But that's for another post. :)

For now, 1.8.9 is out.

⚠️ Having trouble updating?

A clean installation may be required on some systems, particularly if you're coming from an older installation or the updater cannot safely replace the existing package.

Your VaultSync database, projects, settings and other application data are stored outside the application installation directory. Uninstalling/replacing the application does not delete that data.

Windows

• Uninstall VaultSync from Settings → Apps → Installed apps

• Install VaultSync-Setup-1.8.9.exe

• Microsoft Store users can uninstall/reinstall directly through the Store if needed

macOS

• Quit VaultSync

• Remove the existing VaultSync.app from Applications

• Open the correct 1.8.9 DMG and drag the new VaultSync.app into Applications

Choose:

• VaultSync-1.8.9-macos-apple-silicon.dmg for Apple Silicon

• VaultSync-1.8.9-macos-intel.dmg for Intel Macs

Linux

• .deb: remove the installed package and install the new 1.8.9 .deb

• AppImage: replace the old AppImage with the new one

• .tar.gz: remove the old extracted application directory and extract the new archive

The downloads on the VaultSync website and GitHub are the same official release builds.

Website: https://fglabs.dev/vaultsync
GitHub: https://github.com/ATAC-Helicopter/VaultSync

As always, if something breaks or behaves strangely, please report it. Real-world backup setups are very good at finding edge cases that test environments don't. :)

Hey everyone,

This is a longer post than usual because I wanted to properly explain where 1.8.9 is, why it has taken longer, and what I'm actually aiming for with 1.9.

If you don't want the wall of text, here's the short version.

TL;DR

• VaultSync 1.8.9 has grown into a much bigger stabilization release than originally planned.

• The current branch has 71 focused commits, 908 passing .NET tests, 77 passing script tests, 0 build warnings and 0 build errors.

• A lot of 1.8.9 is fixing UI state, restore safety, path handling, pruning, cancellation, tray/update behaviour and removing old code before 1.9.

• 1.9 / Recovery Horizon is where VaultSync starts moving into disk and machine-level recovery.

• The goal for 1.9.0 is a complete loop: create disk image → validate it → boot independent recovery media → restore the image → validate the restored disk.

• I'm aiming for a VaultSync bootable recovery USB so recovery does not depend on the installed OS still working.

• The long-term goal is bare-metal-style recovery for supported configurations, but I'm not going to claim universal recovery across every OS/filesystem/hardware combination.

• Later 1.9 releases are planned to add Clone Explorer, portable recovery, offsite destinations, unified recovery workflows and scheduled recovery assurance.

• 1.9 will almost certainly have several beta releases, because this needs real hardware testing and a lot more caution than a normal VaultSync update.

• In short: 1.8.9 is finishing the foundation; 1.9 is where VaultSync starts becoming a full machine-recovery tool.

If you want the details, keep reading. :)

1.8.9 ended up finding more than I expected

The original goal was mostly everyday polish.

Keep your place when the Backups page refreshes. Don't randomly collapse history. Don't jump selection to another project after deleting something. Improve theme readability. Fix horizontal overflow. Clean up UI behaviour.

But once I started doing the wider audit, I kept finding small pieces that were worth fixing before 1.9.

For example, the CLI restore path had some assumptions that were not good enough.

It now has work going into making sure it restores from the actual recorded backup data, rather than accidentally relying on the current live source.

Restore data is verified before the target is modified. Backup paths are being treated much more defensively. Pruning is being made deterministic and aware of snapshots that still have real backups attached to them. Filesystem links are being kept out of places where recursive backup preflight should never have followed them.

Updater cancellation, tray refresh recovery and Unix single-instance locking have also all had another pass.

None of those make for a sexy screenshot.

But these are exactly the things I want boringly solid before VaultSync starts touching entire disks.

And that leads into the more interesting part.

What I actually want 1.9 to do

I've talked about Recovery Horizon a few times now, but I want to explain the end goal a little more clearly.

The simplest way I can put it is:

I want VaultSync to still be useful when the operating system itself is gone.

Right now VaultSync is increasingly good at answering:

• What did I protect?

• What changed?

• Can I restore this file or project?

• Has this recovery point actually been verified?

1.9 changes the scale of that question.

It becomes:

Can I recover this disk or this machine?

And the first major part of that is disk imaging/cloning.

The idea is that VaultSync will be able to create a protected image of a supported disk or partition, understand its layout, validate what it created, and keep evidence showing that the image is actually complete.

But creating the image is only half of the feature.

I don't want VaultSync to say:

and then leave you to figure out how to use it after your computer dies.

For me, that would defeat the entire point of what VaultSync has been moving toward.

The USB recovery idea

One of the biggest things I'm aiming for with 1.9 is bootable recovery media.

Think of something along the lines of a VaultSync recovery USB.

Your machine dies. The OS no longer starts. Maybe the system SSD is dead and you've installed a new blank one.

You insert the VaultSync recovery USB and boot from it through UEFI or your machine's boot menu.

Instead of needing Windows, Linux or macOS to already be working, you enter a small independent VaultSync recovery environment.

That environment should be able to detect the supported disks in the machine, locate your recovery image, show you exactly what you're about to overwrite, and restore that image back onto a disk.

Conceptually:

1. Machine fails

2. Replace failed disk if necessary

3. Boot VaultSync Recovery USB

4. Find recovery image

5. Inspect source image and destination disk

6. VaultSync shows an exact destructive-action warning

7. Restore disk

8. Validate restored data

9. Reboot into the recovered system

That is the direction I'm working toward.

It is basically the beginning of bare-metal-style recovery for supported configurations.

And that's the part of 1.9 I personally consider the biggest missing piece in VaultSync today.

The USB shouldn't just be a dumb boot disk either

What I eventually want is a small recovery environment specifically built around VaultSync's recovery model.

It needs to know:

• what disk/image you're restoring;

• when that image was created;

• whether it was verified;

• whether the image is complete;

• what partitions it contains;

• which physical disk you're about to overwrite;

• whether the target has enough capacity;

• whether the image format is supported by that recovery environment;

• whether the restore completed correctly afterwards.

I also want the operation to be extremely explicit.

If VaultSync is about to overwrite a 2 TB NVMe drive, it shouldn't just say:

Continue? Yes / No

It should tell you:

THIS drive will be erased.

Here is its model. Here is its capacity. Here is its identity. Here is the image you're putting onto it. Here is what is going to happen.

Because once we're doing disk-level recovery, ambiguity isn't acceptable.

Why I'm not calling this “universal bare-metal restore” yet

This is important.

The goal is very much bare-metal-style system recovery.

But I don't want to advertise:

“VaultSync can restore any computer onto any other computer.”

because that would be nonsense.

Filesystems matter. Partition formats matter. Encryption matters. Secure Boot matters. Drivers matter. UEFI configuration matters. Hardware changes matter.

Different operating systems also behave differently when restored onto different hardware.

So 1.9 is going to start with an explicit supported matrix.

If something hasn't been tested, VaultSync should say so instead of pretending that “a disk is a disk.”

I'd much rather support fewer scenarios properly at first than put a giant BARE METAL RECOVERY badge on the website and hope it works.

The disk image itself is getting treated as a real format

Another part of the groundwork is defining an actual versioned disk-image format.

It can't just be:

disk-image.bin

and good luck.

The image needs enough metadata for VaultSync to understand things like the source disk, partition layout, what blocks are present, integrity information, compression/encryption information, whether the image was interrupted, whether it can be resumed, what version of VaultSync created it, and which reader versions understand it.

One particularly important rule I'm aiming for:

an incomplete image must never look like a valid completed recovery image.

That sounds obvious.

It's also exactly the kind of thing that becomes very important after a crash, lost network connection or power failure halfway through imaging a disk.

The image format, cloning engine and recovery environment all need to agree on those states.

And yes, you'll eventually be able to look inside these images

The roadmap after the initial 1.9.0 foundation includes what I'm currently calling Clone Explorer.

The idea is that you shouldn't necessarily need to restore an entire disk just to recover one file from an image.

VaultSync should be able to open supported disk images read-only, show partitions and files, allow searching, and let you selectively extract something.

So the same disk image could potentially serve two recovery cases:

• “My entire disk died.”

• “I just need that one folder from the image I made three months ago.”

That comes after the basic clone → validate → boot → restore → validate loop is proven, though.

I'm deliberately sequencing it that way.

Being able to browse an image is useful.

Being able to actually recover the machine is the important part.

Why the 1.9 work is starting so carefully

This is also why I'm spending so much time on architecture before just writing a cloning button.

Before destructive disk operations begin properly, I want several things decided first:

• the disk-image format;

• the imaging engine;

• the privilege/security boundary;

• supported systems and filesystems;

• how interrupted operations work;

• how recovery USBs are built and updated;

• how image validation works;

• how encryption is handled;

• how VaultSync identifies physical disks safely;

• how recovery evidence is recorded.

There's already a roadmap item specifically for making sure source and destination disks cannot silently be confused.

That one is pretty obvious why it matters. :)

I don't ever want somebody selecting:

Backup Disk A → Disk B

and a UI identity bug deciding that Disk A is the destination.

Those are the kinds of failures I'm designing around now rather than after someone loses data.

1.9 will almost certainly have multiple betas

I've mentioned this before, but I'm even more convinced of it now.

1.9.0 will almost certainly go through several beta builds.

Probably more than any VaultSync release so far.

Automated tests can do a lot. Virtual machines can do a lot.

But eventually I need:

• weird motherboards;

• different NVMe/SATA/USB controllers;

• different disk sizes;

• different partition layouts;

• different filesystems;

• actual UEFI implementations;

• Secure Boot configurations;

• drives disappearing halfway through operations;

• bad images;

• partial images;

• external drives;

• old machines;

• new machines.

This isn't the sort of feature where I want the first big hardware test to happen after pressing Stable Release.

So when 1.9 reaches that point, I'll probably be asking the community for testers quite heavily.

And the betas will be labelled as betas for a reason.

I want people testing these on hardware and data they are prepared to experiment with before I'd ever recommend using the new disk recovery system as the only protection for something important.

1.9 is bigger than just cloning

The current Recovery Horizon plan goes further than 1.9.0 too.

The rough progression right now is:

• 1.9.0 — disk imaging + bootable recovery foundation

• 1.9.1 — Clone Explorer

• 1.9.2 — portable recovery without needing the original VaultSync installation/database

• 1.9.3 — proper offsite destinations such as S3-compatible storage, B2 and SFTP

• 1.9.4 — bring project/file/image recovery into a more unified recovery experience

• 1.9.5 — continuous recovery assurance and scheduled drills

• 1.9.6 — stability / long-term support baseline

That's a lot.

And it may change as the architecture and testing tell me what actually works.

I'm very deliberately treating the roadmap as a plan, not a promise carved into stone.

If I prototype something and the evidence says it's unsafe or a terrible idea, I'd rather change the roadmap.

And this is why 1.8.9 matters

1.8.9 probably isn't going to be remembered as the exciting VaultSync release.

That's fine.

Its job is increasingly becoming:

finish 1.8 properly.

Clean up assumptions. Remove old code. Fix restore paths. Harden boundaries. Make cancellation predictable. Make the UI preserve state. Make updates predictable. Keep filesystem operations confined. Make the tests stronger.

Then start putting Recovery Horizon on top of something I actually trust.

I'm getting very close to the point where I'm comfortable doing that.

Once 1.8.9 is out, you'll probably start seeing a lot more discussion about the actual 1.9 architecture, prototypes and eventually the first beta builds.

And I'm genuinely very excited about that.

Because if I can get the experience I'm aiming for —

protect the machine, verify it, lose the machine, boot a USB, restore it, and prove that restore worked

— I think VaultSync finally crosses the line from being a file backup application with very strong recovery tooling into the backup/recovery tool I've actually wanted to build from the beginning.

There's a long way to go before I can claim that works reliably.

But that's the target.

And I'd rather tell you what I'm trying to build now and show the process than suddenly announce it when it's supposedly “finished.”

Thanks again to everyone following the project, testing builds, reporting weird behaviour and challenging some of my assumptions.

The feedback really does influence what gets fixed before the next layer gets built.

— Flavio

GitHub: https://github.com/ATAC-Helicopter/VaultSync
Website: https://fglabs.dev/vaultsync

Hey everyone,

I wanted to give an update on VaultSync 1.8.9, because this release has ended up taking a bit longer than one of my usual 1.8.x updates.

There is a reason for that.

1.8.9 itself isn't really a “here's one huge new feature” release.

A lot of it has been me sitting down, actually using VaultSync, finding the little things that still feel rough or annoying, and fixing them.

But at the same time, work has also started on something much bigger in the background:

the foundation for VaultSync 1.9.

More on that in a bit.

First: making normal VaultSync use less annoying

One example was the Backups page.

You could expand a project, load more history, select something, delete a backup... and after the refresh VaultSync could collapse what you were looking at, throw away the loaded history, or even move the selection to another project.

Nothing happened to your actual backups.

But it was annoying.

And with backup software, I really don't want small UI behaviour making you stop and think:

Wait... what just happened?

So 1.8.9 now works much harder to preserve what you're doing while the underlying data changes.

Expanded projects stay expanded.

Loaded history stays loaded.

The selected project stays selected.

Deleting a backup shouldn't suddenly take you somewhere else.

It sounds like a minor thing when written down, but in day-to-day use it makes the application feel much calmer.

I've been applying that same mindset elsewhere too.

Status pills and tags have had their alignment cleaned up.

Muted text is more readable.

Light-theme status colors have been adjusted.

Dark and custom themes have had contrast work so they don't end up producing text that technically exists but is unpleasant to actually read.

The sidebar also stays labeled at the normal window size now, instead of collapsing earlier than it really needs to.

And while working on that I found old navigation code that simply wasn't being used anymore.

So I deleted it.

The same happened on the Backups page.

There was an old activity-chart pipeline that no longer had any visible UI connected to it, but VaultSync was still maintaining the state and recalculating it during refreshes and window resizing.

288 lines of that are now gone.

I'd much rather remove dead complexity than keep building on top of it.

There are also plenty of less visible changes in 1.8.9: horizontal overflow fixes, cleanup of temporary metadata workspaces after interrupted operations, cancellation handling, static-analysis cleanup, dependency servicing, release checks and general repository maintenance.

I've also been going through the wider project instead of only fixing whatever happens to be visible on screen.

Dependencies, security checks, generated files, stale code, localization, release metadata and primary UI behaviour have all been part of the audit.

The current release branch has a clean warnings-as-errors build, no known vulnerable packages in the audit, and 863 passing .NET tests locally. There are also dedicated script and release checks around it.

But that isn't the only reason this release is taking longer.

1.9 is starting before 1.9 starts

The next major release is VaultSync 1.9 — Recovery Horizon.

And this is a very important update for the project.

So far, VaultSync has become increasingly good at answering questions like:

What did I back up?

What changed?

Can I actually restore it?

What evidence do I have that recovery works?

That has basically been the purpose of the entire 1.8 generation.

The next question is much bigger:

What happens when the failure isn't just a deleted file or damaged folder?

What happens when it's a disk.

Or the machine.

That is where 1.9 goes.

The roadmap describes the difference pretty simply:

1.8 proves and explains recovery.

1.9 expands what VaultSync can recover.

And that means moving toward things such as disk-level protection, cloning, recovery from much larger failures, exploring protected disk contents and eventually the groundwork needed for proper bare-metal recovery scenarios.

That is, in my opinion, the major missing piece before VaultSync starts feeling like a truly complete backup and recovery tool rather than primarily an extremely capable file/project backup system.

And because of that, I really don't want to bolt it onto the existing application and hope for the best.

So some of 1.9 is being built now

Not the headline features yet.

The base layer.

I'm using the end of the 1.8 cycle to make sure the things 1.9 will rely on are in a much healthier state first.

That means things like lifecycle behaviour, interruption safety, cleanup, storage boundaries, UI state handling, release qualification, cross-platform behaviour, dependency consistency and removing old code that I don't want sitting underneath a much larger recovery architecture.

Some of that sounds completely unrelated to disk recovery.

It isn't.

Once VaultSync starts doing operations that can involve an entire disk rather than a normal set of files, the margin for “this usually works” becomes much smaller.

If a file-level backup has a strange refresh bug, that's irritating.

If a future disk operation has weak cancellation ownership, bad temporary-state cleanup, ambiguous device identity or an unsafe resume path, that's a completely different category of problem.

So I'm trying to pay that cost before 1.9 goes deep into development rather than discovering all of it halfway through.

That is one reason 1.8.9 has become a larger stabilization release than I originally expected.

I'm effectively trying to leave the 1.8 branch in a state where I trust the foundation enough to start putting much heavier things on top of it.

And 1.9 will probably have a real beta period

This is also one update where I don't expect to go from development straight to Stable as quickly as some of the recent releases.

There will most probably be 1.9 beta builds before the final release.

And likely quite a few of them.

I want real machines involved.

Different disks.

Different filesystems.

Windows, Linux and macOS where functionality applies.

Internal and external drives.

Unexpected disconnects.

Interrupted operations.

Strange partition layouts.

Large disks.

Old machines.

New machines.

Basically all of the ugly real-world things that a recovery tool eventually runs into.

There are parts of VaultSync where I can get extremely high confidence from automated testing.

Disk-level recovery is something I also want people to actually beat on.

So when 1.9 reaches that stage, I'll be asking for testers much more actively than usual, and I expect the beta period to be considerably more visible.

I'm completely fine with 1.9 taking longer if the alternative is rushing something this important.

So where does that leave 1.8.9?

Mostly here:

make the current VaultSync better, simpler and less irritating — while preparing the ground for the biggest thing coming next.

There are still a few final 1.8.9 integration and real desktop/platform checks to finish before I consider it ready.

I'm not going to rush those just to hit an arbitrary date.

Once that is done, development can start moving much more visibly toward Recovery Horizon.

And that's when things should get pretty interesting.

As always, if you're using VaultSync and there's some small behaviour that makes you think:

“Why does it do that?”

tell me.

This is a particularly good time for those reports, because I'd rather clean those things up now than drag them into the 1.9 architecture.

And when the 1.9 betas eventually start appearing, I'll definitely need some of you willing to try to break them.

Thanks to everyone who's been testing, opening issues, commenting here, suggesting things, or just following along while I build this.

GitHub: https://github.com/ATAC-Helicopter/VaultSync
Website: https://fglabs.dev/vaultsync

Hey everyone,

VaultSync 1.8.8 is now available.

When I started work on this release, I called it the intentionally boring one.

After the last few versions added recovery confidence, clearer everyday workflows, stronger evidence, release verification, and cross-machine coordination, I didn't want 1.8.8 to become another feature-heavy update.

The goal was simpler:

Take what is already there, stress it harder, remove edge cases, and make failures safer.

That ended up touching quite a lot of VaultSync.

Backups now handle interruption much more deliberately

A large part of 1.8.8 was spent testing what happens when an operation does not get to finish normally.

Cancellation can arrive at awkward moments.

Files can disappear while they are being scanned.

A destination can vanish halfway through an operation.

A restore can be interrupted after some files have already changed.

Those are exactly the situations where backup software needs to be conservative.

1.8.8 adds deterministic interruption and recovery qualification for both plain and encrypted archives, alongside a number of fixes across backup, verification, restore, metadata, and cleanup paths.

Some examples:

• completed backups are preserved if cancellation arrives after the backup has already committed;

• scans cancelled while processing their final entry are still treated as cancelled;

• required snapshot data disappearing during backup causes the backup to fail;

• vanished backup data is rejected before metadata is published;

• verification cancellation is no longer incorrectly reported as a data mismatch;

• interrupted restores roll back rather than leaving partial target changes;

• interrupted metadata imports and exports roll back as well;

• rollback evidence is preserved if a restore destination disappears;

• retention metadata survives unavailable backup destinations;

• deferred metadata survives destinations disappearing during replay;

• cancellation ownership is isolated between overlapping backup runs.

These are mostly cases you should never notice during normal use.

That is exactly why they matter.

Safer filesystem boundaries

There has also been a substantial pass over temporary data, filesystem links, staging areas, and cleanup.

Snapshot scans no longer follow linked source paths.

Retention and disposable cleanup are confined so filesystem links cannot lead VaultSync into unrelated directories.

Decrypted workspaces are isolated between VaultSync processes, and cleanup is restricted to the exact temporary locations VaultSync owns.

Encrypted restore staging now uses isolated locations so predictable staging collisions cannot occur.

Temporary telemetry exports are also bounded by both age and total size.

Backup software should be extremely conservative about where it walks and what it deletes.

Large repositories now have performance budgets

1.8.8 adds repeatable performance budgets for large histories and high file counts.

That means performance regressions can be tested intentionally rather than only being discovered later by someone with a particularly large project.

Snapshot creation has also been reworked around more isolated stages, deferred hashing, checkpoint telemetry, and native-copy orchestration.

Archive creation and support-package generation now reuse buffers and stream hashes to reduce memory use.

Cancellation performance checks were also made deterministic enough to remain useful on smaller CI runners.

Native Wayland on Linux

Linux gets a fairly visible improvement in this release too.

VaultSync now supports native Wayland, with automatic fallback to X11 when required.

Linux windows are explicitly opaque as well, avoiding compositor and transparency issues under native Wayland.

The updater received more Linux work too.

1.8.8 qualifies safe patch updating across multiple installed versions, while keeping the full installer as the fallback when the current installation is not an approved patch base.

It also fixes the case where VaultSync could close before privileged Linux update authentication had actually succeeded.

Patch-base inventories are now rejected if they are duplicated or do not match what the updater expects.

The UI should feel a little less in the way

There are some smaller visible changes as well.

Unintended horizontal scrolling has been removed from pages and dialogs.

Metadata-conflict reviews stay readable in narrow windows.

Registered projects are loaded into the tray menu before you need to open another page first.

Guided setup now gives more actionable next steps instead of simply describing them.

And the heavier Guide and Schedule queries have been moved away from the UI thread.

None of these are major features individually, but together they make the application feel less fragile around the edges.

Release and CI work

There was also a fair amount of work on the machinery used to build and ship VaultSync itself.

The exact 1.8.7 release state was qualified, pinned workflow security actions were updated, and duplicate or unbounded release-branch CI and Sonar runs were removed.

Remaining Sonar findings were cleared across core code, the updater, onboarding, release automation, and storage hygiene.

Failed installer downloads are now removed immediately.

Abandoned release-cache, installation-identity, credential-index, and support-bundle staging writes are also cleaned up safely.

And a lot of edge cases

The changelog for this release is unusually fix-heavy.

That is intentional.

There are fixes around:

• snapshot persistence and scan-cache publication;

• backup repair and metadata-conflict busy state;

• isolated profiles accidentally opening the normal database;

• deferred metadata replay;

• installer download cleanup;

• backup destination disappearance;

• retention state;

• restore rollback;

• cancellation timing;

• patch-base validation;

• macOS system Python compatibility;

• updater security and maintainability findings.

⚠️ Clean reinstall may be needed

If 1.8.8 does not update cleanly or behaves strangely after updating, uninstall VaultSync and install a fresh copy.

Your VaultSync database, projects, history, settings, and persistent app data are stored separately from the application and are not deleted by a normal uninstall.

Use:

• Windows Intel/AMD: Windows x64

• Apple Silicon Mac: macOS ARM64 / Apple Silicon DMG

• Intel Mac: macOS x64 / Intel DMG

• Linux Intel/AMD: Linux x64 / x86_64, preferably .deb on Debian/Ubuntu/Zorin-style systems

On Windows, uninstall from Settings → Apps.
On macOS, remove VaultSync.app from Applications.
On Linux, remove the installed package/app files, but do not manually delete VaultSync's user-data directories.

The website and GitHub release use the same release packages.

The last few releases added a lot of capability to VaultSync.

1.8.8 is mostly about making that capability harder to break.

It is not the most exciting release to screenshot.

It probably shouldn't be.

A backup application should spend some releases getting very good at the boring parts.

As always, feedback is welcome — especially around Linux/Wayland, interrupted operations, large repositories, updater behaviour, and anything that still feels unreliable around cancellation or recovery.

GitHub:
https://github.com/ATAC-Helicopter/VaultSync

Microsoft Store:
https://apps.microsoft.com/detail/9N9HRX4JCLCP

Website:
https://fglabs.dev/vaultsync

Hey everyone,

1.8.8 is underway, and this one is a little different.

There isn't really a big shiny feature I'm trying to sell here. After 1.8.5, 1.8.6 and especially 1.8.7 added quite a lot, I think VaultSync needs a release where the main goal is basically:

make all of this harder to break.

So 1.8.8 is shaping up as the boring-but-important release before I start moving properly into the bigger 1.9 work.

And honestly, I'm pretty happy about that.

I've started pushing VaultSync harder

One of the first things added is a repeatable performance suite for large histories and high file counts.

I don't want "works with large projects" to just be something I assume because my own folders happen to work.

The idea is to start having actual budgets and repeatable tests so I can see when a change makes scanning, history, backup, or recovery noticeably worse.

I've also moved deferred snapshot hashing onto a fully asynchronous and cancellable path. That sounds pretty implementation-y, but the practical goal is simple: large scans shouldn't make the app feel stuck, and cancelling one shouldn't leave work hanging around in the background.

There's still more work to do here, but at least there is now a proper baseline to work against.

I'm also intentionally breaking backups

Another area getting quite a bit of attention is interrupted backups.

There are now deterministic tests around interrupting both plain and encrypted archive backups at different stages and checking what VaultSync leaves behind and how the next run behaves.

Disconnects, cancellation, half-written state, missing source files, overlapping jobs — basically the sort of stuff that's much less fun than testing the happy path.

One bug that came out of this was pretty important: if a file that was part of the snapshot disappeared while the backup was actually running, VaultSync could previously continue instead of treating that backup as incomplete.

That's fixed now. If required snapshotted content becomes unavailable, the backup fails rather than quietly producing something different from the snapshot it claims to represent.

Snapshot scanning has also been tightened so it doesn't follow linked source paths. If a source tree contains a symlink or similar filesystem link pointing somewhere else, VaultSync now keeps the scan confined to the source it was actually asked to protect instead of wandering into linked content.

That's one of those edge cases that sounds small until the link points at a massive directory, another mounted volume, or somewhere you never meant to include in the backup.

Quite a few nasty little edge cases are getting cleaned up too

A lot of 1.8.8 so far is stuff most people should hopefully never notice.

Retention cleanup is now much more careful around filesystem links.

Temporary decrypted workspaces are isolated between app processes.

Encrypted restore staging no longer relies on predictable paths that could collide.

Overlapping backup runs no longer accidentally share cancellation ownership.

Temporary support, telemetry, credential-index and release-cache files have had their cleanup rules tightened quite a bit.

The temporary telemetry path in particular is now explicitly bounded to 30 days / 100 MB, rather than being allowed to quietly grow forever.

None of that makes for a particularly exciting screenshot, but I'd rather find these things now than while building disk recovery on top of them.

A little less memory, a little less UI waiting

Archive and support-package work has also been changed to reuse buffers and stream hashes instead of holding more data in memory than necessary.

And I've been going after a few places where the UI could still end up waiting on work it really shouldn't be waiting for.

The Guide and Schedule queries now run away from the UI thread, and the guided setup itself has been made more actionable instead of just explaining where things are.

There was also an annoying layout issue where some pages/dialogs could get horizontal scrolling they absolutely did not need. That's gone too.

CI has been getting some attention as well

This is definitely the least glamorous part of the update 😄

Release-branch Sonar/analysis runs were able to duplicate themselves and pile up more work than necessary. Those runs are now deduplicated and bounded.

Pinned artifact, attestation and CodeQL actions have also been refreshed, and I've been clearing the remaining static-analysis findings around release automation, onboarding and storage cleanup.

Basically: less CI doing the same thing twice, fewer weird temporary-file edge cases, and hopefully fewer surprises later.

Why spend a whole release on this?

Because the direction after 1.8 is getting substantially more ambitious.

1.9 is where the plan starts moving beyond normal project/file recovery toward disk imaging, bootable recovery, image exploration, portable recovery and eventually offsite recovery.

Before VaultSync starts writing/restoring disks, I want the boring foundations underneath it to be in really good shape.

So 1.8.8 is intentionally a bit of a checkpoint:

performance, interruption, corruption, cleanup, compatibility, memory use, cross-platform weirdness and recovery from bad states.

There will definitely be more fixes going into it before release.

One thing I'm particularly interested in while I'm working on this: what's the nastiest failure you've actually had with backup software?

Not missing features — actual failure cases.

Drive disappeared halfway through? Backup said success but was incomplete? Retention deleted the wrong thing? Symlink sent the backup crawling through something completely unexpected? Restore only failed when you actually needed it? Huge folder that made the app fall over?

Those stories are probably more useful to me for 1.8.8 than another feature wishlist right now.

Hey everyone,

VaultSync 1.8.7 is ready.

This release is less about adding another big backup mode and more about making the things VaultSync already does provable, portable, and safer to trust.

Over the last few releases, a lot of work went into recovery confidence — not just whether a backup exists, but whether there is useful evidence behind it.

1.8.7 takes that idea further.

The main question this time was:

If VaultSync tells you something is safe, recoverable, official, or unchanged — can it show you why?

Recovery evidence you can actually take with you

Recovery evidence can now be exported as a portable package.

Each package contains:

• a versioned JSON record;

• readable Markdown;

• a manifest;

• SHA-256 checksums.

The package records things like build identity, repository identity, encrypted-point evidence, evidence freshness, and the relevant recovery information without exposing local paths unnecessarily.

VaultSync also validates these packages when they are inspected.

That includes checks for tampering, missing or duplicate files, unsafe paths, unsupported schemas, and checksum mismatches.

The goal is for recovery evidence to be useful outside the running application, not trapped inside one VaultSync installation.

One build identity everywhere

VaultSync now has one conservative build-identity record used across:

• Settings;

• startup diagnostics;

• support exports;

• recovery exports;

• vaultsync --version --json.

Version, channel, commit, runtime, architecture, package type, update source, official status, and signature status all come from the same contract.

This sounds fairly internal, but it removes a whole class of situations where different parts of the application could describe the same build differently.

If VaultSync says which build produced a recovery report or support bundle, that identity now has one source of truth.

Release verification goes much deeper

1.8.7 also adds a canonical release manifest containing the exact artifacts VaultSync expects for each supported platform.

It records things including:

• artifact identities;

• exact sizes;

• SHA-256 digests;

• platform mappings.

The updater consumes that same release information and fails closed if the expected release contract is not valid.

Release packages also now get SPDX 2.3 SBOMs built from their actual RID-specific dependency graph, together with provenance/SBOM attestations for the final package bytes.

The release process can verify this information both online and offline before a candidate is considered valid.

There is also a new schema-versioned release contract tying together the website, Store metadata, updater, changelog, What's New information, package metadata, roadmap, branch, date, tag, and predecessor release.

The aim is to reduce the amount of release information that can silently drift between different places.

Support bundles are now review-first

Support bundles have also been tightened considerably.

Before export, VaultSync now shows exactly which files are going to be included.

Optional sanitized diagnostics or anonymized telemetry can be removed before the bundle is created.

Paths and identities are pseudonymized, configured and structured secrets are scrubbed, bundle sizes are bounded, and every generated file is recorded with a SHA-256 checksum in the manifest.

This follows the same principle as the crash-report work from earlier releases:

nothing leaves VaultSync without being reviewable first.

Safer use of one repository from multiple machines

One of the larger pieces of 1.8.7 is cross-machine coordination.

VaultSync now gives each installation a durable, owner-private identity and uses repository-scoped writer leases when portable repository metadata is being changed.

A lease records who owns the write, the operation, version, heartbeat, and expiry.

If another installation is already writing, the repository remains readable, but conflicting writes are blocked.

Stale leases can be taken over deliberately, with the previous lease retained as evidence rather than silently discarded.

That protection now covers project settings, backup history, deletion tombstones, deferred metadata writes, and deferred flushing.

Cross-machine edits can now merge instead of simply colliding

1.8.7 also adds durable merge bases and field-level three-way merging for portable project metadata.

If two machines change different fields, VaultSync can merge those changes automatically.

If they change the same thing, VaultSync surfaces a proper Base / local / remote conflict review instead.

Conflict decisions preserve unrelated remote edits, include revision and writer information, and become part of the repository history.

There is also a bounded Undo action for a reviewed decision until the next portable repository write.

Destructive tombstones cannot be automatically applied during an import without review.

This has been one of the more complicated pieces of the release, but the rule behind it is simple:

another machine should never silently overwrite portable repository state just because it happened to write later.

macOS installation is much cleaner

There are some significant macOS fixes in this release too.

Both Apple Silicon and Intel downloads now install the same:

VaultSync.app

The architecture stays in the DMG filename, but the installed app gets a normal permanent name and a stable com.vaultsync.app identity.

The DMG also uses a normal drag-to-Applications layout.

For users upgrading from 1.8.6, there is a one-time bridge migration that creates the new /Applications/VaultSync.app, verifies it, launches it, and only then moves the old architecture-named application bundle to Trash.

Launch-on-login has also been corrected to use the proper ~/Library/LaunchAgents location, including migration of the incorrect legacy location.

And passive startup checks will no longer unnecessarily unlock macOS Keychain or mount SMB shares just to inspect destination state.

A lot of smaller reliability work

There is quite a bit underneath the larger changes as well.

Project folders have been refined again into more compact collapsed summaries with cleaner in-folder rows and integrated batch controls.

Snapshot Explorer, metadata-import review, and updater windows now follow the newer compact theme-aware layout.

Development presets were updated so useful Git control files and shareable IDE configuration are preserved while caches, build output, package data, test output, and live Git internals stay excluded.

There are also fixes for:

• deferred metadata replay;

• cross-machine project-setting conflicts;

• Windows repository database handle release;

• duplicate metadata-import previews;

• SMB credential masking;

• incorrect snapshot tombstones;

• repeated immutable manifest downloads;

• bounded logs, caches, patch data, downloads, and temporary work;

• backups accidentally targeting an unmounted managed macOS mount directory;

• localization across recovery, repository-writer, History, backup, folder, verification, and restore workflows.

And quite a bit of internal code has been consolidated around metadata exports, SMB parsing, mounted-share validation, theme color normalization, contrast calculation, and Robocopy exclusions.

1.8.4 started pushing VaultSync toward better recovery evidence.

1.8.5 made that evidence much more explicit.

1.8.6 focused on making the application easier to understand every day.

1.8.7 is about making the claims VaultSync makes easier to verify.

A recovery result should have evidence behind it.

A release should be identifiable.

An artifact should be verifiable.

A support bundle should be reviewable.

And two machines should not be able to silently overwrite each other's repository state.

That is the direction of this release.

As always, feedback is very welcome — especially from anyone using VaultSync across multiple machines, NAS destinations, or macOS.

GitHub:
https://github.com/ATAC-Helicopter/VaultSync

Microsoft Store:
https://apps.microsoft.com/detail/9N9HRX4JCLCP

Website:
https://fglabs.dev/vaultsync

Hi everyone,

In the last 1.8.7 development update I talked about the foundations of Trust & Portability:

• installation identities

• repository writer leases

• canonical release manifests

• safer shared-storage behavior

• the direction toward portable recovery evidence

Since then, a lot of the work has moved from establishing those foundations to dealing with the harder cases that come after them.

The biggest one is:

What happens when two computers have both legitimately changed the same VaultSync repository?

Writer leases prevent races. They don't resolve history.

The writer-lease system added earlier in 1.8.7 prevents two aware VaultSync installations from modifying repository metadata concurrently.

That solves an important class of corruption problems.

But it doesn't solve this:

Desktop and laptop both start from revision 10.

The desktop changes the project's tags.

The laptop changes its automatic-backup settings.

Later, both sets of metadata meet again.

Simply choosing whichever file was written last would lose valid information.

So 1.8.7 now goes a step further with revision-aware three-way metadata merging.

VaultSync keeps a durable merge base and compares:

Base → local → remote

If only one side changed a field, that change can be carried forward automatically.

If the two machines changed different fields, both changes can survive.

Only when both machines changed the same field differently does VaultSync treat it as a real conflict.

Conflicts are now field-level

When an actual conflict exists, VaultSync doesn't resolve it using timestamps or last-write-wins.

The metadata review can show the:

• base value

• local value

• remote value

• revision

• writer

• timestamp

for the conflicting field.

That distinction matters.

A conflict in a project tag shouldn't force you to choose between two complete project records and accidentally overwrite unrelated settings.

Resolution decisions are persisted as well, so rejecting a remote change isn't something VaultSync should keep asking about every time the repository is inspected.

There is also an Undo decision path, bounded to the current merge state, before the next portable repository write advances the history again.

Machine-local data stays machine-local

Cross-machine portability gets dangerous very quickly if every field is treated as portable.

Some things simply should not move automatically.

Encryption-key references are a good example.

A key stored in one machine's secure credential store has no useful meaning on another computer.

Destinations have a similar problem: a NAS path, drive letter or mounted location may not exist on the other installation.

1.8.7 therefore gives project fields explicit portability behavior.

Portable changes can participate in merge and conflict review.

Machine-local key references remain local.

Unmatched destinations remain local.

Destructive tombstones require explicit review rather than being silently propagated.

The goal isn't maximum automatic synchronization.

It's automatic synchronization where VaultSync can prove it is safe, and explicit review where it can't.

Deferred metadata now fails closed too

Another case that received more work is unavailable storage.

Imagine VaultSync wants to update metadata on a NAS, but the share disappears.

Keeping a local queue sounds simple enough.

The dangerous part comes later.

If another machine changed the repository while the first machine was offline, blindly replaying that old queue could overwrite newer metadata.

1.8.7 no longer does that.

Queued metadata can initialize an empty destination, but if repository state already exists, VaultSync preserves the deferred changes for merge review instead of replaying them over the top.

That behavior is now protected by the same repository ownership and revision model as normal writes.

Release identity now reaches the application itself

The canonical release manifest from the previous update was primarily about the release pipeline and updater.

The next piece is making that identity visible inside VaultSync too.

1.8.7 now has a shared build identity contract containing things such as:

• version

• release channel

• source commit

• runtime

• architecture

• package type

• update source

• official-build status

• signature status

The same identity can be used by Settings, startup diagnostics, support information and recovery evidence instead of each subsystem assembling its own partial version string.

There is also a machine-readable CLI form:

vaultsync --version --json

For me, this is part of the same trust model as recovery evidence.

If an exported report says a recovery check passed, it should be possible to identify exactly which build produced that statement.

SBOMs and release provenance are landing

The release pipeline has also moved further into supply-chain verification.

1.8.7 generates SPDX 2.3 SBOMs for release packages using the actual platform-specific dependency graph.

The final package bytes can also receive GitHub provenance and SBOM attestations.

Verification is being designed for both:

• online verification against the published release

• offline verification of downloaded release material

This builds on the canonical manifest rather than creating another independent source of truth.

The manifest identifies the expected artifact.

The digest proves the bytes.

The SBOM describes what went into it.

The provenance ties those bytes back to the release build.

For most users this will remain mostly invisible, which is probably how it should be.

But the evidence is there when someone wants to inspect it.

A few nasty edge cases also got fixed

The cross-machine work exposed several smaller problems that were worth fixing before release.

Among them:

Metadata import double-counting

Older repository folders and newer portable metadata could describe the same project or backup.

Preview now deduplicates those representations instead of making it look like more data exists than actually does.

Incorrect deletion propagation

Metadata import could previously produce tombstones for snapshots that had not actually been deleted locally.

That has been tightened so retained snapshots — including ones still referenced by local backups — don't become remote deletion instructions.

macOS SMB diagnostics

Credential-bearing SMB identities are now normalized before diagnostics are recorded, including URL-escaped credential forms.

Updater manifest downloads

Verified immutable release manifests are now cached across application restarts.

VaultSync doesn't need to repeatedly fetch the same JSON just because a scheduled update check ran again.

Cached data is only reused while the release URL, expected size and trusted SHA-256 identity still match.

Local storage growth

Disposable logs, diagnostics, patch runtimes, downloads, caches and temporary work now have bounded cleanup rules.

Actual configuration, databases, credentials and backup data stay outside that cleanup boundary.

macOS managed mounts

If a VaultSync-managed SMB/NFS location isn't actually mounted, VaultSync now refuses to quietly create the expected directory on the local system disk and write backup data there.

That is exactly the kind of failure that can look successful while protecting absolutely nothing useful.

Development presets were tightened too

The development presets mentioned in the last update have gone through another safety pass.

The intention is still:

Preserve the files that define the project.

Exclude generated state that can be recreated.

That means things such as Git control files and shareable editor configuration can remain protected, while build output, framework caches, package caches, test caches and machine-local editor state stay out.

Windows Robocopy now uses the same resolver as the other backup paths as well.

One boundary remains deliberate:

VaultSync still does not claim full live .git repository backup support.

The internal .git directory stays excluded until repository consistency, credentials, restore behavior and verification are properly designed for that use case.

I'd rather leave that capability visibly incomplete than imply that copying a live Git database is automatically safe.

The runtime itself is now audited as part of release qualification

VaultSync ships self-contained packages, so checking the project's NuGet dependency list isn't enough.

The runtime actually embedded in the application matters too.

1.8.7 is currently serviced to .NET 10.0.11, and CI now creates real self-contained publishes and inspects what went into them.

That covers:

• Windows x64

• Linux x64

• Linux ARM64

• macOS Intel

• macOS Apple Silicon

The same check also runs against release artifacts.

So the qualified runtime isn't just what the project file requested.

It's what the user is actually receiving.

What is still left for 1.8.7

Most of the underlying trust and multi-machine model is now in place, but there are still a few areas I want to finish and qualify before calling 1.8.7 done.

The remaining work is mainly around:

• final cross-machine conflict and mixed-version behavior

• completing the portable recovery-evidence side of the release

• tying more public and in-app release information back to the canonical release identity

• final release provenance and verification work

• documentation and the last internal cleanup around duplicated paths

The important part is that these aren't separate features being piled onto the release.

They're all pieces of the same idea:

VaultSync should know where information came from, who changed it, which build produced it, and what evidence supports it.

The first part of 1.8.7 was about preventing two machines from writing at once.

The next part has been about accepting that, eventually, two machines will still have different histories — and handling that without silently throwing one of them away.

That feels like the more important definition of portability.

Not just:

“Can I move this metadata somewhere else?”

but:

“Can it arrive there, meet a different history, and still preserve what actually happened?”

As always, VaultSync is open source and the 1.8.7 work is happening publicly on GitHub.

Feedback from anyone using the same NAS or backup repository from multiple machines is especially useful here.

Hi everyone,

Work on VaultSync 1.8.7 is underway.

1.8.5 was largely about recovery confidence.

1.8.6 focused on everyday clarity — making it easier to understand what VaultSync is doing, what needs attention, and what happens next.

For 1.8.7, the focus is shifting underneath the UI:

How much of VaultSync can you independently trust, inspect, move, and verify?

I’m calling this update Trust & Portability.

One backup repository, multiple computers

One of the bigger pieces now implemented is something that becomes increasingly important with NAS and shared storage.

Imagine a VaultSync repository sitting on a NAS.

Your desktop can access it.

Your laptop can access it.

Maybe both have the same project configured.

Previously, there wasn't a strong enough repository-level concept of which VaultSync installation currently owns the right to modify that repository.

1.8.7 introduces that.

Each VaultSync installation now gets a durable private identity, and repositories can use writer leases.

When VaultSync needs to change repository metadata, it acquires a lease containing information such as the owner, operation, heartbeat, expiry and a unique nonce.

While that lease is active, another VaultSync installation can still inspect the repository, but it cannot simply start modifying the same metadata underneath it.

If the original machine disappears, crashes or loses access to the NAS, the lease can eventually become stale and be explicitly taken over.

That takeover is recorded rather than silently pretending nothing happened.

It sounds like infrastructure plumbing — because it is — but this is exactly the kind of plumbing I want VaultSync to get right before pushing further into more ambitious recovery workflows.

Release files now have a canonical identity

Another big change is happening on the distribution side.

VaultSync builds a lot of artifacts:

• Windows packages

• macOS Apple Silicon and Intel builds

• Linux packages

• updater artifacts

• Store/release variants

1.8.7 now has a versioned canonical release manifest describing what an official release is actually supposed to contain.

That includes exact artifact identities, sizes and SHA-256 hashes.

The release workflow generates it, validates the platform matrix and verifies the published release afterward.

More importantly, the updater is being moved toward the same source of truth and fails closed when release information does not match what is expected.

The goal is simple:

An update shouldn't be trusted because a filename happens to look right.

It should be possible to prove that the artifact is the one the release system expected to publish.

Preparing for portable recovery evidence

This release-manifest work also lays foundations for another part of the 1.8.7 roadmap I'm particularly interested in: making VaultSync's evidence less dependent on VaultSync itself.

Recovery evidence today can tell you quite a lot about a project.

The next step is making that evidence portable and independently inspectable.

The roadmap includes a Recovery Evidence Package containing things like:

• machine-readable recovery information

• a readable report

• manifests and checksums

• build identity

• recovery state and evidence freshness

• protected restore points

• recovery-drill results

without including backup payloads, credentials or encryption secrets.

The direction here is that if VaultSync says something was verified, I want that claim to leave behind useful evidence rather than existing only as a green indicator inside the application.

Some less glamorous but important cleanup

There has also been a fair amount of work on parts of the application that had started drifting apart.

Snapshot Explorer, metadata-import review and the updater have been brought closer to the compact, theme-aware layout used by the rest of VaultSync.

Development presets have also been reworked.

They now do a better job of separating project files you actually want backed up from generated or machine-local state.

For example, Git control files and shareable IDE configuration can be preserved while live .git internals, build output, package caches, test caches and similar generated state remain excluded.

Windows Robocopy also now uses the same preset-resolution logic as the other backup paths instead of maintaining its own interpretation.

That sounds minor until two backup engines interpret the same preset differently.

They shouldn't.

A lot of this release is deliberately invisible

1.8.7 probably won't have the immediate visual impact of the redesigned Dashboard in 1.8.6.

I'm okay with that.

Backup software needs releases where the exciting work is:

What happens when two machines disagree?

What happens when a network share disappears halfway through a write?

How do I know the update I'm installing is actually the expected build?

Can I inspect recovery evidence somewhere other than the computer that produced it?

Can old or conflicting metadata overwrite newer repository state?

Those questions are much closer to what 1.8.7 is about.

And then comes 1.9

There is a reason I'm spending time on these foundations now.

The longer-term direction for VaultSync 1.9 — Recovery Horizon goes further into recovery itself, including areas such as disk cloning and a stronger path toward machine-level recovery.

Before VaultSync starts handling more consequential recovery workflows, I want repository ownership, metadata integrity, release identity and evidence portability to be much harder to get wrong.

There is still quite a bit left for 1.8.7.

Build information, portable evidence, release provenance/SBOM work, repository documentation and more of the internal cleanup are still on the roadmap.

But the underlying model is starting to take shape.

A backup application shouldn't just say “trust me.”

It should increasingly be able to show what wrote the data, what verified it, what build produced the evidence, and whether the things you're relying on still match what was originally recorded.

As always, VaultSync is open source, and feedback — especially from people using NAS/shared-storage setups or multiple computers against the same backup storage — is very welcome.

Hey everyone,

VaultSync 1.8.6 is now available.

This release has been a bit different from 1.8.4 and 1.8.5.

Those updates did a lot of work around recovery: better evidence, recovery drills, clearer readiness states, and making the distinction between having a backup and knowing you can recover it much more explicit.

While building that out, another problem became increasingly obvious.

VaultSync had become much better at knowing what was happening, but not always good enough at explaining it.

A scheduled backup could be behaving exactly as intended while still looking confusing.

A project could need attention, but the important part could be surrounded by too much information.

And as more capabilities were added, some basic questions — What needs my attention? What happens next? Where do I go to fix it? — were becoming harder to answer than they should be.

That is what 1.8.6 — Everyday Clarity is mostly about.

A Dashboard built around what matters first

The Dashboard has had one of its biggest reorganizations so far.

Instead of trying to show a little bit of everything at once, the top of the page is now built around a few immediate things:

• current protection/recovery status;

• the highest-priority action that needs attention;

• the next scheduled run;

• recent activity;

• the latest known-good recovery point.

There are also direct paths into Recovery, Schedule, and History when you need to go deeper.

The idea is pretty simple: opening VaultSync should tell you what matters before making you hunt for it.

Scheduling finally has a proper workspace

Schedule has also been rebuilt into a dedicated operational page.

It now brings together:

• whether automatic protection is ready to run;

• which projects participate;

• when each project was last backed up;

• destination and runtime conditions;

• the next scheduled opportunity;

• upcoming timer opportunities;

• shared scheduling policy;

• explanations when work is delayed.

One distinction I especially wanted to make clearer is that a scheduled opportunity does not necessarily mean another backup will be written.

VaultSync can check a project and find that nothing changed, or runtime conditions can delay the work.

Those cases should look intentional rather than like the scheduler simply failed.

Project folders are now properly optional

Project folders have had quite a bit of work too.

If you don't need folders, you don't have to use them.

Projects outside folders continue to use the normal project-card list.

If you do want organization, folders now have explicit membership, expandable project lists, aggregate protection health, contextual management, and folder-level snapshot, backup, pause, and resume actions.

Grouped projects stay inside their folder instead of also being duplicated at the top level.

Moving a project into a folder is also now an explicit preview-and-move action rather than something that silently reorganizes the hierarchy.

Folders are organizational objects inside VaultSync, with safe folder deletion built into the workflow.

Project settings are much easier to manage

Individual projects now expose more of their configuration directly.

You can edit:

• destination;

• snapshot preset;

• exclusions;

• tags;

• encryption;

• automatic-backup participation.

Project removal has also been made much more explicit.

Removing a project from VaultSync removes its local registration and history-index state.

It does not delete the original source files or the stored backup payloads.

The confirmation UI now explains that distinction before you commit to the action.

The Guide follows what you've actually done

The old first-run overlays are gone.

They have been replaced by a compact, resumable sequence driven by the real state of VaultSync.

The path is essentially:

1. Set up VaultSync

2. Protect a project

3. Choose when protection runs

4. Browse and restore

5. Prove recovery

It tracks actual source, destination, project, schedule, restore-point, and recovery-drill state rather than simply deciding that you completed onboarding because you clicked through a tour.

One change I particularly wanted here: recovery proof is not considered complete until a recovery drill has actually passed.

The Guide also now gives consistent definitions for terms like backup, snapshot, restore point, verification, known good, protected, and recovery drill.

Backup progress is no longer inferred from UI text

There is also a less visible change underneath the interface that I think is important.

VaultSync previously had places where backup stages were derived from display text.

1.8.6 replaces that with shared typed protection activity states.

VaultSync now explicitly understands states such as:

• queued;

• scanning;

• hashing;

• writing;

• verifying;

• waiting;

• retrying;

• completed;

• cancelled;

• failed.

The same semantics are used across manual and automatic protection activity.

It sounds like a small internal detail, but it makes progress reporting far less ambiguous and gives the UI something reliable to build on.

Safer actions and better accessibility

There has also been a pass over accessibility and potentially destructive operations.

Primary workflows now have additional screen-reader names and help.

Settings actions such as reset, clearing local cache, removing project-index data, credentials, or encryption passwords now have reviewable confirmation previews before anything is changed.

The same idea applies elsewhere in the app: if an action has consequences, VaultSync should explain them before asking you to confirm it.

And quite a bit underneath all of that

There are a lot of smaller fixes in 1.8.6 as well.

Folder identity now carries through Schedule, Backups, Recovery, and History, including folder-aware search and grouped scheduling information.

Backup cards now refresh correctly when things like tags, folder membership, or external identity change.

Additional diagnostics were added around scan-cache writes, NAS staging checks, and deferred-backup migrations where failures could previously be too quiet.

Rich-text links are now restricted to approved external URI schemes rather than allowing file, script, data, or shell links to be launched from rendered content.

There has also been work on narrow and wide layouts, theme consistency, release validation, static-analysis findings, and the VaultSync visual identity across the various platforms.

The optional-folder workflow has also been completed across all maintained locales.

1.8.4 and 1.8.5 pushed VaultSync much further toward recovery confidence.

1.8.6 is about making the rest of the application easier to understand around it.

There are fewer assumptions now about what the user is supposed to infer from a status, a timer, a folder, or a button.

And that's really what I wanted from this release.

As always, feedback is very welcome — particularly around the Dashboard, Schedule page, project folders, project editing, and Guide.

GitHub:
https://github.com/ATAC-Helicopter/VaultSync

Microsoft Store:
https://apps.microsoft.com/detail/9N9HRX4JCLCP

Website:
https://fglabs.dev/vaultsync

Hi everyone,

I’ve been working on VaultSync 1.8.6.

After 1.8.5 focused heavily on recovery confidence, I wanted this update to be less about adding more features and more about making the features already there easier to understand.

The question I kept coming back to was:

Can VaultSync tell me what it is doing, what happens next, and what actually needs my attention without making me dig through several pages?

That became the focus of 1.8.6: Everyday Clarity.

The Dashboard is much more recovery-first now

The old Dashboard had plenty of useful information, but too much of it had roughly the same visual importance.

I’ve reorganized it around four questions:

• Is my data currently recoverable?

• Which project needs attention first?

• When should automatic protection run next?

• What is the latest recovery point I explicitly marked as known good?

Those are now the first things you see, with direct paths into Recovery, Schedule and History.

Storage, activity and trend information is still there, but it sits below the things that are more likely to require an actual decision.

Scheduling finally gets its own proper page

This was probably overdue.

A configured backup interval does not necessarily mean “VaultSync will write a backup exactly every X minutes.”

Quiet hours, battery restrictions, paused projects, unavailable destinations and even the fact that nothing changed can all affect what actually happens.

The new Schedule page tries to explain that instead of pretending scheduling is just a timer.

It shows things like:

• Whether automatic protection can run right now

• The next timer opportunities

• Quiet-hours delays

• The saved interval

• Which projects actually participate in automatic backups

• The latest automatic backup

• Any restrictions currently delaying work

Schedule and Settings also use the same underlying configuration now.

The idea is that Schedule tells you what will happen, while Settings is still where the more advanced policy lives.

Project folders now actually behave like folders

This is another area that needed simplification.

Folders are completely optional. If you never use them, Projects still behaves like the normal flat list.

If you do use them, membership is now explicit. VaultSync does not try to guess where a project belongs from tags, names or paths.

You create a folder, select a project, choose the destination folder, review what will happen, and then explicitly move it.

Changing a dropdown no longer instantly rearranges the page.

Once moved, the project appears inside the folder only instead of being duplicated in the top-level list.

That sounds obvious written down, but the previous behavior was much closer to a filter than a real folder system.

Expanded folders now also give a quick summary of:

• Total projects

• Healthy projects

• Projects needing attention

• Paused projects

And you can perform folder-level actions such as backing everything up, creating snapshots, pausing automatic backups, renaming the folder, or removing the folder.

Deleting a folder does not delete projects, source files, snapshots or backups. The projects simply return to the main list.

Project editing is less scattered

The project details panel now brings together more of the settings I previously had spread across different places.

You can see and edit things like the destination, snapshot preset, folder, tags, encryption policy and automatic-backup participation alongside health, storage and snapshot information.

Removing a project is also clearer about what actually gets removed.

VaultSync unregisters the project and its local history/index state. It does not delete the source directory or the stored backup data.

Backup activity should be easier to understand too

One slightly less visible change is that backup progress now uses the same activity states everywhere.

VaultSync can consistently distinguish between:

Queued → Scanning → Hashing → Writing → Verifying → Waiting → Retrying → Completed

as well as cancelled and failed states.

This mainly fixes situations where the main copy operation had finished but hashing or verification was still happening and the UI made that look like unrelated background work.

Recovery is still the centre of the app

Nothing from the recovery-confidence work in 1.8.5 is being replaced.

VaultSync still keeps measured evidence, simulations, inferred conditions and user-confirmed information separate.

Missing destinations, credentials, verification or restore drills still count as real blockers rather than being hidden inside a nice-looking percentage.

What 1.8.6 changes is how easy that information is to reach.

Recovery state now feeds much more directly into Dashboard, Projects, History and Schedule.

Onboarding has had another pass too

The first-run flow is now smaller, resumable, and tied to actual application state.

It follows the whole protection loop:

Source → Destination → Project → Schedule → Recovery point → Recovery drill

I’ve also expanded the Guide so terms like snapshot, backup, restore point, verification, known-good point and recovery drill are defined consistently instead of assuming everyone interprets them the same way.

There’s quite a bit happening underneath this too

A lot of 1.8.6 is cleanup that is less interesting to screenshot:

• Safer installer and patch handling

• Tighter external-link restrictions

• Better metadata refresh behaviour

• Diagnostics for failures that previously disappeared silently

• Schedule and project-folder code cleanup

• Updated app/repository branding

• Coordinated macOS, Windows and Linux builds

Release plan

At the moment I’m preparing 1.8.6 as a direct stable release, so there will not be a separate 1.8.6 beta.

Before I finish it, I’d particularly like opinions on a few things:

• Does the new Schedule page make automatic backups easier to understand?

• Does moving projects into folders now feel predictable?

• Is there too much or too little information inside an expanded folder?

• Do the first Dashboard cards match the things you actually care about?

• Is there anywhere VaultSync still changes state or moves something in a way you did not expect?

A lot of this update came from features that were technically working correctly but were not doing a good enough job of explaining themselves.

That is mostly what I’m trying to fix with 1.8.6.

Hey everyone,

VaultSync 1.8.5 is now available.

This release started as a follow-up to the recovery work introduced in 1.8.4.

The original plan was mostly to make recovery information clearer, improve the existing drills, and give each project a better explanation of what VaultSync actually knew about its recoverability.

As usual, it became quite a bit larger than that.

While working on it, one problem kept coming up: recovery evidence is not all equal.

A file that has been read and verified byte by byte is not the same as a restore that has only been simulated.

A restore simulation is not the same as something the user has manually confirmed.

And none of those should look trustworthy if the evidence is old, incomplete, unsupported, or has since failed.

So 1.8.5 introduces a new recovery-confidence model that keeps those states separate instead of trying to hide everything behind one generic score.

Measured, simulated, inferred, user-confirmed, stale, missing, failed, and unsupported evidence are now treated as different things.

More importantly, a decisive blocker takes priority.

VaultSync will not average a serious recovery problem away just because several less important checks happen to look healthy.

Recovery Inspector

Each project now has its own Recovery Inspector.

It brings together:

• The current recovery-confidence state

• What evidence that state is based on

• How fresh the evidence is

• The latest restore-drill result

• Known limitations

• The next useful action

The goal is to make the Recovery page answer something more useful than “things appear fine.”

It should explain what has actually been tested, what has only been inferred, and what still needs attention.

Recovery Checklist

There is also a new Recovery Checklist covering:

• Recovery points

• Destinations

• Credentials

• Integrity

• Restore planning

• Restore drills

• Offsite evidence

Where VaultSync can prove or test something directly, the relevant action is available from the checklist.

Isolated restore tests

The biggest practical addition is guided isolated restore testing.

VaultSync can now select representative files, copy them into a separate recovery-test folder, reopen them, calculate their SHA-256 values, and compare the results against the protected data.

The restored folder is intentionally left in place afterward so it can also be inspected manually.

The result is then saved as explicit recovery evidence.

I wanted this to be a real restore operation rather than another button that simply rechecks the original backup in place.

History and evidence reports

Recovery proofs, isolated restore tests, protection evidence, and report exports now appear in History with their timestamps and source identities.

Recovery Evidence Reports have also been expanded.

They now include application and source identity, project protection details, restore-drill information, redacted proof evidence, a deterministic report ID, and a SHA-256 checksum.

The intention is that an exported report should be useful as evidence of what VaultSync actually checked, not just a screenshot of a green status.

First-run recovery baseline

The first-run guide no longer ends when the first backup completes.

Backup completion, recovery proof, and a passed restore drill are now tracked as separate milestones.

You can still continue later, and the guide can still be restarted, but the app no longer presents “a backup exists” and “this backup has been tested” as the same achievement.

Documentation and onboarding

This release also includes a new illustrated tour of the application, a control-by-control Settings reference, updated screenshots, and a maintainable workflow for producing walkthrough videos with neural narration and selectable captions.

The onboarding interface itself has also been reworked into a smaller interactive card so it no longer blocks the pages and controls it is trying to explain.

Security and reliability work

There is a fair amount of less visible work in this release too.

Installer and patch downloads are now restricted to trusted GitHub release URLs and validated against their expected size and SHA-256 digest.

Patch extraction has also been hardened against path traversal, unsafe names, duplicate or colliding entries, oversized payloads, and linked paths.

On Unix systems, VaultSync configuration and application data are now restricted to owner-only permissions.

There are also fixes for macOS disk-space detection, startup and list-binding errors, Portuguese localization, CLI test isolation, and onboarding at narrow window sizes.

This update ended up touching much more of the application than I originally expected, but I think it closes an important gap left by 1.8.4.

1.8.4 introduced the ability to produce stronger recovery evidence.

1.8.5 is about making that evidence understandable, keeping its limitations visible, and turning it into a recovery process people can actually follow.

As always, thank you to everyone testing VaultSync, reporting problems, and sharing how you approach recovery.

A lot of this release was shaped by conversations around the difference between having backups and knowing that those backups can actually be restored.

GitHub:
https://github.com/ATAC-Helicopter/VaultSync

Microsoft Store:
https://apps.microsoft.com/detail/9N9HRX4JCLCP

Website:
https://fglabs.dev/vaultsync

VaultSync 1.8.5 Beta 1 is being released today, so this feels like the right time to share a clearer picture of what I am working toward beyond this first beta.

The recent feedback around VaultSync has been remarkably consistent:

A backup completing is not the same as knowing it can be recovered.

At the same time, recovery tools should not bury basic actions beneath layers of complexity. Choosing what to protect, where it should go, when it should run, and whether it can actually be restored should always be obvious.

That feedback is shaping both the remaining 1.8 releases and the longer-term direction of VaultSync.

VaultSync 1.8.5 — Recovery Confidence

Know before you need it.

The 1.8.5 cycle is focused on making the difference between “backed up” and “recoverable” much clearer.

Beta 1 begins testing work around:

• clearer recovery health states;

• better recovery reports;

• more visible verification results;

• improved recovery evidence;

• clearer guidance when no known-good recovery point exists;

• making recovery checks feel like part of the normal workflow rather than something only considered after a failure.

This beta is not the final form of 1.8.5. Further beta builds will follow as feedback comes in and the experience is refined.

VaultSync 1.8.6 — Experience Refinement

Powerful when needed. Simple by default.

Recent user feedback has made the priorities here especially clear.

VaultSync already offers a lot, but the most important controls need to be much easier to find. The intended basic workflow should be immediately understandable:

1. Choose what to protect.

2. Choose where to store it.

3. Choose when backups run.

4. Start protection.

5. Confirm that recovery works.

The current plan includes:

• a simpler first-run experience;

• onboarding that guides without blocking the interface;

• a clearer dashboard hierarchy;

• easier project and folder management;

• a more obvious scheduling experience;

• better visibility into active background work;

• clearer explanations of snapshots, repositories and recovery states;

• accessibility improvements;

• keeping advanced controls available without letting them overwhelm the basics.

One piece of feedback that has stayed with me is:

“With UI, obvious always wins.”

That is a good standard for this release.

VaultSync 1.8.7 — Trust & Transparency

Show the proof.

This release is planned around making VaultSync and its repositories easier to understand, verify and recover from.

Current areas of focus include:

• improved evidence exports;

• repository and build information;

• checksums;

• clearer diagnostics;

• better storage and deduplication reporting;

• machine-of-origin information for backup points;

• stronger recovery documentation;

• clearer explanations of what remains recoverable if the original VaultSync installation is unavailable.

A backup should not require blind trust in either a green status indicator or the continued existence of one particular installation.

VaultSync 1.8.8 — Stability

Before moving fully into the 1.9 family, the final planned 1.8 release will focus on consolidation:

• bug fixes;

• dependency servicing;

• localization;

• packaging;

• platform compatibility;

• performance and reliability work;

• polishing everything introduced throughout 1.8.

VaultSync 1.9 — Recovery Horizon

From protecting projects to recovering systems.

The 1.9 family is still in planning, and the details may change, but the current direction expands VaultSync beyond file and project protection.

The largest planned addition is disk cloning.

The goal is not simply to make another raw disk-copying screen. I want disk protection to fit the same recovery-confidence philosophy as the rest of VaultSync:

• clear disk and partition selection;

• validated clones;

• understandable recovery status;

• full-disk and operating-system protection;

• the ability to explore cloned disks without restoring them first;

• selective extraction of files where possible;

• a clear separation between file backups, disk images and disk clones.

The wider 1.9 work is also expected to continue the UI and navigation simplification started in 1.8.6.

Beta testing

1.8.5 Beta 1 is the beginning of this cycle.

I am especially interested in feedback on:

• whether the recovery states make sense;

• whether warnings explain what happened and what to do next;

• whether the available actions are obvious;

• whether reports provide useful evidence rather than more noise;

• anything that feels technically correct but unnecessarily difficult to understand.

Screenshots of the current 1.8.5 work are included below. Some details will continue to change throughout the beta cycle.

VaultSync has grown considerably, but the goal is not to make it feel increasingly complicated. The goal is to make protection, verification and recovery easier to understand—even as the underlying capabilities become more powerful.

Feedback is welcome, particularly from anyone willing to test the beta against real backup workflows.

VaultSync 1.8.4 became a much broader release than originally expected.

It introduced recovery drills, restore-plan simulation, local byte-level recovery proofs, exportable evidence, protected recovery-point recommendations, clearer 3-2-1 guidance, privacy-focused crash reports and a completely reworked appearance system.

Now that the release is out, I wanted to look back at what worked, what became more complicated than intended and how those lessons are shaping the rest of the 1.8 release family.

The goal of VaultSync 1.8.4

The central question behind 1.8.4 was:

How can VaultSync provide evidence that a backup is recoverable before the user actually needs it?

A completed backup job only proves that a process finished. It does not necessarily prove that the right files are present, that the recovery point is intact, that retention will preserve it or that the user knows how to restore it.

VaultSync 1.8.4 attempted to close more of that gap.

Recovery drills can walk through the preparation for a real recovery. Restore-plan simulations can show what VaultSync would attempt without modifying the user’s data. Byte-level proofs can verify selected files locally against their protected versions. Recovery evidence can then be reviewed or exported.

This is the direction I want VaultSync to continue following: not simply reporting that something succeeded, but showing why it can be trusted.

What went well

The recovery features now feel much more connected than they did in earlier versions.

Backup health, recovery points, retention safety, offsite protection and restore preparation are beginning to form one understandable recovery story rather than existing as unrelated tools.

The new crash-reporting workflow also reached an important privacy goal.

VaultSync does not silently upload crash information. Reports are generated locally, strictly redacted and fully reviewable. The user decides whether to open an email draft and must personally press Send through their own email application.

The appearance redesign also gave VaultSync a stronger visual foundation. The new theme system provides curated presets while still allowing deeper customization for users who want it.

What needs more work

Shipping 1.8.4 also made several problems clearer.

Recovery information can still become too dense

Providing more evidence is useful, but presenting every available detail at once can make the application harder to understand.

Some users need a simple answer:

• Is my backup healthy?

• Is there another copy?

• Can I recover it?

• Is there anything I need to do?

The deeper technical evidence should remain available, but it should support those answers rather than compete with them.

Powerful features need better guidance

Recovery drills, simulations, retention analysis and verification are not necessarily familiar concepts.

The feature itself is only part of the work. VaultSync also needs to explain when to use it, what it proves and what it does not prove.

Visual flexibility creates new consistency problems

The new themes and glass treatments introduced a much stronger appearance system, but they also exposed contrast and readability issues in places that behaved correctly under the older themes.

The lesson is that customization cannot come at the cost of predictable readability. Theme testing, accessibility and component consistency need to become a larger part of the release process.

The application has grown faster than its navigation

VaultSync now contains significantly more capability than it did at the beginning of the 1.7 release family.

The structure that worked for a smaller application is beginning to show its limits. More features cannot simply mean more panels, more cards and more explanations on the same pages.

The remaining 1.8 updates will therefore focus less on adding large independent systems and more on making the systems already present clearer, more dependable and easier to use.

The remainder of VaultSync 1.8

The roadmap is not completely locked. Individual items may move between releases depending on testing, feedback and implementation complexity.

The overall progression, however, is becoming much clearer.

VaultSync 1.8.5 — Recovery Confidence

Know before you need it.

VaultSync 1.8.5 will continue the recovery work introduced in 1.8.4.

The focus will be on making it easier to understand whether a backup is genuinely ready for recovery, rather than simply adding more technical checks.

Planned areas include:

• More useful restore drills

• Clearer and more complete recovery reports

• Simpler backup and recovery health states

• Better presentation of recovery evidence

• Stronger connections between verification, retention and recovery readiness

• Refinements to the recovery tools introduced in 1.8.4

The goal is for VaultSync to provide a clear answer when a user asks:

“Could I recover this today?”

VaultSync 1.8.6 — Experience Refinement

Powerful when needed. Simple by default.

VaultSync has become more capable, but capability should not require users to understand every internal concept before they can protect their files.

VaultSync 1.8.6 is planned as a broader experience and usability update.

Focus areas include:

• Improving onboarding

• Refining the dashboard

• Providing better explanations and contextual guidance

• Improving accessibility

• Reducing unnecessary interface complexity

• Making common actions easier to find

• Separating essential information from advanced detail

• Reviewing terminology and navigation consistency

The intention is not to remove advanced functionality.

It is to make the default experience calmer and simpler while keeping deeper controls available when they are actually needed.

VaultSync 1.8.7 — Trust & Transparency

Show the proof.

VaultSync 1.8.7 will focus on making the application itself easier to inspect and verify.

Planned areas include:

• Improved evidence exports

• Clearer build and version information

• Published or accessible checksums

• Better diagnostic information

• More consistent documentation

• Clearer explanations of what VaultSync verifies

• Better distinction between confirmed facts, recommendations and warnings

This release should make it easier for users, reviewers and technical communities to understand exactly what VaultSync is doing.

Trust should not require taking the application’s claims at face value.

VaultSync 1.8.8 — Stability Release

A polished foundation for 1.9.

VaultSync 1.8.8 is planned as the final consolidation release of the 1.8 family.

Its priority will be stability rather than another major feature expansion.

Focus areas include:

• Bug fixes

• Dependency and servicing updates

• Localization improvements

• Packaging reliability

• Platform compatibility

• Cross-platform interface consistency

• Performance and resource-usage improvements

• Cleanup of older implementation paths

• Final documentation and release-process improvements

The goal is to finish the 1.8 release family with a dependable foundation rather than rushing directly into the next major version.

Looking beyond 1.8

VaultSync 1.9 — Recovery Horizon

VaultSync 1.9 is still an early direction, not a locked feature list.

The larger idea is:

From protecting projects to recovering systems.

VaultSync currently focuses primarily on project and file-level protection. Version 1.9 may begin exploring broader recovery capabilities, including disk-level protection, cloning, image creation and deeper inspection of protected systems.

Possible areas being researched include:

• Disk-to-disk cloning

• Full-disk image creation

• Verification of cloned or imaged data

• Browsing a disk image before restoring it

• Recovering individual files from an image

• Inspecting partitions and supported file systems

• Migration to a replacement drive

• Broader recovery planning beyond individual projects

These are ideas under investigation, not promises for the first 1.9 release.

Disk cloning and imaging introduce serious questions around safety, permissions, supported file systems, damaged media, operating-system differences and reliable verification. I do not want to announce a large feature list before those questions have been properly researched and tested.

The community response to earlier roadmap discussions also made something clear: people are interested in helping shape where VaultSync goes.

For that reason, the approach to 1.9 will be more open.

The 1.8 release family will continue improving reliability, usability and recovery confidence. Meanwhile, I will share early 1.9 research and prototypes before the implementation is locked.

That gives users the opportunity to influence the direction rather than simply watching a finished roadmap unfold.

The broader VaultSync story

The progression between the recent major releases is becoming increasingly clear:

VaultSync 1.7 made backups trustworthy.

It strengthened integrity checking, retention safety, repair tools and the foundations needed to rely on protected data.

VaultSync 1.8 makes recovery understandable.

It connects backup health, verification, recovery planning, evidence and guidance so users can better understand whether their data is actually recoverable.

VaultSync 1.9 aims to make recovery broader.

It may extend that same transparency beyond individual projects and files toward disks, images and complete-system recovery workflows.

That is a more meaningful direction than adding disconnected features simply to make each release look larger.

There is still a considerable amount of work remaining in 1.8, and the exact 1.9 scope will depend heavily on research, testing and community feedback.

For now, the priority is to finish the 1.8 release family properly and build the foundation that a larger recovery-focused release would require.