Reviews

A follow-up to my review of Google’s Backup and Sync

I reviewed Google’s Backup and Sync service back in December. There were several issues with the service that I outlined in there, such as the app backing up files that it was not supposed to back up, the service counting files toward the quota even though it was supposed to compress them and allow unlimited free storage, etc. I thought I’d do a follow-up because, as you may have guessed already, there are more issues I want to point out and also a few pieces of advice that might help you in your use of the app.

One issue that occurs over and over is that the app crashes. It gives an error message popup and says it needs to quit. Which is somewhat okay, but when you start it back up, it does a re-check of all the files it’s supposed to back up, and that is an energy-hungry process. You can see it at the top of the active apps in Activity Monitor (on the Mac), eating up all the processor cycles as it iterates through its list of files. And even when it does its regular backup in the background, it’s still climbing toward the top of the active apps. To be fair, Flickr’s own Uploadr is also an energy-hungry app. Neither of the apps allow you to make them use less energy (to work slower, etc.), so they churn away at your computer’s resources even though they’re supposed to work quietly in the background.

Another issue that still occurs is that the app backs up files that it’s not supposed to back up. I have it set to back up only photos and videos and yet it backs up a lot of files with strange extensions that end up counting toward my storage quota on Google Drive. Have a look at the screenshots taken from my settings for the app below.

I had it set on backing up RAW files too, but it wasn’t backing up anything but CR2 (Canon RAW files) and DNG (Adobe RAW files, or digital negatives). And it had problems backing those up as well, because when the size of a DNG file was over a certain limit (it’s somewhere around 50 MB I think), it backed it up but it didn’t compress it, so it counted toward the storage quota.

It wasn’t compressing ORF (Olympus Raw files) while backing them up, so they counted toward my quota. Since I shoot only with Olympus gear these days, that was no good to me. So what I did is I chose not to let it back up any RAW files and I set my camera to shoot in ORF + JPG format. I work with the ORF files in Lightroom and the unedited JPG files get backed up with the app.

Here’s a list of files whose extensions it might be helpful for you to add to its settings, so the app won’t put them on your Google Drive. Of course, as mentioned above, the app backs up all sorts of files it’s not set to back up. It’s like it ignores the settings and just does what it wants, so ymmv.

  • cmap
  • data
  • db
  • db-wal
  • graphdb
  • graphdb-shm
  • graphdb-wal
  • heic
  • heif
  • ithmb
  • lij
  • lisj
  • orf
  • plist
  • psd
  • skindex
  • tif
  • tmp
  • xmp
  • zip

You may have noticed HEIF and HEIC in the list above. Those are the new image and video standards used by Apple because they offer much higher quality and compression than JPG and H.264. And even though it’s not logical that Google wouldn’t know or want to compress them and back them up properly, they don’t. The app will simply copy them to Google Drive, uncompressed, and they’ll count toward your quota. So all of you who have iPhones and iPads and use the Backup and Sync app or the Google Photos app, you are currently backing up the photos taken with your devices on Google Drive, but they count toward your storage quota even if you don’t want them to. Keep in mind that this may be a temporary thing and Google may choose to rectify this issue in the coming months.

The storage options on Google Drive are another issue I want to talk about. I had to upgrade my storage to 1 TB because of all these issues. At one point, I had over 400GB of unexplained files taking up space in there and I had to upgrade to the 1 TB plan, which costs $10/month. Now I don’t know about you, but that pisses me off. It’s one thing if I choose to upgrade my storage plan because I want to do it, and it’s another thing altogether to be forcibly upsold because the Backup and Sync app might be used as a funnel to generate gullible leads for Google Drive’s storage plans. Notice I said “might be”; I have no proof of this. It could be that the app is just full of bugs and not well-maintained.

So I did two things: one was to downgrade my storage plan to the minimum of 100 GB at $2/month, and the second was to start looking through my Google Drive in order to see what files were taking up space. I found them but let me tell you, getting rid of them is like pulling teeth. It’s like Google doesn’t want you to get rid of them, so they keep on taking space there and you keep on paying. It’s not right. Let me show you: first you go to Google Drive, and at the bottom of the sidebar on the left, you’ll see how much space you’ve got. My storage quota is under control now, but this is my second day of working on this. Can you believe it? Google has made me waste almost two work days in order to correct a problem that it created.

If you click right on the space used, in my case the 76.6 GB, it’ll take you to a page where it begins to list all of the files that are taking up space on your Google Drive, in descending order based on file size. Here’s where it might be confusing for some: the files that are compressed and don’t count toward your quote are listed with a file size of 0 bytes. This is not an error, those files aren’t really 0 bytes, but they’ve been compressed and as far as your quota is concerned, they’re okay. The files that do count toward your quota will be listed at the top. That’s how I found out that Google doesn’t compress PSD files or TIF files or large DNG files. I had images that were over 100 MB in size, some close to 1 GB in size, that it wasn’t compressing, so I had to delete those. If you want to bring down your storage requirements on Google Drive, you’ll have to do the same. Here’s a screenshot of the page I’m talking about, but keep in mind that I’ve already done the work, so I have no more uncompressed files taking up space. Whatever’s left, it’s in the Trash.

So this part is like pulling teeth. Even though I was using Google’s own browser, Google Chrome, and working on Google’s own service, Google Drive, it was excruciatingly slow to list the files I needed to delete. The page would only pull something like 50 files to display, and if you wanted to see more, you had to scroll down and wait for it to pull up more… and then the browser would almost freeze and give you a warning to let you know the page was eating up too many resources… ugh… what a nasty thing to do to your customers, Google!

Have a look at the resources Chrome was eating up during this whole thing:

This “fun activity” took up most of my two days. Not only did it work like this when I needed to identify the files that I needed to delete, but once they were in the Trash, that page also worked the same way. In the web browser, it would only pull up about 50 files or so for me to delete at once. Even though the “Empty Trash” option was supposed to clear the Trash of all of the files in it, it would only delete the 50 or so files that it pulled up. Sure, you can scroll down, wait for it to pull up 50 more files, scroll down again, etc. until Chrome gives you a warning that the page isn’t working properly anymore, then you can empty the trash, deleting a few hundred files, then go again and again and again. I tell you, I suspect that Google is doing this on purpose so you don’t clean up your Drive and are forced to upgrade your storage plan…

I looked this thing up, and some people had more luck emptying the trash by using the mobile app (for iOS or Android). I tried it on my iPhone and it hung, then crashed. I tried it on my iPad and it would hang, the little Googley kaleidoscope wheel going on and on for hours, and then it would either crash or keep on twirling. I left my iPad with the app open all night after issuing the Empty Trash command and when I came back to it in the morning, it was still twirling away and the files hadn’t been deleted.

So now it’s back to the browser interface for me until I clean up all the files. See the screenshot below with the twirly blue thing in the middle? That’s me waiting on Google to list those files in the Trash… By the way, I bought a 2 TB storage plan on Apple’s iCloud to back up my phones, tablets and computers, and I can share that plan with my family. It costs the same as Google’s 1 TB plan: $10/month.

Will I keep using the Backup and Sync app? Yes, at least for now. The promise of unlimited storage of all my compressed images is a tempting thing. I realize there’s a loss in resolution and quality but God forbid something happen to my files and my backups, at least I have them stored somewhere else and I can recover them; they might not be their former selves, but I’ll have something.

Just FYI, I back up locally and remotely. For local backups I use Mac Backup Guru and for the remote backups I use Backblaze, which I love and recommend. Their app is amazing: blazing fast, low energy footprint, works quietly in the background and has backed up terabytes of data in a matter of 1-2 weeks for me. And as for my hardware, I still use Drobos and I love and recommend them as well. I’ve been using them since 2007 and while I’ve had some issues, I still think they’re the best and most economical expandable redundant storage on the market. I use a Drobo 5D next to my iMac and two Drobo 5N units on the network.

I hope this was helpful to you!

Standard
Reviews

A comparison of CrashPlan and Backblaze

I’ve been a paying CrashPlan customer since 2012 and my initial backup still hasn’t finished. I’ve been a paying Backblaze customer for less than a month and my initial backup is already complete. 

I’m not a typical customer for backup companies. Most people back up about 1 TB of data or less. The size of my minimum backup set is about 9 TB. If I count all the stuff I want to back up, it’s about 12 TB. And that’s a problem with most backup services.

First, let me say this: I didn’t write this post to trash CrashPlan. Their backup service works and it’s worked well for other members of my family. It just hasn’t worked for me. This is because they only offer a certain amount of bandwidth to each user. It’s called bandwidth throttling and it saves them money in two ways: (1) they end up paying less for their monthly bandwidth (which adds up to a lot for a company offering backup services) and (2) they filter out heavy users like me, who tend to fill up a lot of their drives with unprofitable data. My guess (from my experience with them) is that they throttle heavy users with large backup sets much more than they throttle regular users. The end result of this bandwidth throttling is that, even though I’ve been a customer since 2012 — at first, I was on the individual backup plan, then I switched to the family plan — my initial backup never completed and I was well on track to never completing it.

When I stopped using CrashPlan’s backup services, out of the almost 9 TB of data that I need to back up constantly, I had only managed to upload 0.9 TB in FOUR YEARS. Take a moment and think about that, and then you’ll realize how much bandwidth throttling CrashPlan does on heavy users like me.

Screen Shot 2016-10-20 at 23.37.07.png

After four years of continuous use, I backed up a grand total of 905.7 GB to CrashPlan

To be exact, counting the various versions of my data that had accummulated on the CrashPlan servers in these four years, I had a total of 2.8 TB stored on their servers, but even if you count that as the total, 2.8 TB in FOUR YEARS is still an awfully small amount.

Screen Shot 2016-10-27 at 00.42.14.png

Space used on CrashPlan’s servers: 2.8 TB

Tell me honestly, which one of you wants this kind of service from a backup company? You pay them for years in a row and your initial backup never finishes? If a data loss event occurs and your local backup is gone (say a fire, flood or burglary), you’re pretty much screwed and you’ll only be able to recover a small portion of your data from their servers, even though you’ve been a faithful, paying customer for years… That just isn’t right.

I talked with CrashPlan techs twice in these fours years about this very problematic data throttling. Given that they advertise their service as “unlimited backup”, this is also an ethical issue. The backup isn’t truly unlimited if it’s heavily throttled and you can never back up all of your data. The answer was the same both times, even the wording was the same, making me think it was scripted: they said that in an effort to keep costs affordable, they have to limit the upload speeds of every user. The first time I asked them, they suggested their Business plan has higher upload speeds, so in other words, they tried to upsell me. During both times, they advertised their “seed drive service”, which was a paid product (they stopped offering it this summer). The gist of their paid service was that they shipped asking customers a 1 TB drive so you could back up to it locally, then send it to them to jumpstart the backup. Again, given my needs of backing up at least 9 TB of data, this wasn’t a userful option.

Screen Shot 2016-10-31 at 15.57.25.png

This is false advertising

Screen Shot 2016-10-31 at 15.59.41.png

This is also false advertising

Some of you might perhaps suggest that I didn’t optimize my CrashPlan settings so that I could get the most out of it. I did. I tried everything they suggested in their online support notes. In addition to tricking out my Crashplan install, my computer has been on for virtually all of the last four years, in an effort to help the Crashplan app finish the initial backup, to no avail.

Another thing that bothered me about CrashPlan is that it would go into “maintenance mode” very often, and given the size of my backup set, this would take days, sometimes weeks, during which it wouldn’t back up. It would endlessly churn through its backup versions and compare them to my data, pruning out stuff, doing its own thing and eating up processor cycles with those activities instead of backing up my data.

Screen Shot 2016-10-22 at 19.40.33.png

Synchronizing block information…

Screen Shot 2016-10-23 at 14.39.36.png

Compacting data… for 22.8 days…

Screen Shot 2016-10-23 at 16.58.23.png

Maintaining backup files…

I understand why maintenance of the backups is important. But what I don’t understand is why it took so long. I can’t help thinking that maybe the cause is the Java-based backup engine that CrashPlan uses. It’s not a Mac-native app or a Windows-native app. It’s a Java app wrapped in Mac and Windows app versions. And most Java apps aren’t known for their speed. It’s true, Java apps could be fast, but the developers often get lazy and don’t optimize the code — or that’s the claim made by some experts in online forums.

Another way to look at this situation is that CrashPlan has a “freemium” business model. In other words, their app is free to use for local (DAS or NAS) backup or offsite backup (such as to a friend’s computer). And one thing I know is that you can’t complain about something that’s given freely to you. If it’s free, you either offer constructive criticism or you shut up about it. It’s free and the developers are under no obligation to heed your feedback or to make changes because you say so. As a matter of fact, I used CrashPlan as a free service for local backup for a couple of years before I started paying for their cloud backup service. But it was only after I started paying that I had certain expectations of performance. And in spite of those unmet expectations, I stuck with them for four years, patiently waiting for them to deliver on their promise of “no storage limits, bandwidth throttling or well-engineered excuses”… and they didn’t deliver.

Here I should also say that CrashPlan support is responsive. Even when I was using their free backup service, I could file support tickets and get answers. They always tried to resolve my issues. That’s a good thing. It’s important to point this out, because customer service is an important aspect of a business in the services industry — and online backups are a service.

About three weeks ago, I was talking with Mark Fuccio from Drobo about my issues with CrashPlan and he suggested I try Backblaze, because they truly have no throttling. So I downloaded the Backblaze app (which is a native Mac app, not a Java app), created an account and started to use their service. Lo and behold, the 15-day trial period wasn’t yet over and my backup to their servers was almost complete! I couldn’t believe it! Thank you Mark! 🙂

I optimized the Backblaze settings by allowing it to use as much of my ISP bandwidth as it needed (I have a 100 Mbps connection), and I also bumped the number of backup threads to 10, meaning the Backblaze app could initiate 10 separate instances of itself and upload all 10 instances simultaneously to their servers. I did have to put up with a slightly sluggish computer during the initial backup, but for the first time in many years, I was able to back up all of my critical data to the cloud. I find that truly amazing in and of itself.

Screen Shot 2016-10-14 at 21.36.27.png

This is what I did to optimize my Backblaze installation

As you can see from the image above, I got upload speeds over 100 Mbps when I optimized the backup settings. During most of the days of the initial upload, I actually got speeds in excess of 130 Mbps, which I think is pretty amazing given my situation: I live in Romania and the Backblaze servers are in California, so my data had to go through a lot of internet backbones and through the trans-Atlantic cables.

The short of it is that I signed up for a paid plan with Backblaze and my initial backup completed in about 20 days. Let me state that again: I backed up about 9 TB of data to Backblaze in about 20 days, and I managed to back up only about 1 TB of data to CrashPlan in about 4 years (1420 days). The difference is striking and speaks volumes about the ridiculous amount of throttling that CrashPlan puts in place for heavy users like me.

I also use CrashPlan for local network backup to my Drobo 5N, but I may switch to another app for this as well, for two reasons: it’s slow and it does a lot of maintenance on the backup set and because it doesn’t let me use Drobo shares mapped through the Drobo Dashboard app, which is a more stable way of mapping a Drobo’s network shares. CrashPlan refuses to see those shares and requires me to manually map network shares, which isn’t as stable a connection and leads to share disconnects and multiple mounts, which is something that screws up CrashPlan. I’m trying out Mac Backup Guru, which is a Mac-native app, is pretty fast and does allow me to back up to Drobo Dashboard-mapped shares. If this paragraph doesn’t make sense to you, it’s okay. You probably haven’t run into this issue. If you have, you know what I’m talking about.

Now, none of this stuff matters if you’re a typical user of cloud backup services. If you only have about 1 TB of data or less, any cloud backup service will likely work for you. You’ll be happy with CrashPlan and you’ll be happy with their customer service. But if you’re like me and you have a lot of data to back up, then a service like Backblaze that is truly throttle-free is exactly what you’ll need.

Standard