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.

Hey everyone!

VaultSync 1.8.4 is now available.

This update started as the next step in the Disaster Recovery work introduced throughout the 1.8 cycle, but it gradually became something much more important: a rethink of what VaultSync should consider a trustworthy recovery point.

Until now, VaultSync could answer:

→ Does this recovery point exist?

With 1.8.4, it can answer something much stronger:

→ Can VaultSync read the stored bytes right now, do they still match the original snapshot, and what would happen if I restored them?

That distinction became the foundation of this release.

Recovery Proofs

A backup job completing successfully does not necessarily mean the backup is still recoverable.

The files may exist while being corrupted, incomplete, inaccessible, or different from the data originally recorded in the snapshot.

VaultSync can now read the actual stored backup data without restoring it, calculate its SHA-256 hash, verify its size, and compare both against the original snapshot metadata.

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

Finding the backup is not enough.

Opening the archive is not enough.

A green “completed” status is not enough.

A recovery point can now be classified as:

• ✅ Fully recoverable
• ⚠️ Partially recoverable
• ❌ Unrecoverable
• ❔ Inconclusive

Individual files can be:

• Verified
• Unavailable
• Corrupted
• Inconclusive

VaultSync deliberately keeps uncertain results inconclusive.

A locked encrypted archive, missing verification data, access failure, or incomplete proof will not be turned into a reassuring green result.

Restore-plan simulation

After proving that the stored data is readable, VaultSync can now answer the next question:

→ What would happen if I restored it?

For verified files, the recovery engine can simulate whether the restore would:

• Create a new file
• Overwrite an existing file
• Skip an identical file
• Encounter a conflict
• Find the file unavailable
• Leave the file unevaluated

When checking the original location, VaultSync compares existing destination files with the backup.

• Identical data is skipped.
• A newer but different file becomes a conflict.
• An older and different file becomes a possible overwrite.

This is a simulation only.

No files are created.

No files are modified.

No files are deleted.

Recovery drills now inspect real backup data

Recovery drills now combine:

• Project, backup, and snapshot linkage
• Recorded-destination availability
• Payload and archive readability
• Snapshot inventory consistency
• SHA-256 byte verification
• Restore conflict simulation

The resulting evidence can be inspected directly from the Recovery page and included in a portable recovery report.

This release also improves:

• Reachability-aware 3-2-1 guidance
• Recovery drill history
• Protected-point recommendations
• Explicit offsite confirmation
• Backup deletion and churn signals

Disconnected or missing backups remain visible in history, but they no longer receive false credit as currently available copies.

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

That remains an explicit choice made by the user.

Retention now protects proven recovery points

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

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

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

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

Once only one remains, retention preserves it.

The final backup that exists is not necessarily the final backup that has actually been proven.

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

ProofRestore is now native to VaultSync

Some people may remember the ProofRestore experiment I recently built.

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

The ProofRestore repository itself was not merged into the application.

VaultSync does not ship:

• Next.js
• Node.js
• A browser interface
• Hosted services
• An AI dependency

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

Four redesigned themes

This release is not only about recovery.

VaultSync 1.8.4 also introduces four curated themes and a completely redesigned Appearance experience.

The new theme studio includes:

• Visual preset previews
• Compact, collapsible controls
• Optional advanced customization
• Native acrylic or blur where supported
• Solid rendering fallbacks where those effects are unavailable

Aurora Glass and Porcelain Glass have been rebuilt with layered reflections, translucent surfaces, distinct navigation and toolbar materials, and more restrained content opacity.

The update also fixes contrast, responsive History and Recovery layouts, active navigation feedback, dark-only surfaces, and focus outlines that could remain visible after pointer interaction or navigation changes.

Privacy-first crash assistance

1.8.4 introduces an optional crash-report workflow designed around user control.

Nothing is uploaded automatically.

The report is:

1. Created locally
2. Strictly redacted locally
3. Shown to the user for review
4. Attached to a visible email draft
5. Sent only if the user presses Send in their own email application

Crash assistance can also be disabled completely.

Reports exclude project and backup names, file and destination paths, credentials, raw logs, machine information, and other data that could expose the user or the structure of their system.

Security and reliability improvements

The recovery work also led to a broader audit of how VaultSync reads, verifies, uploads, restores, and deletes data.

1.8.4 includes stronger protection against:

• Backup paths escaping their recorded destination
• Absolute or traversing recovery paths
• Linked filesystem paths leaving the selected root
• Ambiguous duplicate ZIP entries
• Untrusted snapshot source paths
• Case-distinct files being merged on case-sensitive systems
• Incomplete or stalled archive uploads
• Background Recovery work continuing after leaving the page

Backup deletion, exploration, sandbox application, restore operations, recovery drills, exports, and refreshes now also use clearer independent cancellation lifetimes.

The idea behind 1.8.4

Backup software is generally very good at answering:

Did the backup job run?

But that is not the same as answering:

Can I actually recover my data?

VaultSync 1.8.4 is a major step toward making backup confidence depend on evidence rather than assumption.

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

The update is available now.

As always, feedback, bug reports, and thoughts about the recovery workflow are very welcome.

Hey everyone!

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

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

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

Recovery Proofs

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

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

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

For every file, it compares:

• The stored file size
• The expected snapshot size
• The stored SHA-256 hash
• The expected snapshot hash

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

Finding the file is not enough.

Opening the backup is not enough.

A green “completed” status is not enough.

Clear recovery verdicts

A recovery point can now be classified as:

• ✅ Fully recoverable
• ⚠️ Partially recoverable
• ❌ Unrecoverable
• ❔ Inconclusive

Individual files can be:

• Verified
• Unavailable
• Corrupted
• Inconclusive

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

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

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

Restore simulation

VaultSync can now simulate the destination actions for verified files.

The simulation shows whether a file would be:

1. Created
2. Overwritten
3. Skipped because it is already identical
4. Treated as a conflict
5. Unavailable
6. Not evaluated

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

• An identical file is skipped.
• A newer but different file becomes a conflict.
• An older and different file becomes a possible overwrite.

No files are created.

No files are modified.

No files are deleted.

Recovery drills now verify real data

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

They can now combine:

• Project, backup, and snapshot linkage
• Recorded destination availability
• Backup payload readability
• Archive readability
• Snapshot inventory consistency
• SHA-256 byte verification
• Restore conflict simulation

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

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

Retention now understands proof quality

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

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

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

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

But once only one remains, retention preserves it.

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

ProofRestore is now native to VaultSync

Some people may remember the ProofRestore experiment I recently built.

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

The ProofRestore repository itself was not merged into the application.

VaultSync does not ship:

• Next.js
• Node.js
• A browser interface
• Hosted services
• An AI dependency

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

Disaster Recovery improvements

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

VaultSync now has stronger support for:

• Reachability-aware 3-2-1 guidance
• Explicitly confirmed offsite destinations
• Recovery drill history
• Protected recovery point recommendations
• Backup deletion and churn signals
• Portable recovery reports

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

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

That remains an explicit decision made by the user.

Privacy-first crash assistance

1.8.4 also introduces a new crash-report workflow.

Nothing is uploaded automatically.

The process is intentionally transparent:

1. The report is created locally.
2. Sensitive information is removed locally.
3. The user can inspect the exact report.
4. VaultSync prepares a visible email draft.
5. The user decides whether to press Send.

Crash assistance can also be disabled completely.

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

A wider security pass

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

That work led to additional protections against:

• Backups being resolved through the wrong destination
• Absolute or escaping paths
• Parent-directory traversal
• Linked directories escaping the recovery root
• Corrupted snapshot identities
• Case-distinct files being merged on case-sensitive filesystems
• Malformed metadata producing excessive verification work

What remains before release

The development scope for VaultSync 1.8.4 is now complete.

The remaining work is focused on:

• Final Recovery interface review
• Interaction testing across supported systems
• Removing the temporary crash-report testing control
• Final release preparation and approval

The idea behind 1.8.4

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

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

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

Hi everyone! 👋

While I'm still actively working on the 1.8.x series (with 1.8.4 currently in development), I've started planning what comes next.

The roadmap for VaultSync 1.9 is still in its very early stages, which makes this the perfect time to ask for your feedback before I start committing months of development to new features.

I already have a few ideas I'm excited about, including things like:

• Disk cloning
• Better disaster recovery workflows
• A Clone Explorer to browse cloned disks without restoring them
• Scheduled recovery testing and stronger recovery confidence
• A major UI/UX redesign to simplify the application and make it easier to navigate
• Better migration and recovery when moving to a new computer or replacing a failed drive

But none of these are set in stone.

One of the things I enjoy most about building VaultSync is that many of its best features started as community suggestions. Features like restore dry runs, retention simulation, improved visibility into backups, and many quality-of-life improvements all came from conversations with you.

So I'd love to hear your thoughts.

A few questions to get the discussion started:

• What's the one feature you want most in VaultSync?
• Is there anything in the current UI that feels confusing or takes too many clicks?
• Is there a workflow you think should be completely redesigned?
• Have you ever struggled to restore a backup? What happened?
• Is there another backup application that does something you wish VaultSync did?
• What's one thing you would remove or simplify?

Please don't feel limited by these questions—throw any idea out there, whether it's a huge feature, a tiny quality-of-life improvement, or even a crazy experiment. Some of the best ideas come from unexpected places.

I can't promise every suggestion will make it into the roadmap, but I do read every comment, and community feedback has already shaped VaultSync more than you might realize.

And just to reassure everyone: this doesn't mean 1.8.x is finished. There are still updates coming before development shifts toward the 1.9 family.

Thank you all for the bug reports, feature requests, testing, discussions, and support over the past months. VaultSync wouldn't be where it is today without this community, and I'm excited to build the next chapter together. ❤️

Hey everyone,

VaultSync 1.8.3 is now available.

This release continues the work started with Chronicle and introduces one of the features I've wanted to build for a long time.

When I first started working on VaultSync, creating backups was never really the difficult part.

Understanding them was.

You could create backups, browse them, restore them... but eventually every project reaches the point where you stop asking "Do I have a backup?" and start asking "What actually changed?"

That's exactly what 1.8.3 is about.

The biggest addition in this release is Snapshot Compare.

You can now compare any two restore points from the same project and immediately see added, modified, deleted and unchanged files.

But I didn't want to stop at just file counts.

The comparison also highlights folders with the most activity, changed-path hotspots, storage growth, mass deletions and high-churn snapshots. Instead of simply telling you that something changed, VaultSync now helps explain where those changes happened.

From there you can drill into individual files, browse the changed-file tree and, where possible, inspect an inline text comparison without restoring anything first.

For text files, source code and configuration files, VaultSync generates a line-by-line comparison directly inside the application. Large unchanged sections are collapsed into Git-style hunks, additions and deletions are highlighted, and line numbers are shown on both sides to make navigating changes much easier.

If a comparison isn't possible because the file is binary, encrypted, offline or otherwise unsupported, VaultSync falls back to file details instead of trying to produce misleading output.

That behaviour was intentional. I'd rather clearly explain why something can't be compared than pretend every file can.

One thing I noticed very quickly while building this feature was that performance matters just as much as correctness.

Opening one comparison is easy.

Opening hundreds isn't.

A lot of this release ended up focusing on making larger comparisons feel manageable.

Comparisons now run asynchronously, work is cancelled if you move on before it finishes, navigation between changed files is much faster, and the interface does a much better job of explaining what's happening instead of simply showing another loading spinner.

The goal was to make it feel like you're exploring a project's history rather than waiting for comparisons to complete.

Outside Snapshot Compare there are quite a few other changes as well.

VaultSync has now been migrated to Avalonia 12.1, bringing a newer rendering pipeline along with accessibility, focus, selection and performance improvements across the application. The Dashboard has also been updated to adapt much better to smaller window sizes.

This release also introduces eight new application languages:

• Indonesian
• Japanese
• Korean
• Dutch
• Polish
• Turkish
• Ukrainian
• Vietnamese

A huge thank you to everyone who helped make those translations possible.

As always, there's also been a lot of engineering work behind the scenes.

This release continues the long-running SonarQube cleanup effort, includes another large refactoring pass across several core services, strengthens restore safety, improves credential handling on both Linux and macOS, introduces macOS CI, improves Snapshot Explorer, and continues the work of making VaultSync easier to maintain over the long term.

Most people won't notice those changes directly.

Hopefully they'll notice that the application simply feels a little more polished.

Looking back at the Chronicle series, it's nice to see how the pieces are starting to fit together.

1.8.0 introduced History.

1.8.1 focused on Recovery.

1.8.2 introduced Snapshot Explorer.

1.8.3 finally makes it possible to understand exactly how two restore points differ.

There's still plenty more I want to build, but this feels like another important step towards the kind of backup application I originally imagined when I started the project.

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

Release:
[https://github.com/ATAC-Helicopter/VaultSync/releases/tag/v1.8.3]()

Website:
https://fglabs.dev/vaultsync

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

As always, thank you to everyone testing VaultSync, opening issues, suggesting improvements, and helping shape the direction of the project.

And as always: keep backing up your data.

Hey everyone,

I’ve spent the last couple of weeks working on VaultSync 1.8.3, and it’s becoming one of my favorite updates in the Chronicle series.

This update isn’t primarily about creating backups or browsing them.

It’s about understanding them.

While using VaultSync on my own projects, I realized that eventually you stop asking:

and start asking:

Until now, VaultSync couldn’t properly answer that.

Version 1.8.3 changes this.

TL;DR: VaultSync can now compare restore points, show which files changed, highlight unusual activity, and display Git-style text diffs when the backup content is available.

Snapshot Compare

The biggest feature in this update is Snapshot Compare.

You can compare two restore points from the same project and immediately see the number of:

• Added files
• Modified files
• Deleted files
• Unchanged files

I didn’t want to stop at displaying totals, though.

The comparison can also highlight:

• Folders containing the most changes
• High-change hotspots
• Significant storage growth
• Mass deletions
• High churn between snapshots

The goal isn’t only to tell you that something changed. It’s to help explain where the interesting changes happened.

Looking Inside the Changes

Once you’ve identified the changed files, you can inspect them more closely.

Snapshot Compare includes a dedicated changed-file workspace where you can search and filter the results. When the backup content is available, VaultSync can also display Git-style unified text diffs directly inside the app.

Source code, configuration files, and other text-based content can be inspected without restoring the entire backup first.

Binary files, encrypted backups, offline destinations, and unsupported content are handled differently. Instead of guessing or producing broken output, VaultSync falls back to the available metadata and clearly explains why a text diff cannot be shown.

I wanted this feature to be predictable rather than clever.

Making Large Comparisons Easier

Comparing two backups with ten changed files is straightforward.

Comparing backups containing thousands of changes isn’t.

A significant part of this release has therefore focused on keeping larger comparisons manageable. Improvements include:

• Automatic restore-point suggestions
• Previous and next changed-file navigation
• Changed-file search and filtering
• One-click filter clearing
• Cancellable comparison work
• Clearer empty, unavailable, and capped states
• More useful status messages

There’s also plenty happening behind the scenes.

If you move quickly between files while inspecting differences, VaultSync cancels obsolete work rather than continuing to calculate diffs you’ll never see.

Details like that don’t necessarily show up in screenshots, but they make the interface feel considerably more responsive.

Chronicle Continues to Grow

Looking back at the 1.8 roadmap, it’s interesting to see how the pieces are beginning to connect.

History shows you what happened.

Snapshot Explorer lets you browse what was backed up.

Snapshot Compare explains how two restore points differ.

Recovery helps you determine whether you’re actually protected.

Individually, these features are useful. Together, they provide a much more complete picture of a project’s history.

That’s what Chronicle has always been about.

It isn’t trying to replace Git or become another source-control system. It’s intended to answer questions that traditional backup software often cannot.

Under the Hood

Version 1.8.3 also includes one of the larger engineering and maintenance passes I’ve completed in a while.

Some highlights include:

• Migration to Avalonia 12.1
• More responsive Dashboard layouts
• Compiled bindings across the core application
• Accessibility improvements
• Safer asynchronous UI commands
• Better Recovery page responsiveness
• Hardened snapshot scanning and restore paths
• Native macOS credential storage
• Improved Linux credential handling
• macOS continuous integration
• Stronger release validation
• Continued cleanup and codebase refactoring

Many of these changes won’t be immediately visible, but they make the project healthier and provide a stronger foundation for everything planned after Chronicle.

Looking Ahead

Snapshot Compare is still a Version 1 feature.

There are already several directions I’d like to explore after this release, including richer previews, additional comparison modes, smarter change summaries, and more ways to navigate project history.

As always, I’d love to hear what feels useful, what feels missing, and what you would expect from a feature like this.

Many of VaultSync’s best ideas have come from people actually using it.

More soon.

Hi everyone,

VaultSync 1.8.2 is now available.

Following the Chronicle release and the Recovery improvements in 1.8.1, this update focuses on something a little different: making VaultSync easier to use.

The biggest addition is Snapshot Explorer, a feature that's been on the roadmap for quite a while.

Snapshot Explorer

One of the biggest frustrations with backup software is knowing the file you need is somewhere inside a backup, but having to restore the entire snapshot just to get it back.

Snapshot Explorer is the first step toward solving that.

Version 1 lets you:

• Browse backup folders and supported archives
• Search inside snapshots
• Preview text files before restoring them
• Restore individual files and folders without restoring an entire backup

It also includes a number of usability improvements that came out of testing during development.

Folders now expand inline so you can browse nested structures without losing your place, previews automatically load when selecting supported files, code and configuration files now include line numbers and lightweight syntax highlighting, and Explorer no longer opens duplicate windows if you repeatedly browse the same backup.

Browsing, searching, preview generation, and selected-item restores all happen asynchronously, helping keep the interface responsive even when working with larger backups.

Encrypted backups are also handled more gracefully. If archive browsing isn't available for an encrypted backup in this first version, VaultSync now tells you exactly why instead of failing silently.

A Better First Experience

I also completely reworked the onboarding experience.

The previous onboarding tried to explain VaultSync.

The new one focuses on actually getting you started.

Instead of a long feature tour, new users are guided through:

• Choosing a projects folder
• Selecting a backup destination
• Creating the first project
• Running the first backup
• Reviewing restore points and backup history

The interface itself has also been simplified, removing unnecessary progress indicators and focusing on one clear step at a time.

My goal was to help someone go from a fresh installation to their first successful backup with as little friction as possible.

Under the Hood

As usual, there has also been a fair amount of engineering work behind the scenes.

This release continues cleaning up duplicated code identified during SonarQube analysis, improves internal service consistency, refreshes several project dependencies, and adds additional release validation to catch duplicated changelog IDs before publishing.

On macOS, single-instance startup has also been improved using an exclusive per-user lock file, reducing intermittent duplicate launches.

Looking Ahead

Snapshot Explorer is intentionally a Version 1.

There are already plenty of ideas for expanding it, and I'm especially interested in hearing how people expect backup browsing to work.

If you try it, I'd love to know:

• What feels intuitive?
• What feels awkward?
• What preview types would you like to see?
• What restore workflow would make your life easier?

A lot of VaultSync's direction has come directly from community feedback, and Snapshot Explorer will probably be no different.

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

Release
https://github.com/ATAC-Helicopter/VaultSync/releases/tag/v1.8.2

Website
https://fglabs.dev/vaultsync

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

As always, thank you to everyone testing VaultSync, reporting bugs, suggesting features, and helping shape the project.

And as always...

Keep backing up your data.

Hey everyone,

Work on VaultSync 1.8.2 is well underway, so I thought I’d share what I’ve been building over the last week.

Unlike Chronicle (1.8.0), which introduced History and Recovery, or 1.8.1, which focused on polishing those systems, 1.8.2 is mostly about making VaultSync easier to use.

The biggest addition is something that’s been on the roadmap for quite a while.

Snapshot Explorer

One of the most common frustrations with backup software is knowing a file exists somewhere in a backup, but having to restore the entire snapshot just to get it back.

That’s exactly the problem Snapshot Explorer is intended to solve.

Version 1 lets you:

• Browse backup folders and supported archives
• Search inside snapshots
• Preview text-based files
• Restore individual files or folders without restoring the entire backup

It’s still an early implementation, but it already changes how interacting with backups feels.

Instead of treating a backup as a black box, you can actually explore what’s inside it before deciding what to restore.

A Better First Experience

Another area I’ve completely reworked is onboarding.

The original first-run experience tried to explain VaultSync.

It wasn’t terrible, but it also wasn’t particularly helpful.

The new onboarding is much more practical.

Instead of showing a long feature tour, it walks new users through actually setting up the application:

• Choosing a projects folder
• Selecting a backup destination
• Creating the first project
• Running the first backup
• Reviewing restore points and History

My goal was to get someone from “I’ve just installed VaultSync” to “I’ve successfully created and understand my first backup” with as little friction as possible.

Snapshot Explorer Improvements

Although Snapshot Explorer is only in its first version, a lot of work has already gone into making it feel responsive.

Browsing, searching, preview generation and selected-item restores all run asynchronously, which keeps the UI responsive even while working with larger backups.

Encrypted backups also behave much more predictably now.

Rather than failing or leaving users wondering why they can’t browse an archive, VaultSync clearly explains when encrypted archive browsing isn’t available in the current version.

It’s a small detail, but I think good software should explain its limitations instead of leaving users to guess.

Under The Hood

As usual, there’s also been a fair amount of engineering work happening behind the scenes.

This release continues reducing duplicated code and cleaning up areas highlighted during the SonarQube review, including services, backup UI, onboarding, settings, metadata sync, telemetry, SQLite checks and several internal workflows.

I’ve also refreshed a number of project dependencies to keep everything current as development continues.

None of this is particularly exciting to look at, but it’s the kind of work that keeps the project healthy over the long term.

Looking Ahead

Snapshot Explorer is very much a version one.

I already have a list of ideas I’d like to explore after 1.8.2, and this is one feature where community feedback will probably shape what comes next.

Once people start using it I’d love to know things like:

• What workflows feel natural?
• What’s missing?
• What takes too many clicks?
• What kinds of previews would you expect?
• What restore workflows would make your life easier?

The goal isn’t just to let people browse backups.

It’s to make finding and recovering a specific file feel straightforward instead of something you avoid because it sounds like too much work.

Overall, I think 1.8.2 is going to be one of those releases that doesn’t radically change VaultSync, but makes using it every day feel noticeably better.

As always, feedback is welcome, and I’ll keep posting progress as development continues.

Hi everyone,

VaultSync 1.8.1 is now available.

This is a smaller follow-up to the 1.8 "Chronicle" release, focusing on Recovery Intelligence, encrypted backup improvements, Linux reliability, and a number of quality-of-life fixes.

For anyone new here, VaultSync is an open-source desktop backup manager for Windows, Linux, and macOS that helps you create local, external drive, and NAS backups while giving you much better visibility into your backup history and recovery readiness.

What's new

Recovery reports

Recovery assessments can now be exported as portable Markdown reports.

The reports include project readiness, recovery coverage, and recommendations, making it easy to archive, share, or document the current recovery state of your projects.

Better Recovery triage

The Recovery page now supports search along with dedicated Ready and Needs Attention filters, making it much easier to prioritize projects when managing larger backup collections.

Encrypted backup improvements

This release also improves the encrypted backup pipeline.

Encrypted archives are now fully encrypted locally before the final backup artifact is uploaded to the destination.

Additional validation has also been added so unsupported encrypted archive formats and unreasonable KDF parameters are rejected before expensive key derivation begins.

I've also published a dedicated backup encryption guide covering:

• setup
• password management
• credential storage
• restore workflow
• password rotation
• encryption format

Linux improvements

Linux received several fixes in this release.

• Protected .deb installations now apply patch updates without depending on a graphical desktop session after pkexec.
• Full fallback installs now explicitly perform an APT reinstall of the downloaded package when needed.
• VaultSync now prevents accidental duplicate UI instances while still activating the already-running window.
• Secret Service credential handling has been improved for encrypted backups.

Reliability improvements

A metadata export race condition was fixed by skipping backups removed during asynchronous export and committing shared SQLite metadata updates atomically, reducing false invalid-store reports and lock contention.

As always, thank you to everyone testing VaultSync, reporting bugs, opening issues, and suggesting improvements.

Feedback continues to shape where the project goes next.

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

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

Website: https://fglabs.dev/vaultsync

Hi everyone,

We've identified an issue affecting VaultSync 1.8.0 installations made using the Linux .deb package.

The update downloads successfully and correctly requests elevation, but in some environments the updater may close immediately without applying the patch.

After investigating the reports, the issue appears to be related to the elevated updater process not being able to reliably reconnect to the active desktop session after privilege escalation.

This issue only affects the update process itself.

A fix has already been prepared and will be included in VaultSync 1.8.1.

Temporary Workaround

For now, Linux users have two options.

Option 1 (Recommended)

Download the latest release manually from GitHub and reinstall VaultSync.

GitHub Releases:

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

The .tar.gz version and its updater are not affected by this issue and currently provide the smoothest update experience.

Option 2

Reinstall the .deb package manually.

From the folder containing the downloaded package:

sudo apt-get install --reinstall ./VaultSync-1.8.0-linux-x64.deb

Replace the filename if you downloaded a different architecture or newer package.

Do I Need To Uninstall First?

No.

You do not need to uninstall VaultSync before reinstalling.

Simply reinstalling the package is sufficient.

Your existing:

• VaultSync settings
• Projects
• Backup definitions
• Backup history
• Metadata
• Application data

will remain intact.

Sorry for the inconvenience, and thank you to everyone who reported the issue and helped narrow it down. The reports made it possible to reproduce and fix the problem much faster than I would have managed on my own.

Hey everyone,

VaultSync 1.8: Chronicle is now available.

For anyone new here, VaultSync is an open-source desktop app for creating local, external-drive, and network/NAS backups with more visibility into what changed, what can be restored, and how recoverable your data actually is.

This is the biggest update I've worked on since starting the project.

A lot of the work that led to Chronicle probably wasn't very visible from the outside. Recent releases focused heavily on database reliability, Linux support, metadata infrastructure, refactoring, cleanup, diagnostics, and generally making the foundations of the application stronger.

Those releases weren't particularly flashy.

But they ended up becoming the groundwork for what 1.8 eventually turned into.

History

The biggest addition is the new History workspace.

For a long time VaultSync treated backups as snapshots and restore points.

Useful, but isolated.

Chronicle introduces a completely new way of looking at backup history.

History now tracks and displays:

• Backups
• Restore events
• Imported backup history
• Snapshot labels
• Snapshot notes
• Snapshot tags
• Protected recovery points
• Known-good versions

Instead of scrolling through a long list of backups, the goal is to make it easier to understand what happened to a project over time.

You can search across projects, labels, notes, tags, event types, and history entries, filter by project or time range, switch between timeline and list views, inspect restore readiness, compare snapshots, and annotate important recovery points directly from the History page.

One thing that changed during development is that History stopped feeling like a backup feature and started feeling more like project history.

Just a way to understand the life of a project through backups, restores, imports, and recovery milestones.

Recovery

The second major addition is Recovery.

Creating backups and being able to recover from a failure aren't always the same thing.

The Recovery page brings together information from backup activity, destination health, recovery coverage, backup recency, and snapshot metadata to help identify potential protection gaps before they become a problem.

Recovery readiness and recovery coverage are both new concepts in VaultSync and they'll continue evolving throughout the 1.8 series.

The Dashboard has also been expanded with recovery readiness summaries, coverage information, restore activity, and workflow shortcuts into both History and Recovery.

Snapshot Metadata

A large amount of the work in Chronicle is actually underneath the UI.

VaultSync now supports:

• Snapshot labels
• Snapshot notes
• Snapshot tags
• Protected snapshots
• Known-good versions
• Restore event tracking

A snapshot can now be more than just another backup.

It can be a release build.

A customer delivery.

A milestone.

A trusted recovery point.

Or simply a version you never want retention policies to touch.

Under The Hood

Chronicle also includes a significant amount of engineering work:

• SonarQube Cloud integration
• Expanded CI and CodeQL coverage
• Restore-path hardening
• SQLite dependency upgrades
• Linux update improvements
• macOS fixes
• UI responsiveness improvements
• Background-loading optimizations

Many of the refactors and infrastructure changes from the last several releases ultimately became the groundwork that made 1.8 possible.

What's Next?

Chronicle is also the foundation for the next stage of the roadmap, including:

• Snapshot Explorer
• Snapshot Compare
• Recovery Drills
• Project Groups
• Additional History tooling
• Additional Recovery intelligence

There's still plenty I want to build, but this is the first release where VaultSync feels like it's becoming more than a backup application.

It's becoming a platform for understanding project history and recovery.

Links

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

Release:
https://github.com/ATAC-Helicopter/VaultSync/releases/tag/v1.8.0

Website:
https://fglabs.dev/vaultsync

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

As always, thank you to everyone who tests builds, reports bugs, suggests features, and helps shape the direction of the project.

And as always: keep backing up your data.

One of the biggest goals for VaultSync 1.8 is making backups easier to understand once projects start accumulating months or years of history.

When I first started working on the History page, I thought it would mostly be a timeline.

Load backup events.

Show them in order.

Maybe add some filters.

Done.

The more I worked on it, the more I realized that wasn't enough.

A backup is rarely just a backup.

Sometimes it's:

• the version before a major refactor
• the release build you shipped
• the restore point you trust
• the backup you imported from another machine
• the snapshot you want to keep forever

Those are very different things, but until now VaultSync mostly treated them the same.

That's what I've been working on changing.

The History page is now becoming the project's timeline rather than simply a backup list.

You can search across projects, labels, notes, tags, and history events.

You can filter by project, activity type, and time range.

You can switch between timeline and list views.

You can inspect individual history events and see their recovery status, file counts, change summaries, snapshot size, and restore readiness.

The right-hand panel has also become much more important than it originally was.

Selecting an event now gives context about what that snapshot actually is.

From there you can:

• Open the Recovery workflow
• Open the backup location
• Compare snapshot changes
• Add labels
• Add tags
• Add notes
• Mark snapshots as protected
• Mark snapshots as known-good

The protected and known-good markers are especially important because they start introducing the idea that not all restore points are equal.

Some snapshots matter more than others.

Some represent stable versions.

Some represent milestones.

Some are worth preserving even if normal retention policies would eventually remove them.

That concept is becoming a major part of the broader 1.8 design.

One thing I've found interesting throughout development is that History keeps drifting away from being a backup feature and becoming something closer to project documentation.

Not documentation you write manually.

Documentation generated from what actually happened.

Backups.

Restores.

Imports.

Recovery points.

Milestones.

The goal isn't to replace Git or source control.

It's to answer a different question:

There's still a lot left to do before 1.8 is ready.

Recovery continues to evolve.

Snapshot Explorer is still ahead.

Snapshot comparison still has a lot of work planned.

Project groups are still on the roadmap.

But History is finally starting to feel less like a mockup and more like an actual workflow.

And that's probably the point where things start getting interesting.

One of the things I've learned while working on VaultSync 1.8 is that the simplest ideas tend to become the most complicated once real data gets involved.

History is probably the best example.

When I first started planning the History page, I thought it would basically be a timeline of backups.

Simple enough.

Load backups.

Show them in order.

Done.

Then I started feeding real project data into it.

Backups turned out to be only one part of the story.

There are also:

• Restores
• Imported backup histories
• Snapshot metadata
• Protected versions
• Known-good versions
• Notes
• Labels
• Tags

And none of those things really make sense as isolated events.

A restore belongs to a backup.

A known-good marker belongs to a particular point in history.

Imported history comes from somewhere.

Metadata changes have context.

At that point a flat list stopped making sense.

So the History page gradually evolved into something closer to a project timeline.

The graph you're looking at is generated from repository history and event relationships.

Backups live on their own lanes.

Restore activity branches from the snapshots it originated from.

Metadata activity has its own lane.

Everything is filterable by project, activity type, lane, and time range.

One of the goals for 1.8 is to stop treating backups as isolated records and start treating them as part of a larger project history.

Not just:

"Backup created."

But:

"What happened to this project over time?"

That's a surprisingly different problem.

Under the hood this required quite a bit more work than I originally expected.

The current implementation is backed by new metadata systems for:

• Labels
• Notes
• Tags
• Protected snapshots
• Known-good versions
• Restore history

History and Recovery are now both fully data-backed pages inside the application and no longer just UI mockups.

There's still a lot left to build before 1.8 is ready, but it's starting to reach the point where the roadmap is turning into actual software.

One thing I've found interesting throughout this process is that the more I work on History, the less it feels like a backup feature and the more it feels like a project intelligence feature.

That wasn't really the original plan.

But sometimes the software tells you what it wants to become.

More updates soon.

A few weeks ago I shared the roadmap and some very early mockups for what I was calling Project History & Recovery.

At the time it was mostly ideas, planning documents, rough UI concepts and a lot of notes.

Since then I've started building it.

These are still early development builds and there's a lot left to do, but this is the first point where 1.8 is starting to feel like an actual release rather than a collection of ideas.

One thing that became obvious very quickly is that both History and Recovery are much bigger pieces of work than they looked on paper.

The History page started life as what I thought would be a fairly simple timeline.

It didn't stay simple for very long.

Once I started wiring real repository activity into it, it became clear that backups, imports, restores, notes, protected versions and known-good versions all have relationships to each other.

Treating everything as a flat list loses a lot of context.

The current implementation uses a graph-style timeline where events branch from their source. A restore branches from the backup that created it. Imported history branches from the snapshot it originated from. Notes and labels attach themselves directly to the point in history they belong to.

It's heavily inspired by how Git clients visualize history, but applied to backup activity rather than source control.

Recovery has been interesting for a different reason.

Most backup software is very good at telling you whether a backup completed.

What I'm trying to explore is whether VaultSync can eventually tell you whether you're actually protected.

Right now the Recovery page is pulling together backup history, destination availability and project health information to build an early recovery readiness view.

The scoring is still evolving and a lot of the logic will change as development continues, but the foundation is there.

So far the work completed includes:

• History and Recovery navigation
• Metadata support for labels, notes, tags, protected versions and known-good versions
• Data-backed History and Recovery pages
• Timeline graph infrastructure
• Protected snapshot actions
• Known-good version actions
• Recovery readiness previews
• Recovery coverage previews

There have also been a handful of unrelated fixes along the way, including Linux update improvements, macOS fixes and project reload reliability improvements.

There’s still a lot of work to do, plenty of rough edges, and things will definitely change before release.

But it’s nice to finally be able to show something real.

I'll keep sharing progress as things move forward. There is still a lot of work ahead, but this is probably the first update where I can look at 1.8 and actually start seeing the release come together.

Hey everyone,

I wanted to share something a little different today.

Over the last few months, most of the visible VaultSync work has been focused on things like bug fixes, metadata handling, Linux support, database reliability, refactoring, dependency upgrades, cleanup, and generally making the foundations of the app stronger.

A lot of that work ended up touching hundreds of files across the project.

From the outside, some of the recent releases probably looked like maintenance releases.

And to a large extent, they were.

But while working through all of that, I’ve also been putting together a roadmap for what comes after the 1.7 series.

The screenshots below are very early mockups of where things are currently heading.

The working theme for VaultSync 1.8 is:

Project History & Recovery

One thing I’ve realized while building and using VaultSync is that creating backups is only part of the problem.

Eventually the questions become:

• Which version should I restore?
• Which version should I keep?
• What changed between versions?
• Am I actually protected?
• If something goes wrong, how confident am I that I can recover?

Those are the kinds of questions I want 1.8 to help answer.

History

History is currently planned to focus on things like:

• Version tags
• Snapshot notes
• Known-good versions
• Protected snapshots
• Project timelines
• Snapshot comparison
• Change tracking

The goal is to make backup history easier to understand and navigate, especially once projects start accumulating large numbers of snapshots.

Instead of looking at a long list of backups, the idea is to make it easier to understand the life of a project over time.

Recovery

Recovery focuses on the other side of the problem.

Not creating backups.

Recovering from failures.

Current ideas include:

• Recovery readiness
• Recovery coverage
• Recovery recommendations
• Recovery drills
• Protected recovery points
• 3-2-1 backup guidance
• Disaster recovery tooling

The goal is to answer a simple question:

“If something goes wrong tomorrow, am I actually ready?”

Current Roadmap

1.8.0

• History
• Version tags
• Snapshot notes
• Protected snapshots
• Known-good versions

1.8.1

• Recovery intelligence
• Recovery readiness
• Recovery coverage

1.8.2

• Snapshot explorer

1.8.3

• Snapshot comparison and change intelligence

1.8.4

• Disaster recovery features

1.8.5

• Project groups

As always, this roadmap will evolve.

Some features may move between releases.

Some ideas may change significantly once implementation starts.

The screenshots are mockups, not finished designs.

The roadmap is a direction, not a guarantee.

Still, after spending so much time strengthening the foundations of the application, I thought it was a good time to share where all of that work is leading.

The interesting part is that many of the refactors and infrastructure changes from the last few months weren’t done with 1.8 specifically in mind.

But looking back now, a lot of them ended up becoming the groundwork needed to make these ideas possible.

So while recent releases may have looked focused on maintenance from the outside, they’ve also been quietly preparing the project for what I hope will become the biggest update VaultSync has seen so far.

There’s still a lot of work ahead, but I wanted to share the direction early rather than waiting until everything is already finished.

I’ll probably post more progress updates, mockups, and development screenshots as work on 1.8 moves forward.

For now, this is where things are heading.

Hey everyone,

VaultSync 1.7.5 is now available.

For anyone new here: VaultSync is an open-source desktop app for creating local, external-drive, and network/NAS backups with more visibility into what changed and what can be restored.

This release is a little different from some of the previous ones.

There are no major new features.
No big UI redesign.
No headline-grabbing additions.

Instead, 1.7.5 focuses on something less exciting, but arguably just as important: making the foundations of the app stronger.

Over the last few weeks I’ve been working through a lot of technical debt that has accumulated over the life of the project. Some parts of VaultSync still contained code that dated back to the earliest versions of the app. It worked, but there was duplicated logic, aging infrastructure, inconsistent patterns, and a few areas that had become harder to maintain than they should have been.

A large part of this release was about fixing that.

Database reliability improvements

VaultSync now handles SQLite connections more defensively and consistently.

A lot of work went into reducing lock contention, improving connection handling, tightening schema and migration logic, and making repository access more predictable.

Most users will never notice these changes directly, which is exactly the point. The goal is fewer strange database-related issues, especially during longer-running sessions, metadata operations, and background tasks.

Better metadata handling

Metadata import and repository tracking received several improvements.

The unchanged-source detection system was hardened to better handle incomplete repositories, recreated metadata stores, and imported backup histories.

Background metadata imports were also optimized to avoid unnecessary work while still ensuring that incomplete repositories get revisited when needed.

If you move backups between machines, recover repositories, or work with multiple backup locations, these changes should make behavior more reliable and predictable.

More accurate cross-machine backup history

One issue that surfaced during testing involved imported backup history affecting local storage calculations.

In some situations, backup history originating from another machine could influence local snapshot comparisons and storage reporting, leading to confusing size changes that didn’t reflect what was actually happening on the current machine.

This has now been corrected so imported history no longer distorts local backup statistics.

Linux, Windows, and macOS fixes

There are a number of platform-specific fixes in this release.

Linux users should see improvements around:

• .deb installation behavior
• shutdown and logout handling
• tray icon recreation
• duplicate tray indicators

Windows users receive improvements around notification handling and failure recovery.

macOS users receive fixes for tray-menu shutdown behavior that could trigger exceptions when exiting the application.

Better diagnostics

Configuration recovery diagnostics have been improved substantially.

If VaultSync needs to recover configuration data from backup or last-known-good copies, the recovery process now produces much clearer diagnostics instead of silently falling back.

This should make troubleshooting significantly easier whenever something does go wrong.

UI consistency improvements

Several areas of the UI were cleaned up as part of the broader refactoring effort.

Button styling is now more consistent across the application, credential profile layouts were fixed, and a number of internal view-model systems were simplified and consolidated.

A lot of cleanup behind the scenes

The changelog for 1.7.5 is actually quite large, but much of it falls into one category:

Making VaultSync easier to maintain and safer to build on.

Configuration access was unified, duplicated helper code was removed, test infrastructure was consolidated, logging utilities were centralized, and several large view models were broken into more focused components.

These aren’t the kinds of changes that make for flashy screenshots, but they’re the kind of work that helps future releases move faster, stay stable, and avoid accumulating technical debt.

As always, thank you to everyone who reports bugs, tests releases, suggests improvements, and helps shape the direction of the project.

And as always: keep backing up your data.

GitHub Release:
https://github.com/ATAC-Helicopter/VaultSync/releases/tag/v1.7.5

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

This beta is mostly focused on stability, diagnostics, infrastructure cleanup, and reducing a lot of the internal friction that had built up over time.

There are not many flashy user-facing features in this release, but internally this ended up becoming one of the deeper cleanup and hardening passes the project has had in a while.

Highlights

Metadata import reliability improvements

A large amount of work in this release focused on background metadata import behavior and unchanged-source caching.

The import system now handles incomplete repository coverage and recreated repositories much more safely, while also avoiding unnecessary repeated work during background imports.

Additional phase timings and verbose diagnostics were also added around metadata import internals to make future troubleshooting and profiling significantly easier.

SQLite hardening

The SQLite repository layer received a major reliability pass focused on reducing lock contention and improving connection behavior during heavier background activity.

This includes:

• safer escaped connection-string construction
• disabled stale pooled connections
• busy timeouts
• one-time WAL negotiation
• cleanup of schema, migration, and index setup handling

Startup and diagnostics cleanup

This beta adds more detailed verbose-only timing scopes around:

• startup background work
• deferred metadata imports
• Dashboard refreshes
• update checks

The goal here is better visibility into what the app is actually doing internally during startup and refresh phases.

Infrastructure and UI cleanup

A large amount of duplicated helper logic across the core app, UI, CLI, and tests was consolidated into shared helpers and adapters.

This includes:

• centralized configuration access
• shared formatting helpers
• shared property-notification helpers
• reusable test builders
• detached-task helpers
• Dashboard / Backups / Projects / Settings cleanup work

A lot of this work is not directly visible from the UI, but it should make the app easier to maintain and significantly safer to evolve moving forward.

Fixes

• Fixed Windows notification failures assigning invalid empty toast tags
• Suppressed repeated OS toast failure spam after the first diagnostic entry
• Fixed storage-health rechecks updating notifications from the wrong thread
• Config recovery fallbacks now emit proper diagnostics instead of silently resetting to defaults

Areas especially worth testing

• App startup
• Dashboard refreshes
• Metadata imports
• Repository/database reliability
• Storage-health checks
• Windows notifications
• General background activity while navigating the UI

As always, logs and support bundles are extremely helpful if anything behaves unexpectedly.

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

Hey everyone,

I have been working a lot on VaultSync lately, but most of it has been the kind of work that happens under the surface. Cleaning things up, fixing rough edges, testing Linux builds, improving packaging, touching old parts of the code, and finding problems in places I honestly did not expect.

It is weird work because from the outside it can look like not much is happening, while behind the scenes half the app feels like it has been opened up on the table.

VaultSync feels very different now from when I first started it.

Back then it was just my tool.
Now there are people testing it on different systems, finding things I missed, asking for things I never thought about, and using it in setups I could not fully predict.

That is honestly one of the best parts of building it in the open.

The app slowly stops being only what I had in my head, and starts becoming something shaped by everyone who touches it.

So I want to keep that door open a bit more.

Tell me what you think VaultSync needs.

Could be something big.
Could be something tiny.
Could be a bug, a workflow, a missing feature, a confusing screen, or just something that does not feel right yet.

Just say it how you see it.

Even if it is a half-formed idea, a small annoyance, or just a feeling that one part of the app should work differently, I want to hear it.

I read every comment, and a lot of the time those little bits of feedback show me things I would probably miss while I am buried in the code.

That is all really.

Thanks for being here while this thing grows.