WARNING! Backblaze now ignoring Dropbox

Hi All,

I started writing this as a question, but in between starting and finishing I’ve received a response from Backblaze which has answered my question but left me alarmed and disappointed.

The original question:

I have long used Dropbox as my central data store. On both my desktop Mac and laptop Mac I have a Dropbox folder which just sits on my desktop (Macs are on 10.14.6 and 12.7.6 for various reasons of retaining compatibility with older software; I know this location is no longer permitted under current MacOS versions, except weirdly if you use migration assistant to move an old Mac with Dropbox in this location to a new Mac, it preserves that location and Dropbox continues to work - a topic for another day…)

Everything goes into Dropbox - it is effectively my ‘home folder’.

For backup, Backblaze on the desktop Mac backups everything, including the desktop (and so Dropbox) to Backblaze’s online backup.

Or at least, it did. And I know it worked because in the past I’ve recovered files from there and know I had to look in the Dropbox folder on Backblaze to find the files.

In checking something on Backblaze today, I discovered that there now is NO Dropbox folder in my Backblaze backup.

This is alarming on two major counts:

  • no current backup of most of my files, since who knows when this stopped working
  • no backup of any files that have EVER been backed up from the Dropbox folder, despite paying for Backblazes’s ‘permanent’ backup option. The backup that was there has just vanished.

On a new Mac with Dropbox on the desktop (the aforementioned migration-assistent-ed Mac), I set up a new Backblaze test account. Sure enough all of the folders were quickly backed up except the Dropbox folder.

This is odd. And just to be clear this is not related to Backblaze backing up Dropbox ‘online only’ files or Backblaze failing to backup Dropbox from its new Apple-mandated location.

It appeared that Backblaze was now just not backing up Dropbox AT ALL, and was discarding (without warning) existing backups of Dropbox folders.

I contacted Backlbaze tech support. Janet their ‘AI Agent’ who is “well-trained to answer your questions” (!!), responded an hour or so later saying that Backblaze now basically do not back up Dropbox as of a recent update to the Mac Backup software. From the reply email:

“This issue is likely related to recent updates in our Mac Backup Client. Recent versions now automatically exclude cloud-synced folders like Dropbox to prevent performance issues and excessive data usage.

“The Backup Client now detects and excludes cloud-mounted folders because recent macOS versions can mount cloud storage in local paths, causing the client to mistakenly back them up. This change was implemented to avoid restore complications and reduce data usage.”

The reply does not touch upon the existing Dropbox folder being removed from the backup without warning.

Working back through the Backblaze release notes, this change happened in 9.2.2.878. The release notes page does not include release dates for software versions, so there is no way of telling when this change happened.

This is a big problem to me. This is a fine sync/backup strategy I have relied on since starting to use two Macs more than a decade ago and it’s worked really well first with Crashplan then later with Backblaze when I switched to it after Crashplan decided it didn’t seem to care about individual users. It’s now broken - and broken without any warning. If I hadn’t discovered this by accident today, I might not have found out until too late. I suspect this is why I haven’t managed to find more outcry about it on the web today - I suspect this applies to a lot of people, who know this has been working fine and haven’t yet noticed that it’s now broken. Yes, it’s in the release notes, but a change like this should, I feel, be displayed VERY PROMINENTLY as part of an update, or an update causing a change this dramatic should not be forced on users automatically.

More particularly, I have lost all faith in Backblaze, which is a problem because faith is perhaps the most critical part in the relationship between users and their backup suppliers.

(Note: there is also a Time Machine backup of this data, so not an immediate crisis, but…)

Really this is a warning. If you have a setup like this where you use Dropbox to share files between devices and have it backing up to Backblaze, check immediately, because you almost certainly no longer have a backup (despite Backblaze’s website still being littered with articles about how well Backblaze and Dropbox complement each other…)

Sorry to be the bearer of bad news.

Rob.

Here’s something to try. What happens if you use Carbon Copy Cloner or SuperDuper to make a duplicate to an external drive—and then point Backblaze at that drive?

If that doesn’t work because Backblaze was excluding the necessary path in a hard-coded fashion even when it was on the external drive, you could use something like ChronoSync to copy all your Dropbox files to a different spot in the hierarchy on the external drive. Then Backblaze wouldn’t know they were related to Dropbox in any way.

This doesn’t completely surprise me. In the past, I’ve had issues with both Backblaze and Carbonite that were traced to issues regarding including the Dropbox folder in my backup.

As I understand it, the underlying issue relates to how cloud sync/backup services track when files have changed and thus need backed up. Suppose Service A checks metadata B to see if a file is changed, and marks metadata C to indicate that the changes have been backed up.

If Service D then identifies metadata C as indicating a change to that same file, and marks something in metadata B to indicate that it has been backed up, you now have a loop that the same file keeps getting continuously identified as changed and in need of backup. Service A will back it up, then Service D will back it up, then Service A, then Service D, and back and forth repeatedly, despite no actual changes to the file from the user’s end.

Conversely, if both Service A and Service D use metadata B to indicate a changed file and metadata C to mark it as backed up, whichever service sees the change to metadata B first will back it up and mark metadata C—and the other service will fail to back it up, because C tells D that the changes have already been backed up.

This is a grossly oversimplified explanation of how the problem happens; there are other ways that services track files, in a multitude of combinations. But it ultimately comes down to one service’s actions confusing another service’s software, causing files to either be unnecessarily retransmitted repeatedly or not get backed up when they should.

There are really only two ways to avoid this happening. One is to have filesystem/OS-level functionality incorporated to support multiple backup services not interfering with each other—a complicated prospect at best. (I believe that this kind of OS-level support allows Time Machine to not cause issues with third-party backup systems, but it also may simply be a difference between cloud backup and local backup.) The other is to ensure that only one service is set to back up any particular file. This latter approach is what Backblaze has decided to do.

That said, I think it’s a massive failure of customer support for Backblaze to not make it crystal clear to users that Dropbox folders would be completely excluded from backups, including removing them from existing backups. It could be as simple as popping up a warning dialog upon detecting a Dropbox folder for the first time after the update that excluded Dropbox folders from backups, and any time thereafter when a new Dropbox folder appears.

Hey Adam,

Yes, all valid, and Backblaze themselves offer a variation on this in their AI reply:

”Your options:

Copy important files from Dropbox to a regular local folder (like Documents) where Backblaze can back them up normally
Keep Dropbox files protected through Dropbox’s own backup while letting Backblaze handle your other files”

But it’s not the same thing, because it involves a whole other process, and a whole other drive. Keep in mind that Dropbox is effectively my ‘home’ folder - everything, with a very few deliberate exceptions, lives in there. The frustration is that it is not causing any more resource usage at the Backblaze end than if it was just in a folder called ‘Rob’s Stuff’. And MUCH more alarmingly, that they appear to have deleted the existing on-line backup of that Dropbox folder with no warning at all. That, to me, is not acceptable - my Backblaze backup currently contains effectively nothing, rather than the effectively everything it used to contain.

What’s also interesting and needs further investigation is that I have another folder on my desktop called ‘Incoming’. That’s just a standard Mac folder, except for a custom icon. It has no connection to any online file or syncing service, and is not related to Dropbox in any way. It’s the folder I use to dump stuff in to that arrives usually as email and needs attention. Backblaze are also excluding that, and cite the same reason.

It feels to me very much like Backblaze have just created a list of folder names that sound like they’re on-line service related, and are excluding based on name. If true, that feels amateurish at best. I might try your approach, to a folder on an external drive that is still called ‘Dropbox’, to see whether that then gets backed up or not.

But not really what I wanted to be spending Christmas doing…

Rob.

Marquelle,

Yes, understood. But the issue from my point of view is that this has been working just fine and without issue for ten years or more - so while there are complications, none of them have impacted me. It’s ‘just worked’ in the best possible way (albeit that it has become problematic as you add things like Dropbox ‘online only’ files into the mix).

As I’ve just said to Adam, from my perspective I use Dropbox effectively as my ‘home’ folder - everything is in there. If that same data was in my home folder, Backblaze would back it up quite happily. There is no more data or resource involved to them in it being in the Dropbox folder - it’s just a different folder on my desktop, so the reasoning they’re offering feels poor.

That’s their decision, of course. But as you say having made it, they need to tell people - it is a major change. And they probably need to remove all the ‘we play nicely with Dropbox’ material that is still all over their website, eg this:

But even given that they’ve made this decision, just removing the entire backup of all of my data (including of course previous versions of files, and deleted files - I pay for the Backblaze ‘permanent’ storage option) at all, let alone without any warning or recourse, is disasterous. I no longer trust them.

Rob.

I don’t know how reliable this link is (I found it via DuckDuckGo AI after Perplexity—and this is a good thing—said it didn’t have an answer) but if accurate, the change probably happened prior to October of this year.

So to save others having to look, prior to 10th October 2025. That feels plausible. I’ve been away from the desktop Mac for a few weeks over that period but have come back to it asking for permissions that it already has, which was probably related to the same thing.

Rob.

Interestingly, the Backblaze Windows release notes for the same version include an additional comment that is revealing:

“This change aligns with Backblaze’s policy to back up only local and directly connected storage.”

So it becomes about how you consider Dropbox. I’ve always considered it ‘local’ storage, that has the magic property of simultaneously being available in other places.

I wonder if the ‘extra resource’ they’re talking about is of backing up the massive files from others that often end up in your Dropbox (ie. the shared folder for a work project).

But I’d argue that that if I have it set to sync to my Mac, it’s still local to my Mac. After all if I chose to copy it directly onto my hard drive, then it WOULD be local and BB WOULD back it up.

Rob.

The thing is, unless you have been repeatedly checking every file’s backup on both Dropbox and Backblaze, you don’t really know that you’ve had no issues. And unless you actively track Dropbox’s and Backblaze’s activity on your system, you don’t know that there hasn’t been excessive resource usage. These problems are generally invisible to users until they build to a massive failure level.

I’m betting that the recent change in Backblaze’s cooperation with Dropbox stems from a change made by Dropbox, one that’s just as invisible to users as Backblaze’s change was. If Dropbox doesn’t care how nicely they play with other services (and I believe that they don’t), Backblaze will be constantly having to make changes to their software to keep up with anything Dropbox does.

Based on my own multi-year experience with Dropbox, I don’t recommend using them as a mass data dump anyway. I found that the more data I synced with them, the more their software struggled to keep up, non-linearly. As Backblaze themselves point out, Dropbox isn’t intended to be a comprehensive backup solution—their concept has always been about portability and access.

I use Dropbox currently only for files that I want to be readily accessible from any device (which basically means my Scrivener documents, guitar tablature, and assorted reference documents). I used to also use them for allowing others to access certain files remotely (as an alternative to Google Drive), but I’m no longer involved in any projects that require that.

Does Backblaze also no longer backup iCloud Drive or iCloud Photos Library for the same reasons?

I stopped using Backblaze a year or two ago so my interest is curiosity rather than necessity.

I wonder if Crashplan is doing anything similar?

I wonder if Backblaze’s change is related to the massive fairly recent change which applied to all third party storage with the move to using the File Provider extension as this article.

Hey Marquelle,

I’m not using Dropbox as ‘backup’, but rather as an easy way of syncing between two devices (a big desktop Mac and a laptop). Any ‘backup’ properties using it provides are a bonus, with Backblaze then (historically) providing an actual backup.

What’s interesting is that I didn’t used to use two Macs, but rather just a laptop that plugged into a big screen at home. There were a lot of good reasons at the time (~2015) for moving to two computers, but since it’s also nearly new computer time, this does also revive the ongoing two machines vs one debate. I’d still need Dropbox in some form for shared work files and for sharing files with others, but my ‘stuff’ could then live outside it and so be backed up via Backblaze or other similar providers.

Rob.

Rob,

Have you considered Maestral as an alternative Dropbox sync client?

I think it permits specifying any local pathname as the Dropbox folder. Backblaze might back up this folder without complaint.

I hope this helps.

–Brian

Hadn’t started investigating options yet, but thanks for the tip, I’ll take a look.

Other things overnight:

  • Release date for 9.2.2.878 Bacblaze are saying was Sep 1st, so Dropbox (and probably other cloud/file syncing services) backup would have stopped whenever after that point your system downloaded that version.
  • Backblaze are saying that while they have stopped backing up Dropbox folders, “to be clear, the Dropbox backup has not been deleted per se, but rather it has ceased to be backed up starting on version 9.2.2.878”. Unfortunately this is not what I am seeing in my Bacblaze > Restore file hierarchy (where there is no Dropbox folder), and not what a friend of mine is seeing in his similar set-up (again, no Dropbox folder). I am highly confident that the Dropbox folder and all of its content previously existed in my Backblaze, he is highly confident it previously existed in his Backblaze.

It’s possible, I guess, that the data is still in Backblaze but is just not being presented by the Restore option…. but it doesn’t really matter, since I can’t get at this data either way.

Rob.

I suspect it’s all cloud based services. The release note about the new exclusions says:

“(for example, Google Drive, OneDrive, and Dropbox) “

Crashplan: their on-line guidance is unclear. For example, they talk about how the ~/Library folder (which is Apple’s new enforced home for Dopbox) is excluded from their backups ‘by default’, but it’s not then clear whether you can over-ride that setting to force it to be backed up. We’ve emailed them to ask directly but have not heard back yet.

Rob.

I suspect it’s all cloud based services. The release note about the new exclusions says:

“(for example, Google Drive, OneDrive, and Dropbox) “

Crashplan: their on-line guidance is unclear. For example, they talk about the ~/Library folder (which is Apple’s new enforced home for Dopbox) is excluded from their backups ‘by default’, but it’s not then clear whether you can over-ride that setting to force it to be backed up. We’ve emailed them to ask directly but have not heard back yet.

Pretty sure you can override the defaults on both CrashPlan and Backblaze.

Is it possible the problem you are seeing is that Backblaze now by default excludes the ~/Library/CloudStorage (which now includes Dropbox etc) ?

If so have you tried removing it from the default exclusions?

Incidentally the iCloud Photos Library is not located in the ~/Library so would not be excluded if this is the situation.

EDIT: Reinforcing the above, the AI summary gives:

AI Overview

Backblaze often struggles to back up Dropbox on Macs due to Dropbox’s move to Apple’s File Provider system, which places the folder in

~/Library/CloudStorage, a location Backblaze typically excludes by default. The solution involves manually telling Backblaze to include the Dropbox folder within CloudStorage by adding it to your backup settings, ensuring files are fully synced and available offline first, and sometimes contacting Backblaze support for advanced help.

Main Reasons for the Issue

  • Location Change: The latest Dropbox update moved the folder to /Users/YOUR_USERNAME/Library/CloudStorage/Dropbox, which is often excluded in Backblaze settings.
  • File Provider System: This new system uses special file tags that can make files seem like they aren’t fully downloaded, confusing backup apps.

How to Fix It

  1. Ensure Files are Fully Synced: Before backing up, make sure all your Dropbox files are marked as “Always available offline” within the Dropbox app.
  2. Add the Dropbox Folder to Backblaze:
  • Open Backblaze System Preferences.
  • Go to Backup Settings.
  • Click Change Selection.
  • Navigate to /Users/YOUR_USERNAME/Library/CloudStorage/ and manually select the Dropbox folder to include it.

Hey Mike,

The installation that is failing is on an older Mac running, for various reasons of old software compatibility, an older OS - 10.14.6. That version doesn’t force Dropbox to a new location, so my Dropbox folder is an actual folder sitting on my desktop. It is configured as that in Dropbox, and continues to sync correctly to Dropbox on other devices. We’ve seen the same issue on another Mac of similar vintage/OS with a similar setup.

If I go to Backblaze Prefs > Settings > Exclusions and try to add any of the folders that Backblaze excludes by default (including /Library) I get a ‘Backblaze does not allow backing up the Library folder’ error.

So Backblaze are not rejecting the Dropbox folder based on file location, but on some other (as yet unidentified) criteria, which could be as simple as its name…

Rob.

(Interestingly, I have one new M4 MacBook Air in the family, which we setup using Migration Assistant from an older Mac. On that device, Migration Assistant has put the Dropbox folder in the same place as it was on the previous machine, ie a folder on the desktop. This does seem to be syncing properly, so has somehow broken Apple’s rules on the location of the Dropbox folder…)

Thanks Rob. Understand.

You have implied that all files are fully downloaded so have local copies, no smart sync, so I don‘t have any more ideas. Have Backblaze Support commented on your specific situation?

Incidentally I think BackBlaze will allow you to remove the user Library (~/Library) from exclusions, but not the /Library.

Mike,

Yes they have - see earlier replies of mine, but in short as of a Backblaze update of early September they are now deliberately NOT backing up Dropbox or similar cloud/syncing services.

They’ve then said they’re no longer backing up these folders, but existing backups of this data should be in place. This is not the case with me or a colleague of mine where the Dropbox folder that we’re both sure used to exist in our Backblaze backups is just no longer there. Waiting for a response to that (which to me is the most alarming part) from Backblaze.

Rob.

Rob,
Yours is an old configuration with an unusual location for the Dropbox folder. I can’t explain why you are having the problem, but can’t help feeling that if this was an across-the-board recent change by Backblaze, including all current Macs and OSes, there would be widespread dismay, of which I can’t find any evidence.

Googling “Backblaze can’t backup Dropbox” only finds the expected problems where Backblaze can’t backup Dropbox because local full size copies don’t exist so can’t be backed up. This is the same problem of course for any cloud files and any backup method.

Mike,

My reaction was exactly the same as yours lat night, particularly with regard to the lack of online controversy.

But Backblaze are now being very clear that this is a change.

I suspect - and worry - that people who’ve used this setup for a long time and know it was working, have just not noticed it’s no longer working because this big change was made with no fanfare. I fear they won’t find out until they come to need that backup and find it’s just not there…

Rob.