Secrecy, sync, and backup are different jobs

Sensitive files on more than one machine need three answers at once: who can read the data, where the latest copy lives, and whether you can recover an older version after you delete or ruin the current one. Cryptomator, Syncthing, and restic each cover one of those jobs. Stack them instead of expecting a single app to handle all three.

Sync is not backup

Sync keeps folders aligned. Deletes, bungled edits, and ransomware ride along when sync works as designed. Encryption changes who can read bytes on disk; it does not roll back mistakes. For history you want snapshots: restic’s backup docs treat each backup as a snapshot of a directory at one moment, with dedup across runs so you are not storing full duplicates every time.

Incremental sync and incremental backups both favor lots of small files, not one opaque encrypted disk image.

Cryptomator stores lots of ciphertext files

Cryptomator’s vault format stores a vault as many encrypted objects (today’s layouts use .c9r / .c9s files plus masterkey.cryptomator and config). Edit one document and sync plus backup see a handful of changed files, not one blob that rewrote wholesale.

Details of how names and chunks are wrapped are in Security architecture and Vault cryptography. You do not need the math to use the idea: the vault is a directory tree of ciphertext objects, which is what cloud clients, Syncthing, and restic all like to work with.

Multi-device edits can still collide. Cryptomator’s sync conflict notes describe suffix-style duplicate filenames like typical cloud conflicts; you open both copies and choose.

Cryptomator is folder encryption carried by sync or backup underneath, not full-disk encryption for the OS drive.

VeraCrypt containers fight tiny deltas

VeraCrypt volumes include file-hosted containers: one normal file that hosts an encrypted virtual disk. Strong choice when the goal is “encrypt this disk or this blob,” weak fit when the goal is “keep small deltas moving between machines.” Cryptomator’s own comparison with VeraCrypt spells out the workflow pain: changing something inside the container can force the whole container to look updated to sync tools, and simultaneous use from multiple devices is risky. Block-level sync might shave pain; it does not turn a container into a directory of independent ciphertext files.

That is a workflow mismatch for VeraCrypt, not a verdict on disk encryption.

Syncthing replicates folders peer-to-peer

Syncthing mirrors folders machine to machine over TLS (syncthing.net, docs). For secrets you usually sync the Cryptomator vault folder: peers ship ciphertext; devices that should see plaintext unlock the vault locally.

For a peer you trust less, untrusted / encrypted folders exist: Untrusted devices store payloads encrypted with a folder password (and folder id); trusted machines hold cleartext. The docs still label this beta. The spec keeps payloads and names opaque while sizes and coarse timing of block transfers still show through on an untrusted peer. Read it instead of assuming blind storage.

Even when it fits your threat model, Syncthing remains replication. It is not a substitute for restic-style history.

Point-in-time copies with restic

Point restic at the directory tree you care about (typically the Cryptomator vault folder). Schedule restic backup; each run creates a snapshot id; unchanged bytes dedupe (backing up). restic restore can pull latest, an older id, or a filtered path; --dry-run shows what would land before you commit.

Backing up ciphertext means the repository password joins vault passwords on your disaster-recovery checklist.

One person, a few devices

A pattern that stays legible:

1. Keep the sensitive working set in a Cryptomator vault directory.
2. Sync that directory with Syncthing between your own machines; optional untrusted peer if the spec matches your comfort and you accept the beta label.
3. Run restic backup from a trusted machine on a schedule, to object storage or another disk you control.
4. Restore a snapshot twice a year on purpose so the runbook is real.

Cryptomator alone hides bytes while replicas march off the same cliff. Syncthing without Cryptomator ships plaintext to peers who should not see it. restic without sync leaves you thin when the only laptop dies between jobs. Assign secrecy to Cryptomator, live copies to Syncthing, retention to restic; rehearse conflicts and restores before you need them.