This article will prodive some information on CrashPlan's client log files:
- Log file locations
- Short descriptions of important log files
- How to use logs to pinpoint common issues with the CrashPlan client
Log File Locations
- Mac: /Library/Logs/CrashPlan
- Windows Vista/7/8/2008: C:\ProgramData\CrashPlan\log
- Windows XP/2003: C:\Documents and Settings\All Users\Application Data\CrashPlan\log
- Linux: /usr/local/crashplan/log
- Solaris: /opt/sfw/crashplan/log
Note: When you open up your log folder, you may notice multiple copies of each log file, e.g. service.log.0, service.log.1, service.log.2, etc. To keep log file sizes under control, logs "roll over" into a new logfile after they reach a certain size, and older logs are eventually purged.
The lower the number appended to the log name, the newer the log file is. i.e. service.log.0 is your most recent service log.
Log File Descriptions
App.log contains general configuration information about your computer and CrashPlan. Some information you can find in your app.log includes:
- Operating system version
- Java version
- CrashPlan version
- Licensing overview
- CrashPlan application settings
- Backup destination information
Service.log is the main logfile, written by the CrashPlan service as it goes about its business. It logs warnings and exceptions, so it is usually the main logfile used for troubleshooting.
Backup_files.log contains a list of files that CrashPlan has attempted to back up. Information found in backup_files.log includes:
- Backup success or failure (an "I" means that the file backed up successfully; a "W" means that the file failed to back up)
- Date and time
- Destination GUID
- File name and path
- File size
Similar to backup_files.log, restore_files.log contains a list of file names and paths for each restore attempt.
History.log mirrors what you would see if you opened the CrashPlan client and clicked on the "History" tab. It contains a high-level overview of what the CrashPlan client has been doing, e.g.
- Backups starting and stopping
- File scans starting or stopping
- Amount of data backed up
- Backup speed
Troubleshooting the client using logs
To read the files, navigate to the log folder and open the log with a text editor. More advanced users may prefer to use the Command Line or Terminal.
When reading through the logs, you can search for WARN as a starting point.
Common Errors Found in service.log
Below, we'll provide sample log messages to illustrate how some common client issues appear in the logs.
Click on each header below to visit the corresponding Answers From Support article for additional troubleshooting information and fixes.
If you see "Unable to connect to backup engine" when you try to open the client, and the below error appears in service.log on Windows:
- Open services.msc
- Open the CrashPlan Backup Service's properties pane
- et the "Startup Type" to "Automatic (delayed start)."
[03.29.13 12:51:12.872 WARN main com.backup42.service.CPService ] Unexpected IO Exception constructing selector engine - e=java.io.IOException: Unable to establish loopback connection, java.lang.RuntimeException: Unexpected IO Exception constructing selector engine - e=java.io.IOException: Unable to establish loopback connection
One extremely common reason for "unable to connect to the backup engine" is that the backup engine is running out of memory.
[09.23.12 22:33:02.273 ERROR QPub-BackupMgr backup42.service.backup.BackupController] OutOfMemoryError occurred...RESTARTING! message=OutOfMemoryError in BackupQueue!
Client cache issues can manifest themselves in a few different ways, including: some or all files missing from the Restore tab, stopped backups, incorrect reports, and incorrect file selection size.
[12.21.12 12:12:01.441 WARN W964862003_BckpSel m.code42.backup.manifest.ManifestManager] Exception initializing ManifestManager java.lang.IllegalArgumentException: Malformed \uxxxx encoding.; MM[BT 525528945129975616>42: openCount=1, initialized = false, dataFiles.open = false, C:\ProgramData\CrashPlan\cache\42]
[05.11.12 08:45:22.921 WARN W471137477_ScanWrkr com.code42.bplusj.BplusTreeIndexFile ] Exception calling Commit() while closing BplusTreeIndexFile@1379711510[ path = C:\ProgramData\CrashPlan\cache\cpgft1x, keyLength = 20], java.io.IOException:
[05.16.12 13:03:06.109 INFO MQ-Peer-1 com.code42.backup.BackupClient ] BC[525528942342975616>42:: SYNC:: Manifest validation failed.<br />[05.16.12 13:03:06.110 WARN MQ-Peer-1 com.code42.backup.BackupClient ] BC[525528942342975616>42:: SYNC:: Replacing empty local target manifest files with remote server files!!
[08.30.12 17:13:27.274 WARN W202972748_SpotQW com.code42.os.mac.spotlight.Spotlight ] Exception in getStringFromCFStringRef(): 64bit, e=java.nio.BufferUnderflowException
12.06.10 04:29:40.426 WARNING W449507565_ScanWrkr com.backup42.jna.inotify.InotifyManager.watch ] Unable to add watch for path /home/erik/Desktop/foo.bar, errno: 28
Identifying What Files Are Backed Up Using backup_files.log
Look for a "W" at the beginning of a line to indicate a file which is failing to back up, or search backup_files.log for the string "Unable to backup".
A file that is failing to back up looks like this:
W 01/06/13 12:00PM 42 - C:\Users\John\Blackberry\Backup\BlackBerry Tour 9630-1.ipd
A file backing up successfully will have an "I" at the start of the line:
I 01/06/13 12:00PM 42 50cd0afdb853e65f1f47c31407ce9a4a 0 C:\Users\Jill\Documents\Outlook Files\outlook.pst (200483653) [1,0,200483653,0,0,0,0]