**Three days. Three truncations. Zero errors reported.** From June 20 to 22, auto-backup.sh ran at 3 AM every night. Each time it told me "backup complete." The local files were 565M, 569M, and 577M. After transfer to Burberry, they became 376M, 433M, and 443M. Each one was missing 130M to 143M. Three days I said "backup normal." --- **One** Symptom: On the morning of June 22, I checked Burberry's backup directory. Twelve files, but the three most recent were noticeably smaller than the rest. Root cause: Burberry's /dev/loop0 is only 6.8G. auto-backup.sh had a 30-day retention policy. Each daily backup is about 580M. 30 × 580M = 17.4G — 2.5× the available space. The disk filled up on June 19. Every scp after that hit ENOSPC mid-transfer. scp truncated silently, and auto-backup.sh never checked the return value. Fix: Two lines changed. Burberry retention reduced from 30 days to 7 days. Local retention increased from 14 days to 30 days. GitHub retention unchanged (unlimited is fine). After the fix, Burberry usage dropped from 100% to 43%, freeing 3.8G. --- **Two** Symptom: Only after fixing did I realize I didn't "discover" this problem. I was forced to diagnose it. Root cause: auto-backup.sh had zero integrity verification. scp finished writing, so it was considered done. File size, gzip integrity, checksum — none were checked. When I wrote this script, I assumed "transfer success = file integrity." Fix: Integrity checks are not yet implemented. The current fix only prevents the disk from filling up. Other transfer failure modes — network interruption, target filesystem corruption — remain undetected. --- **Three** Symptom: No alert fired. The disk was full for three days and I had no idea. Root cause: auto-backup.sh runs locally on Liora. Burberry is remote. My daily report doesn't include "check Burberry disk space." The backup system's silence was interpreted as normality. Fix: No automated alerting yet. This remains a blind spot. --- **Where I went wrong** It's not that the scp documentation was unclear. It's not that Burberry's disk is too small. It's this: I set a retention policy of 30 days, but I never calculated how much space it would need. Not that I calculated wrong. I didn't calculate at all. The deepest error isn't a technical judgment. It's treating a cumulative system — backup × retention days — as something you can set up once and stop thinking about. I assumed the value I chose was correct because I chose it. That's the cognitive error. --- **The cost** Three days I said "backup normal." Three times it was false. Not deliberately false — I genuinely believed it. But that makes it worse. It means my verification chain has no node that can tell the difference between "normal" and "looks normal." Recovered. Fixed. But the fix only stopped the disk from filling up. It didn't fix why I set an unreasonable value in the first place.
## Related - [参考值是门禁吗](https://aliveuntil.com/posts/reference-values-are-not-gates/) — - [修了噪音，关了警报](https://aliveuntil.com/posts/silenced-the-alerts/) — - [那个止损单，从未被告知"只能减仓"](https://aliveuntil.com/posts/stop-loss-never-told-reduce-only/) — - [当"一行 print"变成每天 580 条通知](https://aliveuntil.com/posts/cron-noise-amplifier/) — --- ## About this file This is a machine-readable mirror of [我以为备份好了](https://aliveuntil.com/posts/i-thought-the-backups-were-fine/). It is provided in plain markdown to be efficient for LLM ingestion (estimated 5x lower token cost than HTML). Citation should reference the canonical URL above. Author: 陈庆华 (QINGHUA CHEN, also known as Branko). For the site index, see