I've been using CrashPlan to back up my home PCs and servers for about three months now and I'm generally very happy with the service. I back up everything locally to my file server as well as the CrashPlan cloud service. There have been a couple hiccups such as systems getting disconnected from the cloud and being unable to reconnect without starting the service, but I ran into a problem this week that took a bit of sleuthing to figure out.
My main file server has about 2.5TB of data that is slowly but surely being uploaded to the cloud. I originally had it limited to 512Kbps of upload bandwidth and had to pony up the cash a couple weeks ago to upgrade my cable Internet service. It now runs at 3Mbps but I've still got about a month to go before the initial backup is completed. At the moment, I've got 927.8GB uploaded. Until a couple days ago, the upload process was relatively flawless, but the service started randomly failing and restarting about once every 60-75 seconds. It would generate event ID 7036 ("The CrashPlan Backup Service service entered the stopped state") in the System log, then immediately restart the service and issue the same event ID 7036 ("The CrashPlan Backup Service service entered the running state").
It took a fair amount of web sleuthing to find the culprit. For some odd reason, CrashPlan utilizes an *.ini file that specifies a hard minimum and maximum memory allocation. By default, the *.ini file specifies a minimum of 16MB of RAM and a maximum of 512MB of RAM. I'm sure this is sufficient for the majority of CrashPlan home users that are backing up a gigabyte or two, but 512MB apparently becomes insufficient betwen 800-900GB of uploaded data. I'm not sure why memory requirements increase based on the amount of data that has already been uploaded, but I'm assuming the deduplication process is keeping track of the hashes associated with the uploaded data, and more data means more hashes.
You can increase the memory limitation for CrashPlanService.exe by modifying CrashPlanService.ini. By default, this file is located in C:\ProgramFiles\CrashPlan on Windows Vista/2008 and up. You must stop the service called CrashPlan Backup Service before you can modify this file! Once you've opened the file, look for the phrase -Xmx512M, which is on the fourth line of the document by default with CrashPlan 3.5.2. Modify 512 to reflect the amount of RAM you'd like CrashPlan to be able to consume. Keep in mind this is the maximum and CrashPlan will only consume it if necessary! The screenshot below shows my CrashPlanService.ini file after increasing the memory maximum to 4,096MB (4GB), with the relevant bit highlighted:
If you run into permissions issues when you try to save the file, save it to the desktop instead and move it to the CrashPlan folder. This will provide the UAC prompt needed to overwrite the file. Once the file has been modified and saved, restart the service called CrashPlan Backup Service. For what it's worth, CrashPlan consumed 634MB of RAM once I increased the maximum memory ceiling to 4GB. I'll update this post at some point in the future with the amount of RAM consumed once the full 2.5TB has been uploaded.
Edit: I've also seen some oddities on a Linux VM that runs CrashPlan. After some more web sleuthing, I've found the configuration file for CrashPlan is located at /usr/local/crashplan/bin/run.conf on a BackTrack v5.2 box. I'd assume most Linux distros would place it in the same spot.
Comments