After a couple of months using CrashPlan I wrote about its awkward feature set and their interactions. The awkwardness didn't negate that it seemed to work well enough, better than the alternatives I tried at the moment. Still, it was also bad enough that it motivated me to keep my TimeMachine local backup, even though my earlier idea was to get rid of it.
8 months later, I'm fed up enough with CrashPlan to start looking for alternatives. This is a list of my problems with it, which are the things I would have liked to realize earlier.
All of these complaints have been brought up with their Support, even explicitly as feature requests and/or bug reports, and the eventual answers have not been particularly helpful nor encouraging; in the best cases Support just provided workarounds to suspend the pain for a while.
The GUI typically uses about 50% CPU, AND seems to manage its redrawing so badly that it causes macOS' WindowServer to use another >50% CPU. So, just start the GUI and the fans might start getting noisy!
Even the menubar GUI uses upwards of 5% CPU while closed. Furthermore it's less than useful, since it easily gets out of sync with what the main GUI says. I totally disabled it some time ago.
Additionally, when you don't interact with the GUI for a couple of minutes, next time you touch it, it'll make you log in again.
CrashPlan supposedly tracks changes in the filesystem to avoid having to scan all the filesystem for changes when the time comes for a new backup.
In practice, CrashPlan seems to spend an inordinate amount of time doing full scans of the backup sets.
This might be just a minor-ish annoyance (as in, can't they get this right?) if you are always connected to power. But if not, this compounds into a major problem, given the CPU usage and battery drainage it causes - but that's what the next point is about.
The actual backup service (CrashPlanService) uses a lot of CPU (I've seen sustained peaks of >120%). In theory this is configurable, but this happens even when on battery AND configured to stop on battery. According to Support, this is expected, because of those times when CrashPlan is "only scanning", not actually backing up. As a possible "improvement" they recommended changing the configuration of CrashPlan (via a hidden console!) to make more memory available, so the scanning would finish faster (but would still happen!). Not only this feels like the 90's – it didn't fix anything.
Actually, when I asked how to know whether the app is misbehaving because of low memory availability, I got no answer. Twice.
Interestingly, the old CrashPlan 4.9 app allowed one to change the scanning periodicity. The latest version, 6.2, doesn't allow to change that. Furthermore, some of the settings have been moved to a page in the web profile, which also could use some reworking. So: the CrashPlan app is getting not only increasingly hoggish, but also increasingly useless.
So I complained again about the CPU usage while on battery, and a rather brutal fix was suggested: once again use the hidden console to "deauthorize" the CrashPlan installation. It worked, and seems to totally stop CrashPlan from doing anything until you later authorize it again (by logging in). But this caused other side problems: when logging in again, one needs to reintroduce the private key (which is a dangerous moment because looks like a mistake could simply erase the existing backup without warning). Even worse: the backup process seems to again start with a full scan, and looks like the actual backup only starts after some hours.
To add insult to injury, when on battery, the GUI only shows "Low battery - Backup will resume automatically based on your battery usage settings." It's only when you look at the OS's Activity Monitor that you realize that CrashPlanService is actually hogging 100% CPU.
This one is funny: you are supposed to configure CrashPlan's memory availability depending on the size of your backups; more or less 1GB per million files. By default it will use up to 512 MB.
The catch is, the default configuration (and a marketed advantage) of CrashPlan is to never forget deleted files. So, by default, the number or backed-up files only grows. So sooner than later you'll have to go into that hidden console and add more memory.
And anyway the maximum is 4GB. I asked what will happen then once you're over those 4 GB; Support just said they know about the problem and will think about it. Huh.
For reference, I'm just backing up my MacBook and a rather unchanging external drive for 10 months, and I'm already over 2.7 million files!
My main reason to use CrashPlan was to have a cloud backup while I'm on the go. Unfortunately, turns out that CrashPlan in practice is too awkward for this, and it's getting worse. So, not only I have to keep my TimeMachine drive; I am again in the market for some no-nursing-needed cloud backup solution.
8 months later, I'm fed up enough with CrashPlan to start looking for alternatives. This is a list of my problems with it, which are the things I would have liked to realize earlier.
All of these complaints have been brought up with their Support, even explicitly as feature requests and/or bug reports, and the eventual answers have not been particularly helpful nor encouraging; in the best cases Support just provided workarounds to suspend the pain for a while.
Absurd CPU usage... by the GUI!
The GUI typically uses about 50% CPU, AND seems to manage its redrawing so badly that it causes macOS' WindowServer to use another >50% CPU. So, just start the GUI and the fans might start getting noisy!
Even the menubar GUI uses upwards of 5% CPU while closed. Furthermore it's less than useful, since it easily gets out of sync with what the main GUI says. I totally disabled it some time ago.
Additionally, when you don't interact with the GUI for a couple of minutes, next time you touch it, it'll make you log in again.
Always "synchronising"
CrashPlan supposedly tracks changes in the filesystem to avoid having to scan all the filesystem for changes when the time comes for a new backup.
In practice, CrashPlan seems to spend an inordinate amount of time doing full scans of the backup sets.
This might be just a minor-ish annoyance (as in, can't they get this right?) if you are always connected to power. But if not, this compounds into a major problem, given the CPU usage and battery drainage it causes - but that's what the next point is about.
Eats battery even when configured not to
The actual backup service (CrashPlanService) uses a lot of CPU (I've seen sustained peaks of >120%). In theory this is configurable, but this happens even when on battery AND configured to stop on battery. According to Support, this is expected, because of those times when CrashPlan is "only scanning", not actually backing up. As a possible "improvement" they recommended changing the configuration of CrashPlan (via a hidden console!) to make more memory available, so the scanning would finish faster (but would still happen!). Not only this feels like the 90's – it didn't fix anything.
Actually, when I asked how to know whether the app is misbehaving because of low memory availability, I got no answer. Twice.
Interestingly, the old CrashPlan 4.9 app allowed one to change the scanning periodicity. The latest version, 6.2, doesn't allow to change that. Furthermore, some of the settings have been moved to a page in the web profile, which also could use some reworking. So: the CrashPlan app is getting not only increasingly hoggish, but also increasingly useless.
So I complained again about the CPU usage while on battery, and a rather brutal fix was suggested: once again use the hidden console to "deauthorize" the CrashPlan installation. It worked, and seems to totally stop CrashPlan from doing anything until you later authorize it again (by logging in). But this caused other side problems: when logging in again, one needs to reintroduce the private key (which is a dangerous moment because looks like a mistake could simply erase the existing backup without warning). Even worse: the backup process seems to again start with a full scan, and looks like the actual backup only starts after some hours.
To add insult to injury, when on battery, the GUI only shows "Low battery - Backup will resume automatically based on your battery usage settings." It's only when you look at the OS's Activity Monitor that you realize that CrashPlanService is actually hogging 100% CPU.
Forever growing memory usage?
This one is funny: you are supposed to configure CrashPlan's memory availability depending on the size of your backups; more or less 1GB per million files. By default it will use up to 512 MB.
The catch is, the default configuration (and a marketed advantage) of CrashPlan is to never forget deleted files. So, by default, the number or backed-up files only grows. So sooner than later you'll have to go into that hidden console and add more memory.
And anyway the maximum is 4GB. I asked what will happen then once you're over those 4 GB; Support just said they know about the problem and will think about it. Huh.
For reference, I'm just backing up my MacBook and a rather unchanging external drive for 10 months, and I'm already over 2.7 million files!
In summary
- If you happen to be in the move most of the day, you have to remember to manually deauthorize CrashPlan before it eats up your battery. (In practice, I tend to remember when I realize that my battery is already 20% lower than expected). Of course, this means no backups during that day.
- When you happen to stop "at home" (hotel, etc), you have to remember to re-authorize CrashPlan. Careful with that private key too!
- The first few hours will be wasted with a new scanning, so I am not sure one can count on the backup being up-to-date!
- You should probably configure the available memory to 4GB from the very beginning. Might help speed up things, and anyway it will be necessary soon.
My main reason to use CrashPlan was to have a cloud backup while I'm on the go. Unfortunately, turns out that CrashPlan in practice is too awkward for this, and it's getting worse. So, not only I have to keep my TimeMachine drive; I am again in the market for some no-nursing-needed cloud backup solution.
At some point I found an acceptable-ish workaround to the CPU-usage-on-battery issue: send to the daemon a SIGSTOP signal, and when ready to restart the backups, send it a SIGCONT. Much easier and much less risky than deauthorizing and having later to retype the archive's private key.
ReplyDelete