Moving CrashPlan cache and log directories to new locations

As discussed in a previous post, the ReadyNAS might run out of disk space on the 4 GB root partition if you install software other than that provided by NetGear.

In my case it was CrashPlan’s cache and log files that were filling up the root partition, with warning emails every 10 minutes that 81% of the root partition was used, 82%… 83%…, so they needed a new home. Turns out it is not too hard:

ssh into the NAS, then su to become root. Stop CrashPlan (if it is running):

[code language=”bash”]
root@RN312:/home/admin# service crashplan stop
Stopping CrashPlan Engine … OK

Make a copy of CrashPlan’s configuration file, in case something goes wrong:

[code language=”bash”]
root@RN312:/home/admin# cp /usr/local/crashplan/conf/my.service.xml /usr/local/crashplan/conf/my.service.xml.orig

Take a look at CrashPlan’s cache directory:

[code language=”bash”]
root@RN312:/home/admin# ls -lah /usr/local/crashplan/cache/
total 40M
drwxr-sr-x 1 root staff  106 Sep 25 03:00 .
drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
drwxr-sr-x 1 root staff  170 Sep 25 21:31 42
-rw-r–r– 1 root staff 8.4K Sep 25 21:31 cpft1_42
-rw-r–r– 1 root staff 1.9K Sep 25 21:31 cpft1_42i
-rw-r–r– 1 root staff 2.1K Sep 25 21:31 cpft1_42x
-rw-r–r– 1 root staff  23M Sep 25 21:31 cpgft1
-rw-r–r– 1 root staff 8.8M Sep 25 21:31 cpgft1i
-rw-r–r– 1 root staff 7.9M Sep 25 21:31 cpgft1x
-rw-r–r– 1 root staff  986 Sep 25 03:02 cpss1

Create cache directory in new location:

[code language=”bash”]
root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/cache

Change the config file to point to the new location (using your favourite editor, vim used here):

[code language=”bash”]
root@RN312:/home/admin# vim /usr/local/crashplan/conf/my.service.xml


(Adjust as needed if you have selected some other place for the CrashPlan files.)

Now move the cache files:

[code language=”bash”]
root@RN312:/home/admin# mv /usr/local/crashplan/cache/* /home/admin/from_root/crashplan/cache/

Time to move CrashPlan’s log files. They are originally stored in /usr/local/crashplan/log/, let’s move them to /home/admin/from_root/crashplan/log.

[code language=”bash”]
root@RN312:/home/admin# ls -lah /usr/local/crashplan/log/
total 111M
drwxrwxrwx 1 root staff  346 Sep 23 04:41 .
drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
-rw-r–r– 1 root root   33K Sep 25 21:31 app.log
-rw-r–r– 1 root root   23M Sep 25 21:31 backup_files.log.0
-rw-r–r– 1 root root   26M Jul 12 19:50 backup_files.log.1
-rw-rw-rw- 1 root root     0 Aug 15 15:21 engine_error.log
-rw-r–r– 1 root root  6.4K Sep 25 21:31 engine_output.log
-rw-r–r– 1 root root  180K Sep 25 21:31 history.log.0
-rw-r–r– 1 root root  501K Sep 17 13:47 history.log.1
-rw-r–r– 1 root root  501K Aug 25 08:10 history.log.2
-rw-rw-rw- 1 root root     0 Aug 15 15:24 restore_files.log.0
-rw-r–r– 1 root root   13M Sep 25 21:31 service.log.0
-rw-r–r– 1 root root   26M Sep 23 04:41 service.log.1
-rw-r–r– 1 root root   26M Sep 17 14:35 service.log.2
root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/log

Find the fileHandler tags (there are 4 of them dealing with log files), modify them so they point to the new log directory. So, once again edit /usr/local/crashplan/conf/my.service.xml.orig, part of mine looks like this after moving the log files. Change the paths as neeed for your choice of new directories:

[code language=”bash”]
    <fileHandler append="true" count="2" level="ALL" limit="26214400" pattern="/home/admin/from_root/crashplan/log/service.log"/>
    <fileHandler append="true" count="10" level="ALL" limit="512000" pattern="/home/admin/from_root/crashplan/log/history.log"/>

Start CrashPlan again:

[code language=”bash”]
root@RN312:/home/admin# service crashplan start
Stopping CrashPlan Engine … OK

And finally check free disk space on /:

[code language=”bash”]
root@RN312:/usr/local/crashplan/log# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          4.0G  1.7G  1.8G  49% /
tmpfs            10M  4.0K   10M   1% /dev
/dev/md0        4.0G  1.7G  1.8G  49% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G  5.8M  2.0G   1% /run
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           2.0G     0  2.0G   0% /media
/dev/md127      2.8T  1.1T  1.7T  39% /data
/dev/md127      2.8T  1.1T  1.7T  39% /home
/dev/md127      2.8T  1.1T  1.7T  39% /apps

49% – nice!

7 thoughts on “Moving CrashPlan cache and log directories to new locations

  1. Pingback: CrashPlan on Netgear ReadyNAS RN312 – hello! | Ptarmigan Labs

  2. Chris

    Thanks for sharing this instruction! I’d like to add the following modifications that I needed to apply in order for this to work on my ReadyNAS Ultra 2 for anyone who might get stuck on the same issues:

    1. the “services” command seems to be unknown on my machine. To start and stop crashplan use /usr/local/crashplan/bin/CrashPlanEngine start/stop

    2. moving the cache to /home/{something} will not help on my machine since /home/ is also located on the root partition. The home appropriate home directory on ReadyNAS machines that have a /c/ directory would be /c/home/admin/{and so on} as /c/ is your big partition.


    1. gsander

      Thanks for the comment – useful to get info on how it works on other products too.
      The Ultra series uses a different (older) architecture, so it is not too strange it works slightly differently.
      Happy yo hear you got it working though!

  3. TomT

    I’d like to thank you for this post and also point out that this seems to work just as well on my Windows 7 Professional computer. I moved the location of the cache and log files from my relatively small SSD C: drive to my much larger D: drive by editing the file C:ProgramDataCrashPlanconfmy.service.xml. First I stopped the CrashPlan service, then I moved the log and cache directories to the desired new location on D:, then I edited the conf file, searching for cachepath and filehandler and changing the path values accordingly. So far backups seem to work fine and this freed up almost 1 GB on my C: drive. One note: CrashPlan seems to have recreated the folder C:ProgramDataCrashPlanlog, but is only storing some files in this folder, while the “large” log files are being stored in the new location under D:ProgramDataCrashPlanlog. So far it seems to operate fine with log files in two locations. (I might have been able to avoid the need for doing the above if I had initially installed CrashPlan to the D: but I can’t remember if that was even an installation option, and in any case I tend to keep my “important” system programs installed on the C: drive.)

    1. Fips

      Thanks for the info! I can add that installing it to D: from the start still leaves the cache files floating around on C:, and confirm that this method at least shifts the cache files and reduces the logs to a trickle.

  4. John Mark Mitchell

    gsander, thanks for time spent documenting this. I spent a good amount of time tracking down why Frontview was showing the volume as offline when I could SSH in and see cd to /c just fine. I has experienced something similar to this in the past when one of my Western Digital Green drives decided to go to sleep (Idle 3 mode) so I went down that path first. For those of you who might come across this in the future, you can read more about the [WD Green disk Idle 3 issues and how to fix it]( “WD Green disk Idle 3 issues and how to fix it”). As you can guess, my issue this time was really a symptom of the fact that /dev/m0 was full and thus many things were not going quite right.

    The full /dev/m0 was due to the fact that I had installed crashplan with the defaults and thus it had filled up the boot drive. I am a bit perplexed as to why I never received any notice from Frontview for the drive filling as a I do get other system notices in my email from my readynas.

    Similar to Chris (comment above) I had to use /usr/local/crashplan/bin/CrashPlanEngine start/stop to control Crashplan. And I moved the cache and log locations to /c/home/admin/… because /home is still part of my boot drive whereas /c/home is on the raided disk.

    If it helps anyone else, the details of my system are as follows:
    ReadyNAS Pro Business Edition
    RAIDiator 4.2.27
    6 disks [13 TB]

    1. gsander

      Nice – happy that things worked out for you.
      It would be nice if Netgear would be a bit more generous when it comes to root partition size.. But on the other hand, these devices aren’t really intended as platforms for general software installation.


Leave a Reply

Your email address will not be published. Required fields are marked *