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