The backup that deleted my file, faithfully
You delete a file by accident. You reach for your sync folder, because that's where everything lives and it has always felt like safety. The file isn't there. It was deleted on the other machine too — instantly, correctly, exactly as designed.
Nothing malfunctioned. A sync tool's entire job is to make two places identical, and it did that flawlessly. It replicated your mistake with the same fidelity it replicates your work, because it has no way to tell them apart.
This is the most common data-loss story among people who are, by their own reckoning, careful. They have a sync tool. They assumed a sync tool was a backup. Those are different jobs, and the gap between them only becomes visible on the day you need the one you didn't have.
The fix isn't a better tool. It's noticing that three separate questions have been collapsed into one.
Three questions about time
Every file you care about raises three questions, and they are genuinely distinct:
Is this the same everywhere? — the present. You edit on the laptop and want it on the phone. This is mirroring, and Syncthing does it.
Can I get this back if the disk dies? — the past, off this machine. This is backup, and Restic does it.
How did this become what it is? — the past, on this machine. Not "restore yesterday's file" but "show me every step, and why." This is history, and Git does it.
One file-set, three questions. The reason they resist being merged is that each demands a property the others actively don't want.
A mirror must propagate deletions — that's what makes it a mirror. A backup must refuse to propagate deletions, or it isn't protecting anything. Ask one tool to do both and you've asked for a contradiction; what you'll get is the mirror's behaviour with the backup's reassuring name.
Why the mirror can't be the backup
Syncthing is superb at what it does. It also has no memory of what you meant.
Delete a file, it deletes it everywhere. Corrupt a file — a bad save, a half-written export, ransomware — and it faithfully corrupts every copy. Speed, which is a virtue for mirroring, becomes the vector: the damage is everywhere before you notice it happened anywhere.
Versioning helps at the margin. Syncthing's staggered versioning keeps old copies for a while, and it has saved me. But it lives on the same disks, inside the same trust boundary, and only for a window. It's a seatbelt, not a spare car.
The honest formulation: a mirror is a copy of the present. A backup is a copy of the past that the present cannot reach. That unreachability is the whole point.
Why the backup can't be the history
Restic is my backup, encrypted client-side before anything leaves the laptop, sitting in EU object storage. It answers "can I get it back" completely.
It answers "how did this become this" barely at all. Restic gives you snapshots — the state of everything at 03:00 on a Tuesday. Diff two snapshots and you get a list of changed files. Not why. Not in what order. Not which of them belong to one coherent change.
Git gives you all of that. Not because it stores more, but because a commit is authored — it's a claim about intent, with a message, grouping a set of changes that mean one thing together. That intent cannot be reconstructed from two snapshots after the fact. It has to be recorded when the change is made, or it's gone.
Which is why the two layers compose rather than compete. .git is just files on disk. The encrypted backup sweeps up your full version history for free, no extra step — the history layer and the backup layer meet exactly once, at rest, as ciphertext.
Why the history can't be the mirror
The reverse temptation: Git syncs, so use Git for everything.
Git is superb at merging text with a shared history. It is bad at binaries, bad at large files, and it demands a commit before anything moves. That's the wrong friction for a scanned PDF or a photo library.
Worse is what happens if you let a sync tool replicate .git itself. A sync tool sees a folder of independent files. Git sees one interdependent whole. Let two devices write to the same repository internals concurrently and the sync tool will merge at file level into something Git considers structurally inconsistent — a corrupt repository. Sync-conflict copies, harmless among notes, are poison among Git's objects.
The rule that follows is narrow and load-bearing: exclude the version-control directory from the sync layer, and run Git on one machine. That ignore rule is the literal boundary between two layers. It's one line of config, and it's the difference between three tools cooperating and two tools fighting over the same bytes.
The green checkmark is not the evidence
A structural split doesn't verify itself. And this is where personal infrastructure quietly rots: the layers are correct, and you stop checking, because everything reports fine.
A real morning from my own system. The health-check flagged three scheduled backup tasks as failed — exit code 0x1, red across the board. Backups broken, apparently.
They weren't. Every snapshot was fresh: vault three hours old, repos and config eleven. What had actually failed was the cleanup step afterward — the retention prune couldn't acquire a lock, because a stale lock from an interrupted run was still sitting there. The backups had succeeded and then tripped on the way out the door.
The inverse had bitten me before, and it's the worse direction: a task reporting success — clean 0x0, green — while no backup had run for six days. An em-dash in a string literal had broken the script under an older PowerShell, and the wrapper swallowed it.
So the exit code is not the evidence, in either direction. The evidence is a fresh snapshot per path, and a restore you have actually performed. My health-check now verifies snapshot freshness per backup path rather than reading return codes, because the return code turned out to be the least reliable signal in the system.
A rule the system can't check is decoration. That includes the rule that says your backups are working.
Where the split earns its keep
The clearest demonstration came from adding a second workstation — a laptop at the other house, wanting the same vault.
The obvious move is bidirectional sync: both machines read and write, everything converges. It works right up until both edit while apart, and then you're arbitrating conflict copies across a 90,000-file vault, forever.
The split suggests something better. Ask which job the second machine is doing. It reads, and it produces small amounts of new work. It doesn't need to be a second master.
So: the vault mirrors to it receive-only, and one small folder mirrors back the other way, send-only. Exactly one writer per folder, in both directions.
The difference is categorical. Receive-only isn't a convention I have to remember — the protocol refuses to propagate local changes and offers to revert them. Conflicts aren't unlikely; they're structurally impossible. Nothing depends on my discipline at 11pm.
It costs something real, and the trade is worth naming: on that machine, tools can read the vault but not write to it. Work produced there lands in the inbox folder and gets filed when I'm back at the master. Draft on the satellite, file at the source. I'd rather have that constraint than a permanent merge problem.
Backup didn't change at all. It runs from the master, as it always did. Three layers, three roles, and adding a machine only touched one of them — which is the practical payoff of keeping them separate in the first place.
The shape of the answer
Three questions, three tools, one file-set:
| Question | Tense | Job | Must |
|---|---|---|---|
| Same everywhere? | present | mirror | propagate deletions |
| Recoverable if the disk dies? | past, offsite | backup | refuse to propagate deletions |
| How did it become this? | past, local | history | record intent, not just state |
The tools are incidental — pick whatever you like. The split is the durable part.
Sync gives you the present on every device. Backup gives you the past, encrypted, out of reach of your own mistakes. Version control gives you the story, locally, where your private material stays private. They compose: history is files, so backup captures it for free; sync carries content, so it never touches history's internals.
None of this is exotic. It's one idea — match the tool to the actual question — applied to the least glamorous corner of a personal system, where the cost of getting it wrong is invisible until the day it's total.
Part of the Structure Beats Magic series, and the third leg of a trilogy: Syncthing as the Glue is the mirror, Restic + Hetzner is the backup, and this is the history — plus the argument for why they must stay three.