Skip to content
Thoughtful, detailed coverage of everything Apple for 33 years
and the TidBITS Content Network for Apple professionals
A disc in a green cloud.

Photo by mnievesmc

13 comments

CloudBerry Backup for macOS: Feature-Rich but Unreliable

A complete backup strategy involves three types of backups, including:

  1. Bootable Duplicates: making an exact, bootable clone of your internal drive so you can get back up and running as quickly as possible in case of drive or computer failure
  2. Versioned Backups: keeping multiple versions of files as they change in case you need to go back in time
  3. Offsite Backups: copying your data to a place outside your home or office to protect against theft, fire, and flood

Numerous products have emerged over time to fill these needs. A detailed survey of the best of these products and how to assemble them into an overall backup strategy appears in Joe Kissell’s Take Control of Backing Up Your Mac, which also includes an online appendix of tables comparing many other apps.

For bootable duplicates, Carbon Copy Cloner and SuperDuper dominate the Mac world, and ChronoSync can create bootable duplicates in addition to its syncing capabilities. For versioned backups, Time Machine is certainly the most well-known and common solution, but it’s far from perfect. As a result, a category of competing apps has arisen, led by Arq, that can both create versioned backups and store them offsite (see “Roll Your Own Cloud Backups with Arq and B2,” 18 May 2018), obviating the need for an additional Internet-only backup service for offsite backups. Such apps have their quirks, though.

So when CloudBerry Lab approached TidBITS to review CloudBerry Backup for macOS and we read its impressive feature set, we were excited about the possibility of discovering a compelling solution for both versioned and offsite backups. But alas, it seems that dream will have to wait.

An Enticing Feature Set

CloudBerry Backup for macOS is available for free, which serves as a fine way to evaluate the product. But for a mere $29.99, you can get the Pro version, which adds key features such as encryption, compression, email support, and the capability to store more than 200 GB. (That pricing does not include storage, which you will have to obtain elsewhere.) I used the Pro version for my testing.

With a name that plays off cloud-based storage and the cloudberry fruit that’s native to northern Russia, the homeland of several of the vendor’s key employees, CloudBerry immediately impressed with a wide choice of backup destinations.

Cloud services supported by CloudBerry.

My testing centered around Wasabi for cloud-based backup, since I already had an account with Wasabi, and File System, which is the option that lets you back up to a local drive.

CloudBerry offers a standard set of file selection and exclusion options, along with a flexible set of retention parameters to give you control over how long to keep your files and how many versions of each file to keep. Conspicuously missing, however, is the simple option to fill the entire volume before starting to delete old file versions, as Time Machine does by default.

In addition, CloudBerry provides a rich set of scheduling options for controlling the hours and days during which the backup should run and with what frequency. Also conspicuously absent, however, is the simple approach of running “all the time” on an “as needed” basis, as apps like CrashPlan offer.

Options for compression and encryption are available, as well as email notifications for backup completion and some control over the email formatting.

Backups run incrementally, which means that, after the initial backup, CloudBerry only has to back up files that have changed, an essential feature which is standard across the industry these days. It also offers a block-level backup option that provides even finer granularity than incremental backups. If you make a small change to a large file, only the file system block where that change exists, possibly as little as an 8 KB chunk of data, will get backed up, rather than an entire file that could easily be 1000 times larger.

The collection of all these options constitute what CloudBerry calls a plan, and you can create any number of plans to back up different files to different destinations in different ways.

Beyond the plan-specific settings, there are additional global settings that provide control over how to handle symlinks, bandwidth throttling, and whether an active backup can keep the Mac awake. Plus, internal application settings let you control things like the thread count, chunk size, and memory footprint.

Having all this power and flexibility presented in such an attractive user interface left me feeling like I was truly going to have full control over the backups I was about to initiate.

A Short Honeymoon

Unfortunately, my bliss was short-lived. Some of the issues I ran into were minor, others major. But the totality of them undermined my confidence in the product. Let me walk you through some of what I found.

Behaving Poorly in the Background

After I set up a backup, I watched CloudBerry run. There were times I saw its main process, cbbWorker, consuming more than 40% of CPU cycles, which disrupted my productivity. CrashPlan, for example, can detect when you’re using the Mac interactively and throttle its CPU consumption down to a configurable threshold during those times to keep from affecting the user’s productivity. CloudBerry offers no such control, making it a less well-behaved background process.

While CloudBerry does offer network bandwidth limiting, it’s not smart enough to go full throttle when you’re away from the Mac. The result is that you either have to choose between a service that performs quickly and one that doesn’t interfere with your work—you can’t have both.

Inaccurate Statistics

Background behavior issues are frustrating, but concerns that make you wonder if all your data is accounted for are more troubling.

I configured a typical backup source, the /Users directory. When CloudBerry runs a backup, it tabulates the total size of the source files. But it counted only about 1 GB, which I knew was low. To convince myself that I wasn’t crazy, I checked with the Finder. And sure enough, CloudBerry’s total was way off:

Actual folder size vs. what CloudBerry backed up.

I made sure my plan had no file exclusions or any other setting that might account for a discrepancy. So what was CloudBerry backing up? If it completed, how could I know that all my data was stored safely?

So I carefully watched the backup progress, and I noticed that the progress bar seemed to shrink and grow over time rather than advance strictly from left to right. This would make sense if, like an option offered by Carbon Copy Cloner, CloudBerry were to start backing up before it finished tabulating how much it had to back up. But that’s not how CloudBerry works; it calculates that Total File Size number up front. To make matters worse, the progress bar didn’t match the percent completion figure stated beside it. Note the “94%” in the screenshot, with the progress bar barely a third of the way across.

I queried CloudBerry support about the progress bar and was told not to trust it because it was inaccurate. The support rep made no comment about plans to fix the inaccuracy, and the admission knocked my confidence in the app down a level, but I decided that it wasn’t a deal-breaker.

Two Activities You Should Never Fall Asleep Doing: Driving a Car and Backing Up Data

I came back later, logged in, and found the backup was incomplete and not running, with no notification at all. Fortunately, CloudBerry’s highly readable logs made it clear that the backup had been interrupted by the Mac going to sleep. I fixed the problem by checking the “Never sleep on backup” option in the app’s settings.

But how many people look at logs, readable or not? I do, because I’m an experienced software professional and because I’m doing a technical review. But most users don’t, and they shouldn’t have to. Backup should just work, and since backups will often take a long time (especially the initial one), it’s insane that the “Never sleep on backup” setting wasn’t suggested by the app. And if there is a problem that interrupts a backup, CloudBerry should yell at you like a smoke alarm until you fix the problem, because your data is at risk.

Inexplicable Slowness

I restarted the backup, at which point CloudBerry perplexingly tabulated a different—and more accurate—source file size of “~300 GB.” Ignoring the wishy-washiness of that number for the moment, I decided to let it run. After 24 hours, CloudBerry had scanned only a small fraction of the files (17 GB of 300 GB). At this rate, it could take 20 days to get my initial—and not particularly large—backup to start copying.

This was unreasonably slow. From a CPU point of view, I was running on a 2017 27-inch iMac with Retina display, and cbbWorker was using less than 8% of the available CPU most of this time, apparently having recovered from whatever it had been doing earlier, when it was chewing over 40% of the CPU. Plus, there was plenty of CPU headroom to spare.

cbbWorker's CPU activity

From a bandwidth point of view, I have Fios service that provides 100 Mbps for both downstream and upstream transfer, and it wasn’t busy transmitting or receiving data. Speed tests showed that other apps on this Mac could upload a lot of data.

Speedtest results

Likewise, the internal Fusion Drive where the source files were located can move a lot of data.

Disk speed test results.

Clearly, none of these system resources was the bottleneck. This suggests that the problem lies with either the client software or the remote server software or its local network. Given that I have over 1.5 TB of data to back up, this molasses-like performance would make CloudBerry unusable for me.

False Negative: Claiming Success When You Actually Failed

As I did with the previous problems I encountered, I set aside these performance concerns and worked toward completing a successful backup. And I got one! Or did I?

I gave up on the cloud backup, chose a much smaller source file set of about 10 GB, and set my backup destination to an external hard drive. CloudBerry finished backing up almost immediately and claimed success, with a nice little green check mark.

CloudBerry checkmark

But that seemed too quick, so I checked the console statistics (which everyone does, right?), where I learned that CloudBerry had backed up only one file comprising 110 bytes of data! That’s success, when I had selected 10 GB to back up?

As you will see, I continued trying to troubleshoot why CloudBerry backed up only one file out of thousands. And of course, errors happen. But it’s dangerously negligent to report success and lead a customer to believe their data is securely backed up when it clearly is not. It’s entirely possible that a customer would perform this backup so they could then reformat their source hard drive. And then they would restore from CloudBerry backup to find that one file is all that’s there and all their other files are nowhere to be found! “What about the green check mark?!?” I can hear them yelling.

Command-Line Chops Required

In spite of CloudBerry’s lovely graphical user interface, it’s apparently well known at CloudBerry Lab that you have to use the command line to have any hope of a working backup.

As I pursued troubleshooting the backup failures with the CloudBerry Lab support team, several techs noticed that some of the files I was backing up were owned by users on the Mac other than the one running CloudBerry, and told me that errors in the logs indicated a permissions problem:

“By default when you create a backup plan as user X it will run with the privileges of the user X. You can change it, however, by changing the owner of the backup plan configuration file.”

sh-3.2# ls -l
total 32
-rw-r--r--  1 dkitabji staff  3826 Nov 24 12:16 {0d1d4a65-4776-4fd4-8bcd-d8425a71e91c}.cbb
sh-3.2# sudo chown root:wheel /opt/local/CloudBerry\ Backup/plans/*
sh-3.2# ls -l
total 32
-rw-r--r--  1 root wheel  3826 Nov 24 12:16 {0d1d4a65-4776-4fd4-8bcd-d8425a71e91c}.cbb

Essentially, you have to run the Unix chown command to change the ownership of the plan file so that you can do advanced, sophisticated things like, you know, back up the files on your Mac!

I find this astounding. This is like handing a man the keys to his shiny, new Cadillac and saying, “Now sir, when you get home, before every long trip, you’re going to need to slide under the engine and use a socket wrench to adjust a few bolts for the car to work correctly. Otherwise, it may crash.” It would be trivial for CloudBerry to automate this change for you; there’s no reason that any user should have to type Unix commands to enable basic functionality.

Twilight Zone for Files

But I am apparently a glutton for punishment. If some simple Terminal commands were all it was going to take to get CloudBerry backing up my files successfully, I’d call myself a power user and use the product with (possibly misguided) pride. But CloudBerry was tenacious, and stubbornly stymied every attempt I made to grant it even a participation trophy.

I followed the guidance of the CloudBerry Lab support team and created a brand new backup plan with a corresponding empty destination folder so I’d have a clean slate to work with. I changed the permissions on the plan file before starting, launched the process, and let it complete.

It once again completed suspiciously quickly and with file-size statistics that, as before, were deeply unsettling. I knew I couldn’t trust the veracity of the statistics, even with this command-line change in place, but I wanted proof that something was amiss. I had a similar concern with Time Machine back in 2009, which led me to write a Unix shell script to look for discrepancies between my source and destination files. I found a glaring set of files that Time Machine was omitting, reported it to Apple, and shared my results online. So I decided to write a similar backup integrity audit script for CloudBerry.

To ensure that my audit would be accurate, I created yet another backup plan and corresponding storage destination, making sure compression, encryption, and all file exclusions were disabled. Then I let it run just once to ensure that CloudBerry’s versioning capabilities didn’t create multiple copies of any files that might have changed since the original run. Luckily, CloudBerry, when run without compression or encryption, simply mirrors the tree of files and directories to its destination. As a result, much as I did when auditing Time Machine, I was able to write a simple script to perform a file-by-file comparison of the source and destination folders, and report on what didn’t match.

The results were not encouraging. Here is the decidedly bare-bones output from my audit script (cb_audit.sh, which you can download and try for yourself, though beware it’s far from a polished user experience), checking the backup of three home directories on my Mac, both at the source (/Users) and the external drive destination (/Volumes/3T Spare; for readability, we’ve shortened the full destination path):

Daves-iMac-27:~ dkitabji$ sudo ./cb_audit.sh
Password:
----------------------------------
Auditing: /Users
----------------------------------
--------------------------
Listing: audrey
--------------------------
--------------------------
Listing: jack
--------------------------
--------------------------
Listing: ernie
--------------------------
sorting...
----------------------------------
Auditing: /Volumes/3T Spare/.../Users
----------------------------------
--------------------------
Listing: audrey
--------------------------
--------------------------
Listing: jack
--------------------------
--------------------------
Listing: ernie
--------------------------
sorting...
Calculating diffs...
File count in /Users: 307958
File count in /Volumes/3T Spare/.../Users: 7854
Directory size diffs:
1c1
< 106G audrey
---
> 309M audrey
1c1
< 3.4G jack
---
> 379M jack
1c1
<  21G ernie
---
> 2.1M ernie

Let me draw your attention to the following two lines of output:

File count in /Users: 307958
File count in /Volumes/3T Spare/.../Users: 7854

The source had 307,958 files, whereas the script found only 7854 files in the backup tree. Yes, you read that correctly.

Now, in addition to file counts, my script also compares the overall size of the directories. For these results, observe, for example:

< 106G audrey
---
> 309M audrey

This means that the source copy of the audrey home directory has 106 GB of data in it, whereas the copy made by CloudBerry only has 309 MB. Recall that I disabled compression and ensured that there were no file exclusions.

Are you feeling deeply unsettled yet?

I filed these results as a fresh ticket with CloudBerry Lab. At first, the support techs suspected that the issue could be related to symlinks, the approximate Unix equivalent of Finder aliases, not being handled properly. Fortunately, besides the output shown above, my script stores, behind the scenes, details about every file that is inventoried, so it’s easy to drill down to figure out which files were present in the source but not in the destination. Since I spend much of my professional career troubleshooting software issues, I know that to solve broad problems, you invariably have to focus on just one or two specific cases to get the bottom of the larger problem.

So I drew the support team’s attention to one specific file, a photo, that didn’t get backed up, even though its listing in Terminal makes clear (to someone who knows how to read this output; the dash in the first column gives it away) that this file is not a symlink:

sh-3.2# ls -l 'audrey/Pictures/iPhoto Library.migratedphotolibrary/Thumbnails/2015/03/20/20150320-180831/1ZghV9P+TAWtlZPsw6uUNQ/IMG_8764.jpg'
-rw-r--r--@ 1 audrey  staff 47053 Mar 20 2015 audrey/Pictures/iPhoto Library.migratedphotolibrary/Thumbnails/2015/03/20/20150320-180831/1ZghV9P+TAWtlZPsw6uUNQ/IMG_8764.jpg

They escalated the ticket to an engineer who also CC’d a member of the corporate advisory board. They then asked me to perform additional troubleshooting steps, focusing specifically on this particular file. Eventually, they replied, saying “We are pretty much sure the issue is caused by the Mojave data protection mechanism.”

I pointed out that I’m running High Sierra, not Mojave. They replied they had received some reports that High Sierra users were experiencing a similar issue, which they hypothesized could have been caused by Apple back-porting some of Mojave’s security mechanisms to High Sierra (which would be the first we’ve heard of such a thing). They also said that CloudBerry’s engineering team would be working on a fix, but there was a backlog of updates in line ahead of that fix.

I tried to convey the urgency of the problem, not for myself, but for the company’s Mac customers. I needed to understand if CloudBerry Lab felt the gravity of the problem. So I added, toward the end of one of my messages:

“As it is, it’s broken, unreliable, and a dangerous illusion of data protection for us consumers.”

And CloudBerry Lab’s engineer agreed to that statement.

I had been in touch with Artem Kolesnikov, CloudBerry Lab’s marketing communication manager, throughout the review process, and I informed him of the nature of the issues I had experienced. I further offered him the opportunity to provide a statement for inclusion alongside this review, and he obliged:

“There’s currently an issue with some personal files not being backed up because of macOS data protection mechanism, namely the contents of “/Users/$USER/Library/” directory.

It is under investigation these days so there should soon be a fix for it. We will publish it right away when it passes all the tests. We officially apologize for the inconvenience it may have caused.”

Even my single example above, however, shows that the problem is not limited to the contents of ~/Library. I hope CloudBerry Lab’s engineers will review my detailed series of tickets and make sure they understand the details of the problem so that they can properly fix it. However, given that I had to uncover this glaring issue myself and that they have not informed their users about it, I can’t see ever being comfortable trusting CloudBerry in the future.

Back Up and Reconsider

I have seen other reviews of CloudBerry that happily check many boxes on the feature list and grant it a favorable rating. I wonder how many of those reviewers actually performed a non-trivial backup using the product and took the time to evaluate whether it was in fact working properly.

I really wanted to be the one to tell the TidBITS community that there was another great backup app to consider. But I wanted to do that because I want to help you protect your data, and right now, the best way I can do that is to recommend that you do not use CloudBerry Backup for macOS.

To quote the late, lamented Dantz Development, “To go forward, you must back up.” Be safe out there!


Dave Kitabjian has been writing software and designing Internet and telecom services for 30 years. A Mac owner since 1984, he manages five of them at home while developing for Linux and Windows at work. O’Reilly Media occasionally asks him to do technical editing, and he enjoys playing improvisational jazz on keys, bass, and guitar.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.

Comments About CloudBerry Backup for macOS: Feature-Rich but Unreliable

Notable Replies

  1. This is truly awful.

    I wonder why making online backups is so hard. The Crashplan persons told me that I have too many files. Their backup simply stopped working. Then I switched to Arq. When I had computer troubles I found out that the last backup was 9 days old.

    Do you have any experience with Acronis? I only know the name from Windows. The software looks much better than Arq or Crashplan. But it has the same problem as Arq: no timeline window. Oh, and sending mails as confirmation seems beyond their capabilities.

  2. Hello Beatrix, and thanks for your reply.

    I am not familiar with Acronis (at least not yet :sweat_smile:). Hopefully after reading this article, you know not to trust how it “looks” :wink:.

    I’m not sure what you mean by Timeline, unless you’re referring to the feature in Time Machine that visually shows what backups you have going back in time? Do you need to actually show it as a “line” or is it enough, as in Crashplan or Arq, to be able to type in a date and get the files you need to restore effective that date?

    As far as sending email notifications, that should be standard nowadays. CloudBerry actually did that part rather well.

  3. Lovely review! It’s so nice to read genuine ones instead of slightly rephrased press releases.

    Given most of the article, I guess this question doesn’t matter much: does it do deduplication, either at file or block level? Even if things otherwise worked, the lack would be a deal killer for me.

    Has anyone tried Retrospect Solo or Desktop? Retrospect used to be one of the standards on Mac, until (tl;dr) they aimed at business for steep prices. But they’ve got individual user versions again: $50 for one computer with no network drives or $120 for one non-server Mac plus five additional computers as clients (cross platform). It can backup to a wide variety of clouds and local media, and hopefully has a similar feature set for file selection, scheduling and such across all versions. There’s a 45 day trial, though that may not include Solo. I now have something else to play with over the weekend, along with my Wasabi and Arq trials.

    https://www.retrospect.com/en/products/solo
    https://www.retrospect.com/en/products/mac/desktop
    https://www.retrospect.com/en/store/trial

    Cloudberry’s problems also gave me a flashback to long ago (mid-late 90s?) LaCie’s SilverLining backup program. Free for everyone, not just LaCie drive owners, and easy to use. I thought there was finally an option to hand out to users to get them to back up. Until I tested it and discovered that it randomly skipped entire folder trees. I tried to talk to LaCie about it, but never heard back. A couple of years later I looked at it again, and it still did that. This was long before apfs, compression, security models, or any other fancy features, so there was really no excuse for them not noticing that the backup didn’t match the source. (N.B., if SilverLining or other LaCie backup software currently exists, it could well be properly functional now; I wouldn’t know.)

  4. The Crashplan person gave you poor advice. They had a very nice online documentation set, but it did take some practice to find things in it. For huge numbers of files, you had to change the maximum memory that the Java engine was allowed to use (one line in a text file), then things went well. There was a third party utility floating around that could do that, and also make sure that CP used the correct Java version if you had other apps that used different versions, but it wasn’t hard to do it by hand and the CP technotes were clear and easy to follow.

    I find that it’s far too common for backup software to eventually stop doing their backups for mysterious reasons. Time Machine is a prime offender, but even Chronosync does it to me a couple of times a year. Now I either have success mail sent to me in the hopes that I’ll notice if they stop coming, or have reminders set to check manually every week or so.

  5. @gastropod: the Crashplan persons did a lot of stuff. We restarted, reinstalled, reindexed and increased the memory Jave until I was totally fed up.

    @Dave Kitabjian: let’s say you delete a file because you want to clean up your disk. Some months later you find out that the file had critical information. In Crashplan I could select the deleted file (I think) or its folder and then with the timeline I could pinpoint very easily when I deleted the file. In Arq and Acronis I only have the individual backups. I now would have to go through the backups weekly back to find the last version of the file I need.

  6. This is why I enjoy TidBits – reviews written clearly with pertinent observations and recommendations.

    @gastropod – I’ve used Spideroak’s backup services for several years and they offer deduplication as I recall. Might meet your needs…

  7. I do not use this application, but have recently experienced a very similar situation in LiveCode.app because of the change in macOS data protection mechanism to access the contents of “/Users/$USER/Library/” directory. The problem was solved by the following, which could apply to CloudBerry and more.

    • System Preferences… > Security & Privacy
    • Privacy
    • Full Disk Access
    • LiveCode.app

  8. Yes, Mojave’s Full Disk Access is often necessary for backup apps. Since @dave1 was testing under High Sierra, that didn’t come up, but I would hope that CloudBerry would prompt the user to add Full Disk Access like SuperSuper and Carbon Copy Cloner do.

  9. CloudBerry here. Thank you for helping us improve our products! We’re big TidBits fans and we love independent reviews of our Standalone products. We’ll keep you updated with our progress on the items you have discovered.

  10. Thanks, Tareck, that’s very kind. It speaks volumes about Adam’s editing skills!

  11. Thanks for your words gastropod. You clearly have a lot of experience with backup software. I enjoyed Retrospect many years ago, but not any time recently.

    I don’t recall reading about any deduplication capabilities in CloudBerry. That matters little to me since my storage costs are low. But having block level incremental backups keeps cpu and bandwidth burdens low, so that matters a lot to me.

  12. @GS.Sunatori1, thanks for pointing this out, and @ace is correct.

    High Sierra doesn’t have the “Full Disk Access” privacy setting available at all. And like I mentioned in the article, the file omissions are much broader than what would be found in ~/Library.

    Likely, their problem is related to the privilege structure between the various processes (there are at least 3), config files, and user files.

    Hopefully they figure it out once and for all!

Join the discussion in the TidBITS Discourse forum

Participants

Avatar for ace Avatar for dave1 Avatar for gastropod Avatar for trelass Avatar for GS.Sunatori1 Avatar for beatrixwillius Avatar for CloudBerry