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. This might be just a minor-ish annoyance (as in, can't they get this right?) if you are always connected to power. In practice, CrashPlan seems to spend an inordinate amount of time doing full scans of the backup sets. I totally disabled it some time ago.Īdditionally, 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.ĬrashPlan supposedly tracks changes in the filesystem to avoid having to scan all the filesystem for changes when the time comes for a new backup. Furthermore it's less than useful, since it easily gets out of sync with what the main GUI says. So, just start the GUI and the fans might start getting noisy!Įven the menubar GUI uses upwards of 5% CPU while closed. 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. This is a list of my problems with it, which are the things I would have liked to realize earlier.Īll 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. 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.Ĩ months later, I'm fed up enough with CrashPlan to start looking for alternatives. The awkwardness didn't negate that it seemed to work well enough, better than the alternatives I tried at the moment. After a couple of months using CrashPlan I wrote about its awkward feature set and their interactions.

Code42service