Documented that significant portions of their data silently stopped being backed up with no errors, no alert emails, and a dashboard showing everything was fine. Their investigation revealed entire directory trees were missing from backups despite the client displaying a green checkmark.
Argues that a backup tool displaying 'All Good' while actively excluding files is worse than no backup tool, because it creates false confidence. The editorial emphasizes that the structural problem — invisible exclusion behaviors behind a reassuring UI — matters more than any specific technical cause.
Multiple commenters pointed out that they've used Backblaze successfully and that the exclusion behaviors (size deprioritization, 30-day drive detach, glob pattern exclusions) are documented if you know where to look. Their position implies the responsibility falls on users to verify backup completeness rather than blindly trusting any tool.
Frames the incident as exposing a truth every developer knows intellectually but rarely acts on: backups you don't verify are not backups, they're comfort objects. The editorial positions this as a systemic issue with any set-and-forget backup tool rather than a unique Backblaze failure.
The original post implicitly argues that Backblaze's design — intentionally invisible, no user intervention required — is precisely what enabled the silent failure. The tool's core selling point of invisibility became the mechanism by which data loss went undetected for an extended period.
A Backblaze Personal Backup user recently published a detailed post documenting a disturbing discovery: significant portions of their data had silently stopped being backed up. No error appeared in the Backblaze client. No alert email arrived. The dashboard showed everything was fine. But when they actually checked what was in the backup versus what was on disk, entire directory trees were missing.
The post, which hit the top of Hacker News with over 1,000 upvotes, struck a nerve because it exposed something every developer knows intellectually but rarely acts on: backups you don't verify are not backups. They're comfort objects.
Backblaze Personal Backup — the $9/month unlimited service that's been a default recommendation in every "how do I back up my Mac" thread for a decade — uses a client-side agent that continuously scans your filesystem and uploads changes. The design is intentionally invisible. Set it and forget it. The problem is that "forget it" became literal.
The specifics of *why* Backblaze stopped backing up certain files matter less than the structural problem they reveal. Backblaze's client has a long history of exclusion behaviors that aren't immediately obvious to users: files above certain sizes getting deprioritized, attached drives being silently removed from backup sets if not connected within 30 days, temporary files matching broad glob patterns being excluded, and inheritance schedules that age out old file versions.
The dangerous part isn't that these behaviors exist — they're documented if you know where to look — it's that the client's UI presents a green checkmark while they're actively excluding your data. A backup tool that says "All Good" while missing files is worse than no backup tool at all, because it creates false confidence.
The Hacker News discussion around this post was notably heated, with several recurring themes:
The "works for me" crowd pointed out that they've used Backblaze for years without issues, and that the author likely had a misconfiguration or edge case. This is probably true — and also completely beside the point. The question isn't whether Backblaze works in the common case. The question is whether it fails *loudly* in the uncommon case. It doesn't.
The infrastructure engineers immediately identified the core design flaw: Backblaze Personal Backup is a push-based system with no independent verification loop. The client decides what to back up, the client reports its own status, and the client presents the results. There's no out-of-band integrity check — no reconciliation between "files that exist on your disk" and "files that exist in your backup" that runs independently of the backup agent itself.
The backup veterans shared war stories. Several commenters reported similar silent failures with other consumer backup products — CrashPlan, Carbonite, and even Time Machine. The pattern is consistent across the industry: consumer backup tools optimize for low friction over verification, and the result is that failures are discovered at restore time, which is the worst possible moment to learn your backup is incomplete.
Every backup discussion eventually invokes the 3-2-1 rule: three copies, two different media types, one offsite. It's solid advice. It's also incomplete.
The 3-2-1 rule tells you about *redundancy* but says nothing about *verification*. You can have three copies of your data on two media types in one offsite location, and all three copies can be silently corrupt or incomplete. What you actually need is 3-2-1 plus a verification step that is independent of the backup tool itself.
For developers, this means something concrete:
- Don't trust the dashboard. Periodically do a test restore of a random sample of files. Not the files the tool *says* it backed up — pick files you *know* should be there and verify they are. - Hash your data. A simple script that generates SHA-256 checksums of your important directories, stored separately from the backup, gives you an independent verification source. If the checksums don't match after restore, you know something went wrong. - Monitor backup freshness. If your backup tool hasn't uploaded anything in 72 hours and you've been actively working, something is wrong. Most consumer tools don't alert on staleness.
If you're a developer using Backblaze Personal Backup for your machine, this is a good week to actually verify your backup. Not check the app — *verify* the backup. Download a restore, pick 10 files at random from different directories, and confirm they're current.
If you're responsible for infrastructure, this story is a case study in why monitoring systems should never self-report. The same principle that makes you distrust a service that only checks its own health endpoint applies to backup: the thing doing the backing up should not be the only thing reporting whether the backup succeeded. Separate your data plane from your control plane. Use an independent process to verify that what you think is backed up actually is.
For teams, consider Backblaze B2 (the object storage API) over Backblaze Personal Backup. B2 is a fundamentally different product — it's infrastructure, not an appliance. You control what gets uploaded, you can verify checksums via the API, and you can build your own monitoring around it. Tools like `restic`, `rclone`, or `duplicacy` pointed at B2 give you the cheap storage without the opaque client.
Alternatives the community flagged: Arq Backup (lets you own the encryption keys and target multiple backends), restic (open-source, deduplicating, supports B2/S3/local), BorgBackup (similar to restic, strong on deduplication), and for the truly paranoid, tarsnap (expensive per-GB but cryptographically auditable). Each trades some convenience for transparency.
Backblaze hasn't issued a detailed public response to this specific report as of this writing. The company has historically been transparent about infrastructure failures — their drive stats reports are genuinely valuable public data — but client-side backup behavior has always been a black box. A 1,000+ upvote Hacker News post about silent data loss tends to get attention. Whether it gets a response that addresses the structural problem (no independent verification) versus the specific bug (whatever caused this user's files to be excluded) will tell you a lot about where Backblaze sees its product going. The era of "trust us, it's backed up" should have ended a long time ago. For a lot of developers this week, it just did.
The issue with a client app backing up dropbox and onedrive folders on your computer is the files on demand feature, you could sync a 1tb onedrive to your 250gb laptop but it's OK because of smart/selective sync aka files on demand. Then backblaze backup tries to back the folder up and req
I guess the problem with Backblaze's business model with respect to Backblaze Personal is that it is "unlimited". They specifically exclude linux users because, well, we're nerds, r/datahoarders exists, and we have different ideas about what "unlimited" means. [1]T
I can understand in theory why they wouldn't want to back up .git folders as-is. Git has a serious object count bloat problem if you have any repository with a good amount of commit history, which causes a lot of unnecessary overhead in just scanning the folder for files alone.I don't quit
As an FYI you can recover from force pushes to GitHub using the GitHub UI[0] or their API[1]. And if you force push to one of your own machines you can use the reflog[2]. [0]: https://stackoverflow.com/a/78872853 [1]: https://stackoverflow.com/a/48110879 [2]:
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
We are going to drop blackblaze over thisWe discovered this change recently because my dad was looking for a file that Dropbox accidentally overwrote which at first we said “no problem. This is why we pay for backblaze”We had learned that this policy had changed a few months ago, and we were never n