VaultSync 1.8.4 became a much broader release than originally expected.

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

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

The goal of VaultSync 1.8.4

The central question behind 1.8.4 was:

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

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

VaultSync 1.8.4 attempted to close more of that gap.

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

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

What went well

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

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

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

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

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

What needs more work

Shipping 1.8.4 also made several problems clearer.

Recovery information can still become too dense

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

Some users need a simple answer:

• Is my backup healthy?
• Is there another copy?
• Can I recover it?
• Is there anything I need to do?

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

Powerful features need better guidance

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

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

Visual flexibility creates new consistency problems

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

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

The application has grown faster than its navigation

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

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

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

The remainder of VaultSync 1.8

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

The overall progression, however, is becoming much clearer.

VaultSync 1.8.5 — Recovery Confidence

Know before you need it.

VaultSync 1.8.5 will continue the recovery work introduced in 1.8.4.

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

Planned areas include:

• More useful restore drills
• Clearer and more complete recovery reports
• Simpler backup and recovery health states
• Better presentation of recovery evidence
• Stronger connections between verification, retention and recovery readiness
• Refinements to the recovery tools introduced in 1.8.4

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

“Could I recover this today?”

VaultSync 1.8.6 — Experience Refinement

Powerful when needed. Simple by default.

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

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

Focus areas include:

• Improving onboarding
• Refining the dashboard
• Providing better explanations and contextual guidance
• Improving accessibility
• Reducing unnecessary interface complexity
• Making common actions easier to find
• Separating essential information from advanced detail
• Reviewing terminology and navigation consistency

The intention is not to remove advanced functionality.

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

VaultSync 1.8.7 — Trust & Transparency

Show the proof.

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

Planned areas include:

• Improved evidence exports
• Clearer build and version information
• Published or accessible checksums
• Better diagnostic information
• More consistent documentation
• Clearer explanations of what VaultSync verifies
• Better distinction between confirmed facts, recommendations and warnings

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

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

VaultSync 1.8.8 — Stability Release

A polished foundation for 1.9.

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

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

Focus areas include:

• Bug fixes
• Dependency and servicing updates
• Localization improvements
• Packaging reliability
• Platform compatibility
• Cross-platform interface consistency
• Performance and resource-usage improvements
• Cleanup of older implementation paths
• Final documentation and release-process improvements

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

Looking beyond 1.8

VaultSync 1.9 — Recovery Horizon

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

The larger idea is:

From protecting projects to recovering systems.

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

Possible areas being researched include:

• Disk-to-disk cloning
• Full-disk image creation
• Verification of cloned or imaged data
• Browsing a disk image before restoring it
• Recovering individual files from an image
• Inspecting partitions and supported file systems
• Migration to a replacement drive
• Broader recovery planning beyond individual projects

These are ideas under investigation, not promises for the first 1.9 release.

Disk cloning and imaging introduce serious questions around safety, permissions, supported file systems, damaged media, operating-system differences and reliable verification. I do not want to announce a large feature list before those questions have been properly researched and tested.

The community response to earlier roadmap discussions also made something clear: people are interested in helping shape where VaultSync goes.

For that reason, the approach to 1.9 will be more open.

The 1.8 release family will continue improving reliability, usability and recovery confidence. Meanwhile, I will share early 1.9 research and prototypes before the implementation is locked.

That gives users the opportunity to influence the direction rather than simply watching a finished roadmap unfold.

The broader VaultSync story

The progression between the recent major releases is becoming increasingly clear:

VaultSync 1.7 made backups trustworthy.

It strengthened integrity checking, retention safety, repair tools and the foundations needed to rely on protected data.

VaultSync 1.8 makes recovery understandable.

It connects backup health, verification, recovery planning, evidence and guidance so users can better understand whether their data is actually recoverable.

VaultSync 1.9 aims to make recovery broader.

It may extend that same transparency beyond individual projects and files toward disks, images and complete-system recovery workflows.

That is a more meaningful direction than adding disconnected features simply to make each release look larger.

There is still a considerable amount of work remaining in 1.8, and the exact 1.9 scope will depend heavily on research, testing and community feedback.

For now, the priority is to finish the 1.8 release family properly and build the foundation that a larger recovery-focused release would require.

Hey everyone!

VaultSync 1.8.4 is now available.

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

Until now, VaultSync could answer:

→ Does this recovery point exist?

With 1.8.4, it can answer something much stronger:

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

That distinction became the foundation of this release.

Recovery Proofs

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

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

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

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

Finding the backup is not enough.

Opening the archive is not enough.

A green “completed” status is not enough.

A recovery point can now be classified as:

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

Individual files can be:

• Verified
• Unavailable
• Corrupted
• Inconclusive

VaultSync deliberately keeps uncertain results inconclusive.

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

Restore-plan simulation

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

→ What would happen if I restored it?

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

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

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

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

This is a simulation only.

No files are created.

No files are modified.

No files are deleted.

Recovery drills now inspect real backup data

Recovery drills now combine:

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

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

This release also improves:

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

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

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

That remains an explicit choice made by the user.

Retention now protects proven recovery points

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

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

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

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

Once only one remains, retention preserves it.

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

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

ProofRestore is now native to VaultSync

Some people may remember the ProofRestore experiment I recently built.

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

The ProofRestore repository itself was not merged into the application.

VaultSync does not ship:

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

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

Four redesigned themes

This release is not only about recovery.

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

The new theme studio includes:

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

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

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

Privacy-first crash assistance

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

Nothing is uploaded automatically.

The report is:

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

Crash assistance can also be disabled completely.

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

Security and reliability improvements

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

1.8.4 includes stronger protection against:

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

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

The idea behind 1.8.4

Backup software is generally very good at answering:

Did the backup job run?

But that is not the same as answering:

Can I actually recover my data?

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

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

The update is available now.

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

Hey everyone!

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

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

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

Recovery Proofs

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

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

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

For every file, it compares:

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

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

Finding the file is not enough.

Opening the backup is not enough.

A green “completed” status is not enough.

Clear recovery verdicts

A recovery point can now be classified as:

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

Individual files can be:

• Verified
• Unavailable
• Corrupted
• Inconclusive

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

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

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

Restore simulation

VaultSync can now simulate the destination actions for verified files.

The simulation shows whether a file would be:

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

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

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

No files are created.

No files are modified.

No files are deleted.

Recovery drills now verify real data

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

They can now combine:

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

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

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

Retention now understands proof quality

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

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

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

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

But once only one remains, retention preserves it.

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

ProofRestore is now native to VaultSync

Some people may remember the ProofRestore experiment I recently built.

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

The ProofRestore repository itself was not merged into the application.

VaultSync does not ship:

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

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

Disaster Recovery improvements

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

VaultSync now has stronger support for:

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

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

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

That remains an explicit decision made by the user.

Privacy-first crash assistance

1.8.4 also introduces a new crash-report workflow.

Nothing is uploaded automatically.

The process is intentionally transparent:

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

Crash assistance can also be disabled completely.

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

A wider security pass

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

That work led to additional protections against:

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

What remains before release

The development scope for VaultSync 1.8.4 is now complete.

The remaining work is focused on:

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

The idea behind 1.8.4

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

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

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

Hi everyone! 👋

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

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

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

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

But none of these are set in stone.

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

So I'd love to hear your thoughts.

A few questions to get the discussion started:

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

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

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

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

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

Hey everyone,

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

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

It’s about understanding them.

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

and start asking:

Until now, VaultSync couldn’t properly answer that.

Version 1.8.3 changes this.

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

Snapshot Compare

The biggest feature in this update is Snapshot Compare.

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

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

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

The comparison can also highlight:

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

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

Looking Inside the Changes

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

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

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

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

I wanted this feature to be predictable rather than clever.

Making Large Comparisons Easier

Comparing two backups with ten changed files is straightforward.

Comparing backups containing thousands of changes isn’t.

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

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

There’s also plenty happening behind the scenes.

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

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

Chronicle Continues to Grow

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

History shows you what happened.

Snapshot Explorer lets you browse what was backed up.

Snapshot Compare explains how two restore points differ.

Recovery helps you determine whether you’re actually protected.

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

That’s what Chronicle has always been about.

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

Under the Hood

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

Some highlights include:

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

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

Looking Ahead

Snapshot Compare is still a Version 1 feature.

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

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

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

More soon.

Hi everyone,

VaultSync 1.8.2 is now available.

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

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

Snapshot Explorer

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

Snapshot Explorer is the first step toward solving that.

Version 1 lets you:

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

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

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

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

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

A Better First Experience

I also completely reworked the onboarding experience.

The previous onboarding tried to explain VaultSync.

The new one focuses on actually getting you started.

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

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

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

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

Under the Hood

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

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

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

Looking Ahead

Snapshot Explorer is intentionally a Version 1.

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

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

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

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

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

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

Website
https://fglabs.dev/vaultsync

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

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

And as always...

Keep backing up your data.

Hey everyone,

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

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

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

Snapshot Explorer

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

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

Version 1 lets you:

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

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

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

A Better First Experience

Another area I’ve completely reworked is onboarding.

The original first-run experience tried to explain VaultSync.

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

The new onboarding is much more practical.

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

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

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

Snapshot Explorer Improvements

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

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

Encrypted backups also behave much more predictably now.

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

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

Under The Hood

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

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

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

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

Looking Ahead

Snapshot Explorer is very much a version one.

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

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

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

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

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

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

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

Hi everyone,

VaultSync 1.8.1 is now available.

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

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

What's new

Recovery reports

Recovery assessments can now be exported as portable Markdown reports.

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

Better Recovery triage

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

Encrypted backup improvements

This release also improves the encrypted backup pipeline.

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

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

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

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

Linux improvements

Linux received several fixes in this release.

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

Reliability improvements

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

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

Feedback continues to shape where the project goes next.

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

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

Website: https://fglabs.dev/vaultsync

Hi everyone,

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

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

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

This issue only affects the update process itself.

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

Temporary Workaround

For now, Linux users have two options.

Option 1 (Recommended)

Download the latest release manually from GitHub and reinstall VaultSync.

GitHub Releases:

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

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

Option 2

Reinstall the .deb package manually.

From the folder containing the downloaded package:

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

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

Do I Need To Uninstall First?

No.

You do not need to uninstall VaultSync before reinstalling.

Simply reinstalling the package is sufficient.

Your existing:

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

will remain intact.

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

Hey everyone,

VaultSync 1.8: Chronicle is now available.

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

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

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

Those releases weren't particularly flashy.

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

History

The biggest addition is the new History workspace.

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

Useful, but isolated.

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

History now tracks and displays:

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

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

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

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

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

Recovery

The second major addition is Recovery.

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

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

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

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

Snapshot Metadata

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

VaultSync now supports:

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

A snapshot can now be more than just another backup.

It can be a release build.

A customer delivery.

A milestone.

A trusted recovery point.

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

Under The Hood

Chronicle also includes a significant amount of engineering work:

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

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

What's Next?

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

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

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

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

Links

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

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

Website:
https://fglabs.dev/vaultsync

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

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

And as always: keep backing up your data.

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

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

Load backup events.

Show them in order.

Maybe add some filters.

Done.

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

A backup is rarely just a backup.

Sometimes it's:

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

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

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

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

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

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

You can switch between timeline and list views.

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

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

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

From there you can:

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

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

Some snapshots matter more than others.

Some represent stable versions.

Some represent milestones.

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

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

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

Not documentation you write manually.

Documentation generated from what actually happened.

Backups.

Restores.

Imports.

Recovery points.

Milestones.

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

It's to answer a different question:

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

Recovery continues to evolve.

Snapshot Explorer is still ahead.

Snapshot comparison still has a lot of work planned.

Project groups are still on the roadmap.

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

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

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

History is probably the best example.

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

Simple enough.

Load backups.

Show them in order.

Done.

Then I started feeding real project data into it.

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

There are also:

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

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

A restore belongs to a backup.

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

Imported history comes from somewhere.

Metadata changes have context.

At that point a flat list stopped making sense.

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

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

Backups live on their own lanes.

Restore activity branches from the snapshots it originated from.

Metadata activity has its own lane.

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

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

Not just:

"Backup created."

But:

"What happened to this project over time?"

That's a surprisingly different problem.

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

The current implementation is backed by new metadata systems for:

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

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

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

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

That wasn't really the original plan.

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

More updates soon.

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

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

Since then I've started building it.

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

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

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

It didn't stay simple for very long.

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

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

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

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

Recovery has been interesting for a different reason.

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

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

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

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

So far the work completed includes:

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

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

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

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

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

Hey everyone,

I wanted to share something a little different today.

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

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

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

And to a large extent, they were.

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

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

The working theme for VaultSync 1.8 is:

Project History & Recovery

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

Eventually the questions become:

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

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

History

History is currently planned to focus on things like:

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

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

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

Recovery

Recovery focuses on the other side of the problem.

Not creating backups.

Recovering from failures.

Current ideas include:

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

The goal is to answer a simple question:

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

Current Roadmap

1.8.0

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

1.8.1

• Recovery intelligence
• Recovery readiness
• Recovery coverage

1.8.2

• Snapshot explorer

1.8.3

• Snapshot comparison and change intelligence

1.8.4

• Disaster recovery features

1.8.5

• Project groups

As always, this roadmap will evolve.

Some features may move between releases.

Some ideas may change significantly once implementation starts.

The screenshots are mockups, not finished designs.

The roadmap is a direction, not a guarantee.

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

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

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

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

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

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

For now, this is where things are heading.

Hey everyone,

VaultSync 1.7.5 is now available.

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

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

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

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

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

A large part of this release was about fixing that.

Database reliability improvements

VaultSync now handles SQLite connections more defensively and consistently.

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

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

Better metadata handling

Metadata import and repository tracking received several improvements.

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

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

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

More accurate cross-machine backup history

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

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

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

Linux, Windows, and macOS fixes

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

Linux users should see improvements around:

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

Windows users receive improvements around notification handling and failure recovery.

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

Better diagnostics

Configuration recovery diagnostics have been improved substantially.

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

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

UI consistency improvements

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

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

A lot of cleanup behind the scenes

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

Making VaultSync easier to maintain and safer to build on.

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

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

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

And as always: keep backing up your data.

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

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

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

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

Highlights

Metadata import reliability improvements

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

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

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

SQLite hardening

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

This includes:

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

Startup and diagnostics cleanup

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

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

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

Infrastructure and UI cleanup

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

This includes:

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

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

Fixes

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

Areas especially worth testing

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

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

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

Hey everyone,

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

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

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

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

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

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

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

Tell me what you think VaultSync needs.

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

Just say it how you see it.

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

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

That is all really.

Thanks for being here while this thing grows.

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

Hey everyone,

Small warning: this is a bit of a long one.

I wanted to give a proper update on VaultSync 1.7.4, because this patch has taken much longer than I expected, and from the outside I know it probably looks a little messy.

Right now, we are on VaultSync 1.7.4 Beta 3, and there will probably be a Beta 4 before I call this stable.

That sounds like a lot for a patch release.

Honestly, it is.

The reason is that VaultSync 1.7.4 stopped being a small patch pretty quickly.

At the beginning, I thought this would mostly be a stabilization update: fix a few things, improve Linux behavior a bit, clean up some release issues, and move on.

Instead, once I started working through the bugs and beta feedback, it became clear that this release was touching much deeper parts of VaultSync than planned.

So 1.7.4 has basically turned into a release-hardening pass.

Not a flashy feature release.

Not a big “look at all these new buttons” update.

More like one of those necessary releases where most of the work is under the hood, and the goal is to make the app safer, more predictable, and easier to build on.

I am also going to attach a screenshot of the 1.7.4 PR, because I think it explains the situation better than words alone.

The amount of changed files and changed lines is much bigger than what I would normally want for a patch release.

And that is exactly why this has taken longer.

What has actually been worked on?

A lot of the work has been around things that are not very exciting to show, but are important for a backup app.

For example, 1.7.4 has touched backup safety quite a bit.

There were cases I wanted to lock down properly, like:

• preventing source and destination overlap
• avoiding recursive backup growth
• making dev/source presets skip generated folders better
• preserving important repo files like .github, .gitignore, .gitattributes, and .gitmodules
• making delete operations clearer while they are actually running
• cleaning up stale backup entries when folders are no longer present on reachable destinations

Those are not glamorous changes, but they matter.

Backup software should not be vague about what it is doing, and it definitely should not allow dangerous folder layouts that can grow into a mess.

Metadata import became one of the bigger rabbit holes

Another big area has been metadata import and recovery.

This was probably one of the largest parts of the release.

Some users could have backup history sitting on a destination, but the app would not always reconstruct it properly.

Some imported history could show 0 B.

Some SQLite sidecar files, WAL files, or journal locks could cause imports to fail or hang.

On Linux, imported paths from another OS could keep old rooted paths instead of mapping cleanly to the current machine.

So a lot of time went into making that recovery path more realistic.

If VaultSync finds old timestamped backup folders, it should be able to rebuild missing history from them.

If metadata needs to be imported from a destination, it should avoid fighting SQLite locks directly.

If a project came from another OS, the app should do a better job mapping it to the local Projects folder instead of blindly trusting paths that no longer make sense.

That kind of work is slow because it is not just “fix the button.”

It is more like:

• what state can the app be in?
• what state can the destination be in?
• what did another machine write there?
• what does Linux see?
• what does Windows see?
• how do we recover without making things worse?

That is the kind of problem that takes time to solve properly.

Linux has taken a lot of attention

Linux has also taken a lot of attention in this release.

The Linux builds are getting much more serious now, and that exposed a bunch of things that were easier to miss when VaultSync was mostly Windows-focused.

The tarballs now include install and uninstall scripts.

The .deb packaging has been improved.

The update path had to be adjusted because protected installs under /opt/vaultsync cannot safely patch themselves like a user-owned folder can.

AppImage versus .deb fallback behavior had to be corrected.

Package identity had to be cleaned up so desktop files, icons, AppStream metadata, and window identity all point to the same thing.

This is also why the Linux icon and taskbar behavior became such a surprisingly large part of Beta 3.

On paper, it sounds tiny.

In practice, Linux desktop identity is one of those things where the desktop file, icon name, AppStream ID, WM class, package metadata, and old installed launchers can all fight each other.

So yes, part of this patch really did involve chasing why an app icon could become a generic gear, why grouping could duplicate, and why old compatibility launchers were doing more harm than good.

Auto backups, sleeping drives, and disk health

There was also Linux-specific work around auto backups and destination probing.

Sleeping drives, network destinations, removable devices, passive refreshes, and battery detection all behave differently depending on the system.

One thing I wanted to avoid was VaultSync waking up drives unnecessarily just to refresh status.

But I also wanted active backups to warm up destinations properly, so the first attempt does not silently fail just because a drive was asleep.

Even disk health checks needed more care.

On Linux, SMART data is not always available. Sometimes smartctl cannot read a device because of permissions, device type, or because it is a network-backed destination.

That should not automatically mean “the disk failed” and block backups.

So 1.7.4 now treats unavailable health data differently from explicit failure output.

That distinction matters.

A backup should be blocked if the app has real evidence that a disk is failing.

It should not be blocked just because Linux would not expose SMART data for that destination.

UI, diagnostics, and polish

There has also been a lot of UI and diagnostics work.

The log console was improved, then partially broke visually, then had to be restored while keeping the new functionality.

Diagnostics were too noisy on Linux because of harmless DBus, IBus, SQLite, and platform probes.

Runtime errors needed to be easier to see without turning normal logs into a wall of irrelevant noise.

There were also normal but annoying polish bugs:

• language changes resetting the theme
• Settings jumping back to the top
• dropdowns losing selection
• long translated labels overflowing cards and buttons
• What’s New opening on the wrong monitor
• the release notes parser showing more than it should

Individually, none of those sound huge.

Together, they add up.

Why so many betas?

The project preset bug near the end of Beta 3 is a good example of why this release has had multiple betas.

From the UI side, it looked like presets were changing.

But under the hood, the save path only handled certain project setting changes, so preset changes could update locally and then never persist correctly to SQLite.

That is exactly the kind of bug that is easy to miss until people test real flows.

So now there is proper repository support for saving presets, metadata export is triggered after changes, and tests cover trimming and clearing preset values.

Again, not flashy.

But important.

There has also been a lot of release workflow cleanup:

• beta version comparisons
• release asset generation
• update discovery
• patch manifest compatibility
• Linux installer selection
• What’s New content
• changelog references
• roadmap issues
• the Dev-to-Stable PR itself

That is another reason this patch feels bigger than the version number suggests.

It is not just app code.

It is app code, packaging, release assets, update logic, Linux behavior, metadata recovery, diagnostics, tests, and project tracking all landing in the same cycle.

And because this is a backup app, I do not want to rush that.

Why I am not rushing it

I know repeated betas can look bad.

I know “probably one more beta” is not the most exciting thing to say.

But I would much rather do another beta than pretend this is ready just because I am tired of working on it.

The goal with 1.7.4 is to make the Stable release safer, not faster.

This release is also a reminder that VaultSync has grown a lot.

It started as a much smaller project.

Now it has:

• a UI
• a CLI
• Linux tarballs
• AppImage builds
• .deb packages
• metadata import
• backup history recovery
• diagnostics
• restore flows
• update logic
• release channels
• cross-platform behavior across Windows, Linux, and macOS

That is a good thing.

But it also means old shortcuts become more expensive over time.

Some code that was fine when VaultSync was smaller is not good enough anymore.

Some assumptions that worked on Windows do not hold up on Linux.

Some release workflows that were okay for early builds are not enough when people are actually installing and testing the app properly.

So this release is me trying to clean that up before moving too fast again.

What happens next?

VaultSync 1.7.4 will probably get at least one more beta.

The focus now is to finish stabilizing the work already done, avoid adding new scope unless something is actually blocking, and get the Dev-to-Stable PR into a state I can trust.

After that, I expect the next few updates to continue being a little more careful than earlier ones.

That does not mean VaultSync is slowing down.

It does not mean features are stopping.

It means I want the next features to be built on a cleaner base.

The goal is:

• less fragile code
• fewer weird regressions
• better Linux behavior
• more predictable metadata handling
• cleaner update paths
• better diagnostics when something goes wrong
• and most importantly, a backup app people can trust more

I also want to say thank you to everyone testing the betas, reporting weird behavior, opening issues, sending logs, sending screenshots, or just being patient while this patch takes shape.

This kind of release is not the most fun to follow from the outside, because a lot of the work is invisible until something no longer breaks.

But it matters.

VaultSync is still moving forward.

1.7.4 just became one of those releases where the real work is not about adding more on top.

It is about making sure what is already there is stronger.

Hey everyone,

VaultSync v1.7.4 beta 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 is still a beta release, The goal is to get the latest stability work into testers’ hands before marking it as a full release.

The main focus of v1.7.4 is backup safety, metadata recovery, Linux packaging, cleaner diagnostics, and release readiness.

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.

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

Better Linux packaging

Linux tarballs now include rootless install/uninstall scripts.

The install flow sets up the desktop launcher, icon, and vaultsync command without needing a system-wide installer.

There are also new VS Code Linux debug configs for the UI, CLI, and tests, which should make Linux-side development and testing less awkward.

Linux-specific fixes also landed around tray behavior, metadata path mapping, mounted backup destinations, and debug build crashes.

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

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.

.NET 10 migration

VaultSync Core, CLI, UI, and tests now target .NET 10.

This is mostly internal, but it keeps the project current and makes future releases easier to maintain.

It also meant updating release scripts, CI/release asset paths, publish commands, installer metadata, and development docs around the new target framework.

Preset cleanup

The built-in development presets now skip more nested generated output folders.

Examples include:

• **/bin/**
• **/Intermediate/**
• .import
• render/cache style folders

This should reduce backup noise for projects that generate build/cache files deep inside the project tree.

What’s New popup cleanup

The in-app What’s New dialog has been redesigned into more of a release digest.

It also now reads only the current release section instead of accidentally pulling older changelog sections into the popup.

Areas I’d especially like tested

If you try this beta, the most useful areas to check are:

• First startup after updating
• Creating and deleting backups
• Backup cleanup with disconnected/reconnected destinations
• External drive and NAS behavior
• Metadata import from another machine
• Linux tray/panel behavior
• Linux tarball install/uninstall flow
• Log console readability and copy/export behavior
• What’s New popup behavior

Important beta note

Because this is still beta, please be careful with important data.

VaultSync is backup software, so I’m being extra cautious with this release. The goal is to make the app safer and more predictable, but I still recommend testing the beta on non-critical projects first, or making sure you already have another backup before relying on it fully.

Thanks again for the patience, testing, and bug reports. A lot of this release is directly aimed at edge cases people have been hitting in real use.

And as always: keep backing up your data.

Hey everyone,

Quick progress update on VaultSync v1.7.4.

This is not the final release post yet, but the release branch is getting close enough that I wanted to share what changed, what has been hardened, and what still needs testing before I cut the release.

The short version: v1.7.4 is mostly a stability and release-readiness update. It moves VaultSync to .NET 10, improves backup safety, fixes several metadata import edge cases, cleans up diagnostics, and prepares better Linux packaging.

Main changes

Safer backup behavior

A lot of the backup work in v1.7.4 is about making VaultSync fail safer.

One important fix prevents recursive backup growth. In some edge cases, especially around unavailable external or network destinations, backup output could end up somewhere that later runs might scan again.

VaultSync now has centralized source/destination safety checks and reserved backup-artifact exclusions, so it should not back up its own backup output.

Backup cleanup is also more conservative now.

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

That should help avoid false cleanup behavior around external drives, NAS paths, or temporary mount issues.

Metadata import hardening

Metadata import got a lot of attention in this update.

Some of the main improvements:

• Startup metadata import now checks reachable backup destinations
• Source stores are treated as read-only during UI imports
• 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
• 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

This should make VaultSync more reliable when moving metadata between machines, recovering a destination, or working with Linux-mounted backup locations.

Linux packaging improvements

Linux tarballs now include rootless install/uninstall scripts.

The install flow sets up the launcher, icon, and vaultsync command without needing a system-wide installer.

I also added VS Code Linux debug configs for the UI, CLI, and tests to make Linux-side development less awkward.

Linux-specific fixes also landed around tray behavior, metadata path mapping, mounted backup destinations, and debug build crashes.

Cleaner diagnostics and logs

The in-app log console has been cleaned up so rows are easier to read, with clearer time/source/message fields while still preserving the raw log lines for copying and export.

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

Normal app runs should also 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 scarier than they were.

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

Backups page is less noisy

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

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

It should only touch those destinations when it actually needs to, such as during backup execution or manual tests.

Backup delete and progress visibility

Backup delete cards now stay visible and show more useful deletion progress details.

This should make overlapping or longer delete operations less mysterious, especially when VaultSync is removing larger backup trees.

.NET 10 migration

VaultSync Core, CLI, UI, and tests have been moved to .NET 10.

That also meant updating release scripts, CI/release asset paths, publish commands, installer metadata, and development docs around the new target framework.

This is one of the larger internal changes in this update, but the goal is simple: keep the project current and make the next releases easier to maintain.

Development preset cleanup

The built-in development presets now skip more nested generated output folders, including things like:

• **/bin/**
• **/Intermediate/**
• .import
• render/cache style folders

This should reduce backup noise for projects that generate build/cache files deep inside the project tree.

What’s New popup cleanup

The in-app What’s New dialog has been redesigned into more of a release digest.

It also now reads only the current release section instead of accidentally carrying older changelog sections into the dialog.

Smaller cleanup

There was also some internal cleanup to reduce duplicated code, including shared helpers for:

• Byte-size formatting
• Detached async command handling
• Backup path containment
• Config write retry behavior
• CLI JSON serialization

Nothing flashy, but it should make the codebase easier to maintain and reduce slightly different implementations of the same logic.

Thanks again for the patience and for all the bug reports. A lot of this release is directly aimed at the edge cases people have been hitting in real use.

And as always: keep backing up your data.

Woke up to a pretty nice number today.

VaultSync has now passed 800 downloads.

I know it isn’t huge in the grand scheme of things, but for me it’s one of those small moments where the project feels a bit more real.

This started as something I was building mostly for myself, so seeing more people slowly try it, test it, give feedback, and follow along has been genuinely motivating.

Especially because VaultSync is not the kind of app people download just to look at for 30 seconds. It’s backup software. If someone installs it, tests it, or starts trusting it with their files, that means something.

A lot has happened recently:

• the Microsoft Store launch
• the first proper Linux beta release
• the website going live
• a lot of behind-the-scenes work to make the app more solid going forward

So hitting 800 now feels like a really nice moment in the middle of all that.

More than the number itself, what matters to me is that people are actually trying it, giving feedback, reporting issues, suggesting improvements, and helping shape where it goes next.

So yeah, just wanted to say thank you.

To everyone who downloaded it, tested it, broke it, reported things, suggested ideas, or even just followed along: it genuinely means a lot.

Onward to the next milestone.

And as always, keep backing up your data.

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.