Backups

My GitHub recovery codes lived on GitHub

Found github-recovery-codes.txt in my vault this weekend, in a folder called Important Docs. The vault is an Obsidian setup that auto-commits every ten minutes and pushes to a private GitHub repo. So the codes for getting back into GitHub were sitting behind the GitHub login. Think about the day I actually need them - phone gone, authenticator gone, sessions expired. Can’t clone the repo. Can’t open the site. The codes might as well not exist.

Sunday, August 2, 2026 | 3 minutes Read

OneDrive and git fought over my vault. Both lost.

Over two days my Obsidian vault appeared to delete itself, git recorded 146 file deletions that never happened, and OneDrive spawned 120 conflict copies of notes I had just restored. Not one byte of a note was lost. Every failure traces back to a single sentence: two sync systems each believed they owned the same tree, and each interpreted the other’s behaviour as changes to sync. I have written this shape of post before. RAID1 saved my data but not the state around it, and a trap I had published a warning about caught my own app the same day. This one belongs to both families: the data was never in danger, the state lied about it, and the limit that made it all worse was documented in a workbook I had read and dismissed as something that happens to other people.

Friday, July 31, 2026 | 7 minutes Read

When RAID1 saved the data but not the state

My home server is a ZimaBoard 2 running ZimaOS. The storage that matters is a RAID1 mirror, two 4 TB drives formatted BTRFS, holding a media library, backups, and personal archives, with the Docker application stack running off the same pool. It is a small setup, and for a long time it was a boring one, which is exactly what you want from storage. Then a migration went wrong, and it taught me more than a year of everything working ever did.

Monday, January 12, 2026 | 4 minutes Read