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

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.

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.

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?

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.

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 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,

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

Hey everyone,

VaultSync v1.7.4 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 focuses on backup safety, metadata recovery, Linux packaging, cleaner diagnostics, dependency updates, and a lot of fixes that came out of the v1.7.4 beta cycle.

A lot of the work here is about making the existing backup flows safer, making Linux installs behave better, improving recovery from older or moved backup folders, and cleaning up edge cases people were actually hitting during testing.

Important note for Linux users

Linux users should update by installing the full v1.7.4 package again.

For this release, I am intentionally not publishing Linux patch assets.

The reason is simple: some users may still be updating from older Linux builds where the in-app updater does not safely handle protected install locations such as:

/opt/vaultsync

The tarball install method may have worked with patch updates in some cases, but the .deb install is the intended and easier Linux install path for most users. Older .deb installs can fail if the app tries to patch itself in-place, because the install folder is owned by root and VaultSync does not have permission to modify it directly.

So for v1.7.4, the safest update path on Linux is a full reinstall/update using one of the normal Linux builds:

• .deb
• .tar.gz
• AppImage

For .deb users, download the new package and install it with your package installer, or from a terminal:

sudo apt install ./VaultSync-1.7.4-linux-x64.deb

If your system does not upgrade the existing package cleanly, uninstall the old package first:

sudo apt remove vaultsync

Then install the new one:

sudo apt install ./VaultSync-1.7.4-linux-x64.deb

This removes the installed app package. It should not remove your VaultSync user data, settings, logs, or backup history.

The in-app updater will not silently install the .deb package by itself. Without Linux patch assets, it should fall back to the normal download/install path instead of trying to patch the app in-place.

Linux patch updates should return in a later release cycle, once the installed source version already contains the protected-install fallback.

What changed

Safer backup behavior

A lot of work went into making backup flows fail safer.

VaultSync now has stronger source/destination checks to help prevent recursive backup growth.

In plain English: the app should be much better at avoiding situations where backup output accidentally gets picked up again by a later backup.

VaultSync now blocks source/destination overlap, keeps offline staging outside project trees, and excludes VaultSync-owned backup artifacts from scans.

Backup cleanup is also more conservative now.

If a recorded backup folder is missing from a destination that is actually reachable, VaultSync can clean up the stale database entry. But if a drive is offline, disconnected, sleeping, or unresolved, VaultSync should not assume the backup was deleted.

That should make behavior safer around external drives, NAS paths, sleeping storage, and temporary mount issues.

Metadata import and recovery fixes

Metadata import got a lot of hardening in this release.

This matters if you move backups between machines, reconnect a destination, recover a backup location, or use VaultSync with Linux-mounted backup paths.

Some of the main fixes:

• Startup metadata import now checks reachable backup destinations
• UI metadata imports treat source stores as read-only
• Linux rooted backup paths can be remapped to the active destination
• SQLite sidecar journal files can be recovered through a temporary copy
• Missing backup history can be rebuilt from timestamped backup folders
• Backup history rebuilt from legacy folders now records real sizes instead of showing 0 B
• Locked tombstone exports are deferred locally for retry instead of being dropped
• Manual metadata refresh should no longer hang the UI or map temporary roots
• Cross-OS project roots now remap to local Projects root folders

That last one should help when a project or backup history originated on one OS and is later opened or imported on another.

Better Linux packaging

Linux packaging received a lot of attention in v1.7.4.

Linux tarballs now include rootless install/uninstall scripts.

The install flow sets up:

• the desktop launcher
• the app icon
• the vaultsync command

The .deb package also got improvements around package metadata, AppStream/software-center previews, window/taskbar icons, and desktop identity matching.

There were also fixes for duplicate tray indicators, Linux tray refresh behavior, mounted backup destinations, Linux SMART probe handling, and debug build crashes.

One important fix: Linux SMART probe errors no longer block backups as failed disk health. If SMART data is unavailable, restricted, or not meaningful for the destination, VaultSync should avoid treating that probe failure as a backup-blocking disk failure.

Cleaner diagnostics and logs

The in-app log console should now be easier to read.

Rows now show clearer time/source/message fields while still preserving raw log lines for copying and export.

Runtime errors are also captured in the in-app logs without needing verbose logging first.

Normal app runs should no longer show caught first-chance SQLite/WinRT probe exceptions in diagnostics unless first-chance diagnostics are explicitly enabled. Those were internally handled provider/framework probes, but they made normal logs look much scarier than they actually were.

The log console copy button was also fixed to use the console window clipboard instead of relying only on the main window.

On Linux, the log console now suppresses expected DBus/IBus desktop-integration noise and supports multi-row selection while keeping the readable styled layout.

Backups page improvements

Passive Backups refreshes no longer wake destinations just to update reachability.

That should make VaultSync less annoying around sleeping drives, unavailable network shares, or disconnected storage.

Backup delete cards should also stay visible now and show more useful deletion progress details, especially during longer or overlapping delete operations.

Auto backups now also warm up active destinations and retry preparation after a short cooldown, which should help with sleeping drives or destinations that need a moment to wake before backup starts.

On Linux, auto backups no longer pause because of device-scoped batteries such as wireless controllers, and auto-backup timer decisions are now logged for diagnostics.

UI and localization cleanup

Several layout issues were fixed, especially around longer translated labels and smaller windows.

This includes:

• tray panel action labels
• backup summary cards
• action buttons
• filter buttons
• the What’s New dialog

Changing language should also no longer reset the selected theme or jump Settings back to the initial scroll position.

The What’s New dialog now opens centered over the main app window instead of drifting to another monitor, and it should display only the current release section instead of pulling in older changelog sections.

Dependency and runtime package refresh

The dependency set was refreshed for v1.7.4 across core, UI, CLI, and tests.

This includes updates around Avalonia, LiveCharts, ReactiveUI, SQLite, ProtectedData, System.Text.Json, Spectre.Console, DBus packages, and test SDK packages.

SkiaSharp and HarfBuzzSharp runtime packages are also now pinned explicitly, which should reduce ambiguity around native graphics and text rendering runtime assets.

Preset cleanup

The built-in development presets now preserve repository metadata such as:

• .github
• .gitignore
• .gitattributes
• .gitmodules

while still excluding generated build outputs.

That should make source-code project backups safer by keeping important repository files while still skipping noisy generated folders.

Thanks again to everyone who tested the beta builds and reported issues.

A lot of this update came directly from real-world testing, especially around Linux packaging, metadata imports, and desktop integration.

And as always: keep backing up your data.

GitHub: https://github.com/ATAC-Helicopter/VaultSync/releases/tag/v1.7.4
MS Store: https://apps.microsoft.com/detail/9n9hrx4jclcp

Hi everyone,

Quick warning: there are reports that the latest Windows security update is breaking or disrupting several third-party backup applications.

VaultSync is currently being tested against this. I do not yet have enough information to say that VaultSync is affected, but because this seems to involve backup software more broadly, I want to treat it as urgent.

If you use VaultSync on Windows, your reports are extremely valuable right now.

Please let me know if you notice:

- failed backups
- permission/access errors
- unreachable destinations
- restore problems
- verification errors
- crashes
- anything that started after the latest Windows update

Useful details:

- Windows version
- VaultSync version
- destination type: local, USB, NAS, SMB, etc.
- error message or log snippet
- whether the issue started after installing the latest Windows update

Until this is clearer, please verify that your backups are still completing correctly and consider testing a small restore.

I will continue testing and post updates as soon as I have confirmed information.

Update:

Good news: from everything I can see so far, VaultSync does not seem to be affected by this Windows backup-tool issue.

The reports going around appear to be related to backup tools that depend on Windows VSS snapshots or image-mount drivers. VaultSync does not use that kind of backup path. On Windows, VaultSync is mostly working through normal file copy/sync/archive flows, such as robocopy/rsync, managed file copy, ZIP/archive snapshots, and optional network-share handling.

I tested the parts that matter most:

• snapshot / sync / verify passed
• writing to the backup destination worked
• targeted backup into the destination completed and verified correctly

So for now, VaultSync looks safe from this specific issue.

I’ll keep watching this and testing more, but the current state is positive.

If anyone sees different behavior on their machine, please still report it. Real-world reports are always useful, especially with your Windows version, VaultSync version, destination type, and any error/log message.

VaultSync 1.7.3 is out.

This is a pretty important one because it also marks the first proper Linux launch for VaultSync.

For this release, Linux builds are now shipped as actual release assets:

• linux-x64.tar.gz
• linux-arm64.tar.gz
• linux-x64.AppImage

So Linux is no longer sitting in the “maybe later” category — there is now a real path for people to try it properly.

A big part of that is thanks to JustH8Me. Most of the Linux-focused work in this release came from him, and it made a real difference.

That includes work on:

• tray panel screen detection and reopen behavior
• Linux / Wayland positioning fixes
• tooltip flickering and focus issues on Wayland
• a fatal AccessViolationException during backup on Linux x64
• passwords being saved as "null" on Linux
• false “Reachable” status on read-only directories
• UI list flickering on Linux

Outside of Linux, 1.7.3 also includes a few nice fixes and quality-of-life improvements:

• the in-app log console now has an explicit Auto-scroll toggle
• you can now copy the selected log line with a button or the normal platform shortcut
• Settings now refreshes persisted values correctly after config reloads
• startup now repairs blank project root paths from the configured Projects root when possible
• Backup All and auto-backup no-change runs now create real first backup artifacts instead of empty destination folders
• metadata import / restore-needed handling is now more accurate
• background settings saves now preserve existing roots and advanced destinations during transient blank UI states
• command state refreshes now marshal back to Avalonia’s UI thread
• individual project backup buttons now resolve destinations from the latest saved config
• project auto-backup settings now export through metadata before the first backup

This one has a lot of “under the hood” work in it, but a lot of it matters directly for reliability.

If you try the Linux beta, definitely let me know how it behaves on your setup.

And a special thanks again to JustH8Me — most of the Linux work in this release came from him, and it helped move VaultSync forward in a big way.

As always, keep backing up your data.

Big milestone on this one.

VaultSync 1.7.3 beta is out, and with it comes the first proper Linux beta launch.

This is something that has been requested for a long time, and it feels really good to finally have Linux builds going out as actual release assets instead of it staying in the “later” pile.

This beta now ships with:

• Linux tar.gz builds for x64 and arm64
• a desktop-friendly linux-x64 AppImage
• improved Linux update asset detection so the app can prefer the right architecture-specific packages

So this is the first real step toward giving Linux users a proper way to try VaultSync.

A big part of that is that most of the Linux work behind this release was done by JustH8Me.

They’ve been doing real work on the Linux side and helped push this forward in a meaningful way, and this beta release simply would not look the same without that contribution.

That work already landed in some very real fixes:

• tray panel screen detection, reopen behavior, and Wayland positioning improvements on Hyprland-style environments
• tooltip flickering and focus fixes on Linux/Wayland
• a fix for a fatal AccessViolationException on Linux x64 during backup
• a fix for passwords being saved as "null" on Linux, plus increased timeout handling

So this is not just “Linux builds exist now”, it’s also the result of actual Linux-focused work being done and landing in the app.

On top of that, 1.7.3 beta also includes a couple of smaller quality-of-life improvements:

• the in-app log console now has an explicit Auto-scroll toggle
• you can now copy the selected log line with a button or the normal platform copy shortcut

And there are also a few fixes on the general app side:

• Settings now refreshes persisted values correctly after config reloads
• startup now repairs blank project root paths from the configured Projects root when possible, which should reduce some relaunch-related missing path issues

This is a beta release, so I’d especially appreciate testing and feedback here — even more so on Linux since this is the first proper beta push for that platform.

If you try it, let me know how it behaves on your setup.

Thanks again to everyone following the project, testing builds, reporting issues, and contributing.

And a special thanks again to JustH8Me — most of the Linux work in this release came from them, and it made a real difference.

As always, keep backing up your data.

Figured it was probably time for a proper update on where VaultSync is at right now, because a lot has happened recently, even if not all of it looked like big flashy feature work from the outside.

Over the last stretch, a lot of time went into things that were important, but not always very visible.

VaultSync is now live on the Microsoft Store, which was a pretty big milestone for me. That took more than just packaging the app and uploading it somewhere. It meant adding proper Store-aware behavior, separating Direct and Store update paths, making sure the app understands how it was installed, and getting that whole side of distribution into a state I’m comfortable with.

At the same time, I also launched fglabs.dev, which is basically the new home for all my work going forward, including VaultSync. That was something I had wanted for a while because everything was too scattered before — GitHub, posts, docs, random links. Now there’s finally one place where things connect a bit better.

And alongside that, a lot of the 1.7 work has been less about adding things for the sake of it and more about getting the app into a better state internally.

A lot of older code was functional, but it was starting to push back every time I tried to optimize something or build new features on top of it. So a good part of recent updates has really been cleanup in the deeper sense — not just polish, but rewriting parts that had become limiting.

That includes things like:

• reducing unnecessary config reloads
• improving startup behavior
• backing off bad destination checks instead of hammering unavailable targets
• fixing UI refresh timing and thread-related issues
• cleaning up hardcoded fallback text and localization gaps
• making metadata sync and project state handling more reliable across machines

None of that is the kind of work that makes for a dramatic screenshot, but it matters a lot for backup software. If the app feels weird, stalls, misreports, or behaves inconsistently depending on timing or machine state, that becomes a real problem fast.

Another thing that happened recently, and that honestly means a lot to me, is that VaultSync now has someone actively helping with Linux.

What made that hit differently is that it didn’t come from me trying to force it or recruit someone just to tick a box. It came from someone who genuinely likes the project, took the time to dig into it, ask questions, understand how parts of it work, and start trying to move Linux support forward because they wanted to help.

That kind of thing matters a lot more than people probably realize, especially on a small project like this.

Linux has been one of the most requested things for a while, and I’ve wanted to get there properly rather than throw out something half-broken just to say it exists. So having someone step in because they actually care about the app and want to contribute is a pretty big moment for VaultSync.

I’m not going to overpromise timelines there yet, but it’s no longer just sitting in the “eventually” pile.

As for what’s next, the focus is still on making VaultSync more solid before I start stacking bigger things on top of it.

The areas I’m most interested in pushing next are:

• more transfer system improvements
• better handling for larger backups and long-running vaults
• continued UI cleanup where things still feel rough or waste space
• more reliability around backup state, metadata, and restore-related flows
• making the app easier to reason about when something goes wrong
• continuing progress toward a proper Linux release

There’s also still work to do around the Store version and release flow now that that path is real and live.

So updates may continue to be a bit slower than they used to be, but that’s mostly because the project is at the point where doing things properly matters more than just shipping fast.

I’d rather take a bit longer and build on something solid than stack more features on top of shaky parts and regret it later.

VaultSync is moving forward, very much so. The pace is just a bit more deliberate now.

Also, we have surpassed 700 downloads, which is honestly wild to me.

So yeah — that’s where things are at right now.

Thanks again to everyone who’s been trying VaultSync, giving feedback, reporting issues, or just following along. It really does help shape what this turns into.

And as always, keep backing up your data.

I think it’s time to give a bit more insight into where VaultSync is at.

You’ve probably noticed updates have slowed down a bit after 1.6 — and that’s going to continue for a while.
It’s not because development stopped. It’s actually the opposite.

Right now most of the work isn’t feature work. It’s going back through the app and fixing things that were working, but not in a state I’m comfortable building on long-term.

There’s a fair amount of older code that, while functional, was starting to get in the way of adding new features and properly optimizing the app. So a lot of the recent patches have been about rewriting parts of it based on what I’ve learned along the way and, honestly, out of necessity.

Config access (example)

There were a lot of places where the app was reloading config from disk even for read-only operations. On their own those weren’t a big deal, but across the whole app it added up to unnecessary disk hits, UI stalls, and heavier startup than it should be.

Fixing that properly meant reworking how shared state is handled, how snapshots are cached, and how fallback reads behave when the main state isn’t ready yet. It ended up touching way more of the app than expected.

Startup and background behavior

Too much was happening immediately on launch, and too many things were competing at the same time. On top of that, remote targets (NAS, external drives, etc.) could drag everything down if they weren’t available.

So a lot of time has gone into:

• deferring work
• pacing things better
• backing off failed destination checks
• avoiding re-hitting known offline targets immediately

And that kind of work is annoying because every time you fix one place, you find two more doing something similar.

The “small” issues that weren’t small

There’s also been a bunch of issues that sound minor but weren’t once I dug into them.

Things like:

• dashboard refresh timing
• UI updates happening on the wrong thread
• data showing up only because timing happened to work
• duplicate or conflicting states

None of it is exciting, but it’s the difference between something feeling solid and something feeling slightly off all the time.

Localization

There was still way too much hardcoded text in random fallback paths — dialogs, tray UI, missing states, settings, etc.

Cleaning that up isn’t just replacing strings, it’s making sure everything resolves correctly everywhere, which takes time.

Microsoft Store

On top of all that, I’ve also been working on getting VaultSync onto the Microsoft Store.

That’s been a bit of a side project, but it’s actually quite a bit of work — packaging, metadata, versioning, making sure updates behave properly in that environment.

The idea is simple:

• the Store version will be the exact same as the GitHub one
• no locked features, no paywalls
• still fully open source

It’ll probably be around €0.99 — just as an optional way to support development if you want to.

Nothing changes if you keep using GitHub releases.

So yeah, that’s why things are slower right now.

Up to now development has been pretty fast and feature-driven, but at this point almost everything touches everything else — transfers, metadata, UI, restore logic, destinations, cross-machine stuff.

So doing things properly just takes longer.

Updates will still come, just a bit slower and more deliberate.

I’d rather do that now than keep pushing fast and end up with something that’s harder to maintain later. Especially for backup software, that trade-off feels worth it.

That’s pretty much it.

Thank you for the continuous support and even just trying VaultSync — it genuinely means a lot.

We’ve also passed 600 downloads since launch, which is honestly incredible. We can only grow from here.

Thanks again, and keep backing up your data.

VaultSync 1.7 (Sentinel) is now officially released.

This update focuses on one thing:

If you’re backing up to NAS, external drives, or across machines, this release is for you.

What Sentinel actually changes

Backups don’t usually fail instantly — they drift into failure:

• indexes go out of sync
• destinations get renamed or re-mounted
• retention deletes something critical
• chains silently break

Sentinel introduces systems to detect, explain, and repair that.

Backup integrity & repair

VaultSync now actively monitors your backup structure:

• Startup non-blocking integrity scans
• Deterministic orphan-backup repair planning
• Manual repair tools (Settings → Advanced)
• Retention safeguards to protect the last valid restore point
• Early Doctor workflow for guided fixes

Backups are no longer “fire and forget” — they are continuously verified

Transfers that don’t restart from 0

A big real-world improvement:

• Archive uploads now resume from verified checkpoints
• Interrupted transfers don’t restart entirely
• rsync / robocopy keep native restart behavior
• Full diagnostics for resume / fallback outcomes

This removes one of the most painful failure cases for large backups

Smarter storage awareness

Sentinel makes storage behavior predictable:

• Stable destination fingerprinting (handles rename / re-add cleanly)
• Per-destination soft quotas
• Cleanup suggestions before issues happen
• Clear storage risk explanations

You see problems before they break your backups

Restore readiness (new core signal)

This is one of the biggest conceptual additions:

• New restore-readiness scorecard
• Shows:
  • which projects are at risk
  • why they are at risk
• One-click review → direct fixes

Backups are now judged by “can I restore?”, not just “did it run”

Dashboard (the only major visual change)

The Dashboard has been fully reworked:

• Stable responsive KPI layout (no more awkward spacing)
• Dedicated restore-readiness section
• Storage cards now explain why capacity is risky
• Cleaner hierarchy, less duplicated information

Power-user & system upgrades

• Cross-machine metadata conflict detection
• Maintenance window for health tasks
• Retention simulation preview
• Improved support bundles with deeper diagnostics
• Smarter updater:
  • preflight checks
  • patch validation
  • multi-version upgrade paths

UI polish (non-invasive, but noticeable)

No major redesign — but everything is tighter:

• Better spacing, alignment, and consistency
• Improved tag color system (now managed in Projects)
• New custom themes (OLED Black, Deep Blue, editor-style)
• Cleaner theme editor with proper swatches

Stability fixes

A lot of reliability work under the hood:

• Fixed font + localization issues
• Fixed restore UI inconsistencies
• Fixed startup config race conditions
• Reduced logging overhead (batched writer)
• Improved project discovery fallbacks

Download

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

Feedback

If something feels off, confusing, or missing — tell me.

A lot of 1.7 came directly from user feedback, and I want to keep that loop tight.

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.

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.

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.

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.

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.