For twelve days my backup was a paragraph

My notes said in bold that git was the real backup. The repo did not exist. Then the fix deleted 900 files on its first night. What a backup has to prove.

By Dasha. Updated November 12 2026. https://heardofyou.io/blog/my-backup-was-a-paragraph

In September my setup notes said, in bold, "git is now the real backup". I wrote that sentence myself, after a scare the week before, and I believed it for twelve days. On day twelve I ran an inventory of my setup: seven small scripts, each checking one piece, each independently running ls on the backup folder. No such file or directory. Seven times. The repo had never been created.

What it looked like from the outside

My notes read like a tidy system. Skills mirrored to the cloud. Memory mirrored to the cloud. "Git is the real backup, the cloud copy is convenience only." Anyone reading them, including me and including the AI assistant that reads them at the start of every session, saw a remedy with a name and stopped looking. A durable sentence that names a fix gets read as proof the fix exists. Twelve days of sessions read the claim, nodded, and moved on.

That is the same shape as a lot of things I have since learned to distrust. A confident sentence hides better than a missing one. If the paragraph had been blank, someone would have asked.

What was actually true

The only copy of 870 memory files, ten months of "do not do that again" notes that my AI coding assistant depends on, plus a 34 KB instructions file, lived in one iCloud folder. And that folder had already failed a real restore the week before. That failure was the scare.

On a second Mac I had tried to pull the same files down. Every file had the right name and the right size in a directory listing, and not one of them would open. The folder was set to optimise storage, so each file was a placeholder waiting to be downloaded on first access, and the download hung. For every file. For 25 minutes. Meanwhile other folders on the same machine read instantly, so it was not the cloud being down, it was this folder specifically, for reasons I never found out.

Worse: one copy command gave up partway and left a 0-byte file in place, which my restore loop then skipped because it only checked that the folder existed. The guard said SKIP, which read as "already done". So I went back to the first laptop and wrote the paragraph. I wrote down the remedy. I did not do the remedy.

Then the fix deleted the backup

Once the inventory caught it, I did it properly: a real git repository, a backup script, a nightly scheduled job. On the first night it fired, it emptied the backup. All 900 files.

Two ordinary facts combined. First, a job started by the macOS scheduler cannot read the iCloud folder unless its shell has been granted full disk access, and the error it gets, "Operation not permitted", does not stop a shell script. Second, my copy function cleared the destination before copying into it, because that is the order I wrote it: remove, make directory, copy. The copy failed. The remove had already happened.

Run by hand from my terminal the identical script worked perfectly, every time, because my terminal already had disk access and the scheduler did not. I had tested it in the one context that could not reproduce the failure.

What saved the 900 files was an unrelated guard I had added for a different reason: refuse to commit if the file count drops by more than 5%. Git still held everything, so one checkout restored it. Had that guard not existed, the nightly job would have committed 900 deletions over the only durable copy. A backup job destroying the backup, silently, on a schedule, with a green exit code.

The tests I trusted were lying too

My copy function guarded each file with [ -f ] (exists) and [ -s ] (not empty). Both return true for a file whose bytes macOS will refuse to hand over. Presence is not readability. The only honest check is to read one byte:

``bash
head -c 1 "$f" >/dev/null 2>&1 || abort
`

That line now runs before anything destructive, in a preflight that touches nothing and exits loudly. I re-ran the job under the scheduler afterwards: 900 files before, 900 after, zero deletions. That is the first time the script had been tested in the context that actually runs it.

The rule I follow now has one word in it: restore. Not "has a backup". Has restored, recently, and read a byte. Before writing "X is backed up" anywhere durable, run the command that proves it in the same breath (ls, git log -1, git remote -v) and paste the output next to the claim. Never delete before you have proved you can copy. And never conclude a script works because it works in your terminal; test it where it will run.

The off-machine copy exists now, I have cloned it back and counted the files, and the counting is the whole trick. I now sell a service whose entire job is to not take a confident sentence's word for it, whether the sentence comes from a chatbot or from me. That one cost twelve days and 900 files to learn, which is cheap, and I only know it was cheap because I ran ls`.