Sync vs Backup

The most common operational failure when adopting Syncthing is treating it as a backup solution. Syncthing is a synchronization tool, not a backup tool.

Learning Focus

Understand the risks of continuous synchronization and why you must pair Syncthing with a snapshot-based backup tool like Restic.

The Core Difference

Synchronization (Syncthing)

Synchronization aims to make the state of folder A match the state of folder B as quickly as possible.

• If you create a file on A, it is created on B.
• If you edit a file on A, the edit propagates to B.
• Critical: If you delete a file on A, it is deleted on B.
• Critical: If ransomware encrypts files on A, the encrypted files are instantly synced to B.

Backup (Restic)

Backup aims to preserve historical states of data so you can recover from mistakes or data loss.

• Backups are one-way (Source -> Repository).
• Backups are usually point-in-time (e.g., daily at 2:00 AM).
• Backups retain deleted or modified files for a defined retention period.

The Disaster Scenario

Consider a photographer with a Laptop syncing photos to a Home NAS via Syncthing.

1. User error: The photographer accidentally runs rm -rf /Pictures/2025/Wedding.
2. Sync triggers: Syncthing detects the deletion.
3. Propagation: Syncthing tells the NAS to delete the /Pictures/2025/Wedding folder.
4. Result: The photos are gone on both the Laptop and the NAS within seconds.

Built-in Mitigation: Syncthing Versioning

Syncthing does offer an internal mitigation called File Versioning. When enabled on a folder, if a remote device alters or deletes a file, the local node keeps the old version in a .stversions directory.

Types of Syncthing versioning:

• Trash Can: Keeps deleted/replaced files for X days.
• Simple: Keeps the last X versions of a file.
• Staggered: Keeps versions intelligently (more versions recent, fewer older) similar to grandfather-father-son (GFS).

warning

Versioning is an emergency undo button, not a backup strategy. It does not protect against catastrophic local hardware failure, local user deletion (versions are only kept when remote nodes make changes), or repository corruption.

The Recommended Architecture: Sync + Backup

The gold standard pattern is to use Syncthing for mobility and Restic for durability.

flowchart LR
    LAP[Laptop] <-->|Syncthing\nReal-time| NAS[Home NAS]
    NAS -->|Restic\nNightly| B2[(Backblaze B2\nOffsite)]

How this works

1. You work on your LAP. Changes sync instantly to your NAS using Syncthing.
2. If your LAP dies, you can grab another laptop, connect to the NAS, and instantly resume work. (High Availability / Mobility).
3. Every night, the NAS runs a restic backup of the synced folder to cloud storage.
4. If you accidentally delete a file on the LAP or get ransomware, Syncthing corrupts the NAS copy, but you run restic restore on the NAS to pull the file back from last night's snapshot.

Summary

Feature	Syncthing	Restic Backup
Primary Goal	Availability & Mobility	Durability & Recovery
Direction	Bi-directional (usually)	One-directional
Accidental Deletion	Destroys data everywhere	Saved in historical snapshot
Malware/Ransomware	Propagates immediately	Can restore prior clean state

What's Next

• Syncthing vs Rsync vs Rclone