Which Syncthing Changes Leave a Recoverable File Version?

Syncthing file versioning can preserve a file that is about to be replaced or deleted because of a change arriving from another device. It does not preserve every edit made directly on the device where versioning is enabled. For a home server holding synchronized documents or photos, that direction matters more than the name of the retention strategy.

The useful question is not simply whether versioning is switched on. It is which device receives the change, whether that device already has the previous file, and how long its policy can retain that copy.

History begins on the receiving device

Consider a laptop and a NAS sharing a folder. The NAS has versioning enabled; the laptop changes a document that has already reached both machines. When the NAS receives the replacement, its versioning policy can archive the previous copy. The laptop's own edit was not archived locally by that same NAS setting.

Now reverse the direction: an application on the NAS overwrites the document directly. Syncthing cannot use its incoming-change versioner to capture that local overwrite. A different device with versioning enabled may preserve its own previous copy when it receives the NAS change, but that is a separate recovery location.

The official versioning documentation defines this as a per-folder, per-device setting, disabled by default. Enabling it on one device does not establish the same history everywhere. Nor does it retroactively produce versions of files that disappeared before the policy existed.

Retention strategies answer different questions

The built-in choices trade detail against storage. Decide what kind of mistake the history needs to cover before treating a retention field as a recovery promise.

• Trash Can: keeps the displaced file, but a later archived file with the same name replaces the earlier one. This suits a recent undo opportunity, not a sequence of many edits.
• Simple: retains a configured number of old versions per file, with an age-cleanup option as well. A frequently changed file can exhaust the count before a hoped-for time window has elapsed.
• Staggered: retains versions at increasingly coarse time intervals as they age, subject to the maximum-age policy. It preserves a selection of history rather than every change.

A zero age limit is not a universal instruction to retain all versions. Trash Can still replaces its same-name predecessor; Simple still has a version-count limit; Staggered still thins versions by interval. Count, age, and sampling rules describe different boundaries. These distinctions follow the strategies in the current policy reference.

A conflict copy is not a scheduled checkpoint

A file bearing a sync-conflict name answers another question: two devices produced competing changes. It does not prove that a chosen daily or weekly recovery point exists. Syncthing treats a conflict copy as an ordinary file after creating it, so it can propagate to the other devices.

That differs from the version archive. According to the synchronization documentation, conflict handling selects a file to rename using defined rules; it cannot decide which content a person intended to keep. A household document edited offline on two laptops therefore needs a content decision, not just a green synchronization status.

Keep the comparison narrow: versioning handles incoming replacements under a retention policy, while conflict handling preserves competing content when synchronization detects a conflict. Neither mechanism is an application-aware revision history for an entire project.

The archive has its own storage boundary

The default location for retained versions is the .stversions directory within the shared folder. The Syncthing FAQ lists that directory among internal items excluded from synchronization. A second machine holding the current files should not be assumed to contain the first machine's version archive.

This matters when planning a disk replacement or a backup. Copying only the visible working files may leave recovery history behind. A custom versions path also has constraints: the official documentation calls for the same partition or filesystem as the shared folder because moving files across that boundary may fail.

Local version history is consequently not independent protection against loss of the disk holding it. An independent backup needs a deliberately chosen destination, retention policy, and proven recovery process. Synchronization and local undo history can complement that backup without substituting for it.

Judge protection by the change that matters

For a private cloud document folder, the important distinction may be an accidental laptop overwrite versus a process rewriting files directly on the home server. Those changes travel in different directions and can leave different recovery evidence.

Before relying on a policy, identify the writing device, the receiving device, the old copy that should survive, and the rule that will eventually remove it. Also identify where that archive remains if its device fails. A synchronized folder describes agreement on current files; a recoverable version describes a particular earlier file that still exists somewhere accessible. Those are related outcomes, not interchangeable ones.