There’s a rather screechy post making the rounds about a change in BackBlaze’s backup policies.

The author uses words like “betrayal”, “furious”, “alarmed”, and other such superlatives.  Whether this is really the worst thing since World War II, I will leave for you to decide.  But it is disappointing, for sure.

Here’s what happened:

A few versions back, BackBlaze changed their backup client so it no longer backs up OneDrive, Dropbox, .git folders, etc.

The Backup Client now excludes popular cloud storage providers from backup, including both mount points and cache directories. This prevents performance issues, excessive data usage, and unintended uploads from services like OneDrive, Google Drive, Dropbox, Box, iDrive, and others. This change aligns with Backblaze’s policy to back up only local and directly connected storage.

Worse yet, they tucked this into the release notes that hardly anyone ever reads.  And worse still yet, it’s not some default setting you can override.  While there are some things excluded by default in a user-configurable list, these folders are not listed.  They’re hard-coded.

Not a Good Look

Backup companies inherently sell trust.  When you do something that runs contrary to user expectations and puts them in a vulnerable spot, that trust is obviously eroded.

It’s true that a lot of cloud storage is also a backup system and not just sync.  With some of the services (e.g., Dropbox) you can go back in time up to a year to see all the versions of files stored there and restore one.

But regardless, users are paying for Backblaze to backup their systems.  Obviously, if Backblaze can exclude large segments of a user’s computer, they have a lot less data to store.

Indeed, the most valuable parts of a user’s PC are now being excluded.  If my PC melts down, it’s my documents, pictures, and other personal data I’m going to want back first.  What happens if one of these cloud storage companies has a serious malfunction and I can’t get my data back from them?  Blackblaze is apparently not the answer any longer.

raindog308

raindog308 is a longtime community LETizen, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, raindog308 runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, raindog308 has a life-long love of German Shepherd Dogs, high-quality knives, target shooting, theology, tabletop RPGs, playing guitar, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.