{"id":8861,"date":"2014-05-22T15:20:19","date_gmt":"2014-05-22T19:20:19","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=8861"},"modified":"2025-01-07T11:50:42","modified_gmt":"2025-01-07T16:50:42","slug":"what-backblaze-doesnt-back-up","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2014\/05\/22\/what-backblaze-doesnt-back-up\/","title":{"rendered":"What Backblaze Doesn’t Back Up"},"content":{"rendered":"

Arq<\/a> recently reported hundreds of GB of missing files, across multiple backup targets. This is so at odds with Amazon Glacier’s reputed 11-nines durability<\/a> that I’m guessing it’s due to an application bug. It would not surprise me if the files are still there; Arq just isn’t seeing them. In any event, my strategy<\/a> is to have multiple cloud backups—Arq and CrashPlan<\/a> (which has been working very well recently)—so this got me thinking about possibly adding a third.<\/p>\n\n

The obvious choice is Backblaze<\/a>. It has a native Mac app, is developed by ex-Apple engineers, and sponsors many fine podcasts.<\/p>\n\n

I’d previously been hesitant about Backblaze because of the way it handles<\/a> external drives<\/a>. I’ve read about problems with large<\/a> bzfileids.dat<\/a> files<\/a> sucking RAM and preventing backups entirely once they get too large. It’s also worrisome that it only retains deleted files for 30 days<\/a>—meaning that a file is truly lost if I don’t notice<\/a> that it’s missing right away. And if, for some reason, my Mac doesn’t back up for 6 months, Backblaze will expunge all my data<\/a>, even if my subscription is still paid-up. The situations in which my Mac is not able to back up for a while are exactly<\/em> the ones in which I (or my survivors) would want to be able to depend on a cloud backup!<\/p>\n\n

My other concern is that Backblaze doesn’t actually back up<\/a> everything<\/a>. It fails<\/a> all but one of the Backup Bouncer<\/a> tests, discarding file permissions, symlinks, Finder flags and locks, creation dates (despite<\/a> claims<\/a>), modification date (timezone-shifted<\/a>), extended attributes (which include Finder tags and the “where from” URL), and Finder comments. Arq<\/a>, CrashPlan<\/a> (as of version 3<\/a>), SuperDuper<\/a>, and Time Machine<\/a> all support all of these. Dropbox<\/a> supports all of them except creation dates, locks, and symlinks<\/a>.<\/p>\n\n

As a programmer<\/a>, I especially care about metadata. But I think most users would as well, if they knew to think about it. For example, losing dates can make it harder to find your files (i.e. they disappear from smart folders or sort incorrectly), even leading to errors (i.e. not finding the correct set of invoices for a time period). You would never use a backup app that didn’t remember which folders your files were in, so I don’t know why people consider it acceptable to lose their Finder tags. (If you use EagleFiler<\/a>, it can restore the tags<\/a> for you.)<\/p>\n\n

Some people don’t care much about metadata. Macworld’s<\/a> survey of online backup services didn’t mention it. Neither did Walt Mossberg<\/a>. (He also told readers that Backblaze automatically includes “every user-created file”; in fact, it skips files over 4 GB<\/a> by default.) [Update (2014-05-25): The Sweet Setup<\/a> doesn’t mention metadata, either (via Nick Heer<\/a>).]<\/p>\n\n

Backblaze has<\/a> a<\/a> stock<\/a> answer<\/a> when asked<\/a> about Backup Bouncer:<\/p>\n\n

This actually tests disk imaging products, a bad test for backup as items we fail on shouldn’t be backed up by data backup service.<\/p><\/blockquote>\n\n

Some people<\/a> accept this explanation. I think it’s misguided and borderline nonsensical. True, Backup Bouncer tests some rather esoteric<\/a> features, but Backblaze fails the basic tests, too. It would be one thing to say that there’s a limitation<\/em> whereby dates, tags, comments, etc. aren’t backed up, but they’re actually saying that these shouldn’t<\/em> be backed up. As if products that do<\/em> back them up are in error. So presumably Backblaze doesn’t consider this a bug and won’t be fixing it.<\/p>\n\n

Lastly, it’s a shame that Backblaze isn’t up<\/a> front<\/a> about what metadata it supports. Some users are technical enough to investigate these things themselves. Others will have read the excellent Take Control of Backing Up Your Mac<\/a> and seen its appendixes<\/a>, which give Backblaze a C for metadata support. But most Backblaze users won’t know that a poor choice has been made for them until they need to restore from their backup.<\/p>\n\n

Update (2017-08-23): A Backblaze employee responded<\/a> to this post:<\/p>\n

Backblaze absolutely backs up and restores the “file creation date” and “file last modified date”. With these two caveats: Backblaze is only accurate down to Milliseconds (1\/1,000ths of a single second) if you restore by USB hard drive restore, and only accurate to the second if you prepare a ZIP file restore. The latter is because that is a limitation of the ZIP file format.<\/p>

The tool “Backup Bouncer” fails Backblaze on this test, and it irritates me. I feel “wronged” by this. The new APFS Macintosh file system has the ability to set the file creation date down to one BILLIONTH of a second, and I assume that just to be totally difficult Backup Bouncer gleefully sets every last bit.<\/p><\/blockquote>\n

I’ve asked for clarification<\/a>, but as far I can tell the response is spreading incorrect information and seems to misunderstand various of the issues involved.<\/p>\n

I started a Backblaze trial in order to verify the claim that the creation date is preserved, but I was unable to get an answer because 4 hours after Backblaze says that it backed up my test files, they were still not showing up in the restore interface, even though it purports to show the latest files as of this minute. After 5 hours, the files were available, I restored them, and the file creation dates were lost and changed to the modification date. The Backblaze restore also messed up the files’ modes, making them executable when they had not been.<\/p>\n\n

Update (2017-08-24): Backblaze support explained to me that it’s normal for there to be a delay, which can be from 1–8 hours<\/a>, before the files are actually available for restore. This is because, although the file data has been sent to the server, the server can’t access the files until the client has sent the index<\/em> that describes the changes. It typically waits a few hours before doing this. What this means is that, during those hours, the Backblaze client reports that the backup is complete (“You are backed up as of: Today, 7:28 AM”), but it’s actually not. If your Mac breaks or goes offline (i.e. you pack up your MacBook for a trip) before the index has been uploaded, it’s as if the backup never happened. I assume the delay before sending the index is some sort of optimization, so perhaps it’s justified, but I consider it a major bug that the client reports the files as backed up when you can’t actually restore them (no matter how long you wait).<\/p>\n\n

The Backblaze employee replied<\/a> about the file creation date issue. The gist of it is that the dates are not preserved when restoring via the network. However, you can pay $99 (flash drive) or $189 (hard drive) for them to mail you your data, and in this format the dates will be preserved. If you mail the drive back<\/a> (sounds like you have to pay shipping) they will refund the cost. I have not verified that this method works, however, I can confirm that the index file that’s sent to the Backblaze server contains the correct information for the creation dates.<\/p>\n\n

Update (2017-09-03): See also: Accidental Tech Podcast<\/a>.<\/p>\n\n

Update (2018-02-05): aikinai<\/a>:<\/p>\n

\n

I started getting emails warning that all of my external drives were offline and my data would be soon deleted. Instead of “Very sorry about that, here’s how to fix the issue,” I got this long response about the ways their system looks for new files in serial and it can get jammed and start ignoring everything, with no apology, no acknowledgement this was their issue, and no solution. I had to go fishing for solutions and drag the information out of them to finally figure out what I needed to do. Which it turns out is to get back an internal drive (totally unrelated to the other drives Backblaze abandoned) I had physically removed and repurposed, put it back the computer, wait a long time for Backblaze to see it, then uncheck that drive in Backblaze and remove it again.<\/p>\n

[…]<\/p>\n

The client will lie to you and you never know what’s really backed up. Even if you use the secret alt-click to force a full drive scan, it can still miss files and tell you fully backed up when files from days ago are still nowhere to be found. Luckily I’ve never actually needed to do a restore, but I almost thought I did one time and would have been furious at all the missing files I noticed.<\/p>\n<\/blockquote>\n\n

Update (2022-03-07): Backblaze<\/a> (via Adam Engst<\/a>, Hacker News<\/a>):<\/p>\n

\n

Backblaze has always kept a 30-day version history of your backed up files to help in situations like these, but today we’re giving you the option to extend your version history to one year or forever.<\/p>\n<\/blockquote>\n\n

Daniel Jalkut<\/a>:<\/p>\n

I recently learned that \n@Backblaze’s 1 year extended backup doesn’t work the way I (or my brother, who ran into this) expected. I thought it was “everything just like 30 days plan - but for a year”. Instead, if you haven’t attached a drive for 30+ days you have to RE-UPLOAD it.<\/p>

So the day is RETAINED for 365 days, but if you have a slow or expensive bandwidth connection, you have to make sure to re-attach drives <30 days or else you have to re-upload. Even though they have the files? Disappointing. My laziness was counting on it behaving otherwise.<\/p><\/blockquote>\n\n

Tim Wood<\/a>:<\/p>\n

\n

I love* it when \n@backblaze\n says I’m fully backed up and I double-check a (non-excluded) file and see it doesn’t show up in the restore interface. Cool.<\/p>\n<\/blockquote>\n\n

Update (2025-01-07): Wade Tregaskis<\/a>:<\/p>\n

For nearly a month now, Backblaze has been fixated on a particular file of mine, that happens to be over 1 TB in size. <\/p>

[…]<\/p>

Admittedly I’m guessing somewhat, since that’s a rather reader-hostile log message, but the combination of the Z_B_TOO_MANY_CHUNKS<\/strong><\/code> error mnemonic and chunkSeq=100001<\/strong><\/code> (because of its proximity to the arbitrary round number 100,000) strongly suggests that Backblaze is imposing a 100,000 chunk limit. Since chunks are 10 MB each, that’s exactly 1 TB.<\/p>

This is unequivocally at odds with what they claim repeatedly on their website, on pages like What Backblaze Backs Up<\/a> and File Sizes<\/a>.<\/p><\/blockquote>","protected":false},"excerpt":{"rendered":"

Arq recently reported hundreds of GB of missing files, across multiple backup targets. This is so at odds with Amazon Glacier’s reputed 11-nines durability that I’m guessing it’s due to an application bug. It would not surprise me if the files are still there; Arq just isn’t seeing them. In any event, my strategy is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2019-12-19T19:59:28Z","apple_news_api_id":"7a5b4eff-58f1-4c15-82b0-5d7a4a619798","apple_news_api_modified_at":"2025-01-07T16:50:45Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAg==","apple_news_api_share_url":"https:\/\/apple.news\/AeltO_1jxTBWCsF16SmGXmA","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[2],"tags":[20,203,534,146,35,692,1902,30,32,608,369,1227],"class_list":["post-8861","post","type-post","status-publish","format-standard","hentry","category-technology","tag-glacier","tag-arq","tag-backblaze","tag-backup","tag-cloud","tag-crashplan","tag-extended-attributes","tag-mac","tag-macapp","tag-metadata","tag-superduper","tag-top-posts"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/8861","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=8861"}],"version-history":[{"count":15,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/8861\/revisions"}],"predecessor-version":[{"id":46338,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/8861\/revisions\/46338"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=8861"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=8861"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=8861"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}