The Line Between File Sync and a Real Backup

A second copy of a file is not necessarily a backup. If that copy remains synchronized with the original, an accidental deletion or unwanted replacement can propagate to it.

That distinction is central to Syncthing. It synchronizes file creation, modification, and deletion across devices (Syncthing FAQ). This is useful when you want the same current files on a desktop, laptop, and homelab server. The critical recovery question is:

After an unwanted change has propagated, can you recover the state you need?

Syncthing’s file versioning can improve the answer, but its coverage depends on where a change originates, which device has versioning enabled, and how long archived versions are retained.

Testing scope: This is a documentation-based explanation. No destructive deletion, restoration, ransomware, or device-loss tests were performed.

Synchronization preserves current state, not history

Imagine a folder shared between a desktop and a server. You delete projects/design-notes.md on the desktop. Syncthing treats the deletion as a synchronized change, so the server’s current copy is also deleted after synchronization.

An unwanted file replacement follows the same pattern: the new state is distributed to the other devices. Syncthing tracks the version on each device and determines a “global” version that participating devices attempt to reach (Understanding Synchronization).

By default, Syncthing file versioning is disabled, so no old copies are retained by that feature (File Versioning). An unversioned replica may still help when one device fails and the desired current files remain elsewhere. It should not be treated as recovery from a deletion or replacement that has already synchronized.

A backup addresses a different need: preserving historical states that remain recoverable independently of the current synchronized state.

What Syncthing versioning covers

When versioning is enabled on a device, Syncthing can archive the old copy before applying a deletion or replacement received from another device. Versioning is configured separately for each folder on each device (File Versioning).

The phrase received from another device matters.

Suppose Alice and Bob share a folder, and only Alice enables versioning:

If Bob edits or deletes a file, Alice can archive her previous copy when she receives Bob’s change.
If Alice edits or deletes a file locally, Syncthing cannot archive Alice’s previous local copy through its versioning feature.
If Bob also enables versioning, he can archive previous copies when he receives changes originating from Alice.

These directionality rules are documented by Syncthing: versioning applies to changes received from other devices, not changes made locally on the device holding the archive (File Versioning).

A designated server can therefore retain useful history for changes arriving from client devices. Changes made locally on that server remain outside its own Syncthing versioning coverage.

Comparing the versioning strategies

Syncthing documents four strategies, each with different retention behavior (File Versioning):

Trash Can: Keeps the previous file after a remote deletion or replacement. An existing archived file with the same name is replaced, so this is not a multi-version history. Optional cleanup can remove archived files by age.
Simple: Keeps a configured number of timestamped versions for each file affected by remote changes. Cleanup settings can also affect retention.
Staggered: Keeps closely spaced recent versions and progressively thinner older history. Versions are removed when they exceed configured age or interval limits.
External: Runs an external command before a file is replaced, delegating archival behavior to another program or script.

All four remain subject to the same directional limitation: they act on changes received from elsewhere rather than preserving the previous state of a locally changed file.

Decision table: what can you recover?

This table summarizes documented Syncthing behavior and conceptual backup coverage. “May remain” assumes the relevant retention settings have not removed the version and that the archive storage is still available.

Event	Sync only	Trash Can	Simple	Staggered	Independent backup
Remote deletion reaches this device	Deletion propagates; no old copy is retained by default	Most recent copy may remain	Timestamped versions may remain	A retained historical copy may remain	Depends on captured restore points and retention
Remote file replacement	New state replaces current state	Previous copy may remain	Several previous versions may remain	Recent and selected older versions may remain	Depends on captured restore points and retention
File changed locally on this device	No Syncthing version history	Previous local state is not archived	Previous local state is not archived	Previous local state is not archived	Can be covered if the backup captured it
Concurrent, differing edits	A conflict copy may be created	Same conflict handling	Same	Same	Depends on which states were captured
Archived version exceeds retention	No archive	May be removed by age	May be removed by count or cleanup settings	May be thinned or removed	Depends on backup policy
Device holding versions is lost	No Syncthing history	Local archive may be lost	Local archive may be lost	Local archive may be lost	Depends on whether backup storage survives independently

When simultaneous, differing edits create a sync-conflict copy, Syncthing treats that copy as an ordinary file and propagates it to other devices (Understanding Synchronization). This can preserve both outcomes in that particular conflict, but it is not a managed version history.

The version archive is local

For most strategies, archived files default to a .stversions directory inside the shared folder. A custom path is possible, but Syncthing advises keeping it on the same filesystem as the shared folder because moving files across filesystems may fail (File Versioning).

The .stversions directory is an internal Syncthing directory and is not synchronized to other devices (Syncthing FAQ). Consequently, the archive does not automatically replicate across the cluster. If the device or storage containing it is lost, its recovery history may also be lost unless another system protects it.

Choosing an arrangement

Sync only

Use this when the goal is access to current files across several devices and history is unnecessary or already handled elsewhere. Deletions and replacements will propagate.

Sync with versioning

Use this for limited recovery from changes originating on other devices. Simple or Staggered versioning on a designated server can retain history, subject to retention and available storage. Local changes on that server are not archived by its own Syncthing versioning.

Sync plus independent backup

Use this when you need both synchronized working files and independently managed historical recovery. Syncthing can distribute current files while a separate backup or snapshot system captures the required states.

Before relying on a design, ask:

Which devices originate edits and deletions?
Where is versioning enabled?
How many versions—or how much history—should remain?
Is .stversions protected separately?
What happens if the versioning device is lost?
Has restoration been verified on the systems in use?

The practical boundary is simple: synchronization aligns current state; Syncthing versioning preserves selected earlier states of remotely received changes; backup begins when recoverable history is managed independently of that synchronized state.