CrashPlan cache getting too large on Mac OS X


This article helps you to clean up the cache directory that CrashPlan uses to storage its metadata.  Apparently CrashPlan does not clean up it’s own cache files in an effective way at this point on Mac OS X. The “cleanest” way is to just uninstall and reinstall the application however sometimes you don’t have the time for this so try this out.

Symptom:  /Library/Caches/CrashPlan directory or /Library/Logs/CrashPlan/engine_output.log is taking up several GB of space and just growing (5+ GB of space).

Solution:  Setup new cache files and remove the old cache.

Here is how you do it:

Open CrashPlan: [(CommandKey) + (SpaceBar) and type: “CrashPlan”]
Double click on the CrashPlan Logo in the upper right corner (looks like a green house).
A command window (below) will open up.
Type “backup.replace 42” into the command window.

Now it is time to shutdown CrashPlan, remove the old cache files and then restart the process.
Open up a Terminal window [Press (CommandKey) + (SpaceBar), then type: “terminal”]

Shutdown the CrashPlan process:
My-Mac:~ username$ sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
the cache files:
My-Mac:~ username$ sudo rm -r /Library/Caches/CrashPlan/*
My-Mac:~ username$ sudo rm -f /Library/Logs/CrashPlan/engine_output.log
the CrashPlan process:
My-Mac:~ username$ sudo launchctl load /Library/LaunchDaemons/com.crashplan.engine.plist

Use this command to view if the engine is running:
My-Mac:~ username$  ps auxww | grep -i CrashPlanService

The output will look something like this:
root        63   0.1  6.1   873644 126976   ??  SNs  Tue03PM  43:01.37 /System/Library/Frameworks/JavaVM.framework/Commands/java -Dapp=CrashPlanService -Xmn10m -Xms15m -Xmx512m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Dnetworkaddress.cache.ttl=300 -Dnetworkaddress.cache.negative.ttl=0 -DCP_USER_NAME= -DCP_USER_HOME= -cp lib/com.backup42.common.jar:lib/com.backup42.service.jar:lib/com.code42.backup.jar:lib/com.code42.bplusj.jar:lib/com.code42.messaging.jar:lib/com.code42.os.jar:lib/com.code42.peer.jar:lib/com.code42.utils.jar:lib/com.jniwrapper.jniwrap.jar:lib/com.jniwrapper.macpack.jar:lib/com.jniwrapper.winpack.jar:lib/jtux.jar:lib/trove-2.0.1.jar:lang com.backup42.service.CrashPlanService

Now you should be good to go and the cache file should grow over time.  You may need to do this once a quarter or so.

I gathered this information from two websites: and

7 thoughts on “CrashPlan cache getting too large on Mac OS X

  1. Thanks – very helpful! My cache file was over 50 Gig!

    • Thank you! It takes more than a year to build up to that level. I had to this twice thus far but it is much better. The other issue I have found is that the JAVA process will eat up 100% of one my CPU cores. I will post how to disable that during working hours when I get a moment. It is totally worth it.

  2. This process will regenerate the cache file, which still may be a few GB after that. One thing to note is that if you’re seeing a really large cache file (more than a few GB), it may be an indication of other issues with the app. Also, the Java process eating up 100% of one of your CPU cores (when the CPU limits are set) can be another indication of issues.

    SO, if you’re seeing either of these symptoms, please contact our CrashPlan Customer Champion team to investigate.

    They’ll want to see your logs. Instructions on getting your log files can be found here:

    Ryan at Code 42 (makers of CrashPlan)

  3. Uninstalling CrashPlan and reinstalling it also flushes out the monster cache files. Ours was well over 205g.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s