Backblaze Update Shrinks Bloated Logs

Originally published at: Backblaze Update Shrinks Bloated Logs - TidBITS

While deciding how much internal storage to get with a new Mac, I recently explored what was consuming space on my 27-inch iMac and discovered something surprising. Backblaze, the Internet backup service I’ve used since 2018, was consuming over 100 GB of my 1 TB drive. Given that the entire point of a backup service is to copy data elsewhere, this seemed excessive.

Further investigation revealed that the space was split between two main areas: bzlogs, which occupied 59 GB, and bzbackup, which took up 41.5 GB. Both seemed excessive.

Backblaze storage usage

Some discussion with Backblaze support revealed that the contents of bzbackup were directly associated with my backups and should not be messed with. I found a suggestion that I could save space on my new Mac by reinstalling Backblaze without inheriting the previous backup and the 41.5 GB of changes it has recorded in the current backup. That new backup wouldn’t have historical changes, but my belief is that the previous backup will remain accessible for a year, which is plenty of time to ensure I have everything backed up again. I need to conduct further research and testing before making a decision about inheriting the previous backup.

The contents of bzlogs were a much easier story. They were excessively large because Backblaze couldn’t back up files stored in iCloud Drive, Dropbox, and Google Drive that had been evicted and thus existed only in cloud storage. Worse, the errors seemed to indicate that my test account also had iCloud’s Desktop & Documents folder syncing enabled (which wasn’t the case), causing another error for every file in those folders for the test account. Backblaze logged each of those failures, and those log lines added up fast: roughly 2.9 GB per day for each of the last 30 days.

2025-04-29 00:00:00 38134 - WARNING: could not read file, diagnosed_as=BZ_FILE_TEMPORARY_OTHER, skipping_DDD for now, fileName: /Users/ghost/Library/Mobile Documents/com~apple~CloudDocs/Documents/TidBITSsvn/Articles/.svn/pristine/7e/7e0a064ff6b1f08bda42080afe149463315b4478.svn-base

2025-04-29 00:00:00 38134 - BzClientVersionManager.cpp:441 [BzClientVersionManager::IsEndOfLife()] WARNING: BzClientVersionManager::IsEndOfLife - invalid clientversion revision (rev 3)

Rather than remove the overly large log files manually, I opted to try a suggestion from Backblaze support. The company had just released a beta version that addressed the log bloat, so I installed that and checked in a few weeks later. The new logs were a much more reasonable size, ranging from about 600 KB to 8.7 MB, as you can see below. Today, the contents of that folder have dropped from 59 GB to 84 MB.

Backblaze logs folder

I don’t recommend running betas of backup software, and you don’t have to, because the necessary version 9.2.1.852 was released; the current version is now 9.2.1.860. The release notes for 9.2.1.852 include these two lines:

Logging was optimized to prevent excessive log file growth during attempts to back up unreadable cloud-based files.

Excessive and incorrect logging was resolved, reducing log file bloat and improving performance.

If you suspect that Backblaze may be consuming unnecessary disk space, here’s how to check and, if necessary, discover your version of Backblaze and update manually:

  1. In the Finder, choose Go > Go to Folder and paste in this path: /Library/Backblaze.bzpkg/bzdata/bzlogs. Feel free to delete the log files (not the enclosing folder) manually to recover the space immediately.
  2. Choose About from the Backblaze menu in the menu bar, and check your version number.
    Backblaze version dialog
  3. If it’s below 9.2.1.852, visit the Update Backblaze page to download and run the current installer. No other changes or uninstallation are needed.

I’m on Version: 9.0.2.806, a few beats shy of your .852 My log folder is small, 251MB.

However, my bzbackup folder is now largest one at 30GB one with two large files/folders inside … bzfileids.dat at 5.6G and bzdatacenter folder at 25GB. These seem to be a record of all of my backups and as I recall should not be deleted.

I seem to have 9.0.1.768 installed. If I go to the folders you mentioned, the larger directory seems to only have a total size of 1.5 GB. I have 2 TB of SSD storage on my MBP. So it seems everything is ok without doing anything?

Not BackBlaze, but the in the same vein for Arq:

Why should an app be dependent on old log files? That doesn’t make any sense. Or the developers are like weird. I would have just deleted the old logs and then contacted support.

1 Like

I just discovered this yesterday when my Time Machine backup failed due to lack of space. I discovered my Backblaze.bzpkg/bzdata/bzlogs/bztransmit folder contained multiple bztransmit.log files. Each one was about 125GB and totaled to 2.9TB of space. My SSD in my iMac is only 4TB and while trying to figure out what the heck was going on I was getting errors due to lack of space on this drive too. I couldn’t even open any of the logs. Console and TextEdit just hung when trying to open one of them. I eventually was able to read one and it was referencing files I deleted from my Mac years ago and files on an external drive I had specifically excluded from being backed up. I’ve been using Backblaze for years in a set it and forget it fashion. This incident has seriously shaken my confidence in their product and their support as I heard nothing about this problem from them and had essentially figured it out on my own and deleted the log files and then updated to the new version I found on their website. I sent an email to support who just confirmed what I had already done was the solution. Hopefully. Unfortunately my Time Machine backup is now just a few days of history instead of the months I had before as it kept making room for my larger and larger files.

Wow, that’s awful.

This whole incident comes across as very bad behaviour from Backblaze as a company.
Having backup software that has this ‘storage sucking-up’ issue going back months (years?) without them either realising nor thinking that it just maybe a MASSIVE problem for its users’ machines, is utterly ridiculous.

Their attitude comes across as ‘meh’ and unbothered too, which speaks volumes about them as a company IMO.

Why is this issue seemingly the same across backup companies software, one wonders.

What did Arq say about this? What did you do to fix this?

I haven’t had the problem for years. Looks like the large log files started occurring recently. There were 20 or so in that folder at 125GB each. Honestly this is the first time I’ve had any problems with Backblaze. Although I will admit besides using it retrieve the occasional individual file, I’ve never had to try to restore with it. Thankfully my local backups are all I’ve ever needed.

I don’t think there was any implication that the app is dependent on the log files—it’s just that it keeps the last month’s worth. I certainly could have deleted the logs without looking into it further, but whenever I encounter a problem, I treat it like a puzzle that, when solved, may inform an article to help others. I wanted to see if the beta would do what it promised, and I didn’t need the space back.

You’re enough behind the current version that something must be blocking automatic updates. Regardless of the log issue, I would strongly recommend updating so you’re running current code. Who knows what else they may have fixed in the interim?

BBEdit is my go-to app when I need to open very large files. It works fine in free mode.

That was very much not my experience. I received a reply to my initial message within two hours, and while that was more generic, I learned more about what was going on the next day and sent an additional question. Again, I heard back within a few hours with more details and a link to the beta that solved my problem. I won’t say it was the best support I’ve ever gotten, but it was well above the bar.

Sure OK, maybe they were better than I understood from the article and others forum comments.

Although, they seemingly didn’t realise this was an issue very quickly, and let users build-up huge storage repositories without comment, before this beta appeared.

Anyway, it’s interesting how Arq has the same/similar issue… so is this some internal component many backup services use, one wonders?

It’s showing that I’m backed up as of about a half hour ago.

image

Oh you probably meant automatic updates of the app. OK, just did that successfully. Thanks.

1 Like

I feel stupid for asking - Where is the Update Backblaze page? You mean on their website? I looked at the application and did not find a “update” selection. Many apps have that. Also, I seem to not be updating automatically as others are also showing. Is there a selection to turn that feature on?

I found out how to update. You click on the backblase icon in your menu bar, and underneath is check for updates. I was launching the Backblaze App and could not find anything regarding updates. Still don’t know why it is not updating automatically.

1 Like

I’ve been using Backblaze for years, and have been a strong advocate for their backup product and B2 services. But they have efficiently destroyed that loyalty.

I am unable to upgrade the app since it requires a case-insensitive filesystem now.

Their support agent suggested that I simply reformat the drive. That’s about as “meh” as support can get.

I have requirement for case-sensitive file system, so reformatting isn’t an option.

Yes, something was blocking automatic updates - a case-sensitive filesystem.

It’s hard for me to express how disappointed I am with Backblaze at present.

When an application requires a case-insensitive file system to operate; it points to incapable developers (or at best lazy developers). Backblaze no longer cares about their users. :disappointed_relieved:

That’s interesting.
Presumably you use the “APFS (Case-sensitive)” or “APFS (Case-sensitive, Encrypted)” option on your Mac then? What’s the reason for that, out of interest?

Does seem strange for Backblaze to require case-insensitive – though it’s obviously likely to be a duplicates issue somewhere which they can’t deal with for {reason(s)}. Annoying for users like you, I’m sure, especially if it’s a recent requirement they’ve just introduced.

Yes, it’s “APFS (Case-sensitive)”.

It’s a legacy requirement for a development environment that has file names that only differ by case. (head vs HEAD is one example).

I have run into other apps which require case-insensitive filesystem, so I have a separate case-insensitive volume I can install those on to. But Backblaze requires the system volume, so it still can’t be installed.

“which they can’t deal with for {reason(s)}” is another way of saying incapable or lazy developers.

My system volume has been case-sensitive for longer than I’ve been using Backblaze. I rebuilt my system around a year ago and Backblaze installed just fine at that time. So it’s a requirement they have introduced in the interim.

It’s more than “annoying”. If they are unwilling to remove that requirement, I’ll have to look for another cloud backup solution. Never updating backup software because their developers are too incapable or too lazy to resolve internal app issues isn’t acceptable.

I switched from CrashPlan to Backblaze many years ago, because the attitude of the company was anti-users. I’m really sad to see Backblaze doing the same thing.

My bzdata files total 19GB and go back to 2023 which is when I had to reinstall BackBlaze. These seem to be lists of files that are backed up each day. I don’t see why they are kept, it would be useful to keep a list of all files that have been backed up, so the files for the current day can be determined. They have to keep the details of all your files on their server so that they can be recovered if your disk fails.

Mgmt complacency again. Without wanting to sound overly cynical, it’s becoming a problem seen almost everywhere these days across companies and organisations.

This becomes more apparent in companies that basically own their market segment. And IMO home backups are essentially owned by Backblaze, as no one offers anywhere near the same type of service: TB’s of backup for one affordable fixed monthly cost. Hence their popularity.

Oh well, thanks for the insight – hope you find something that works for you.

Ach, my mistake! I was publishing late at night on the WWDC keynote day and apparently I forgot to add the link. It’s in the article now.