- CrashPlan for Home
This article is intended for CrashPlan for Home users. For Code42 CrashPlan and CrashPlan PRO documentation, read this page on our enterprise support site.
If it looks like the CrashPlan app is restarting your backup unexpectedly, it may actually be running a file verification scan. The scan is an important and normal part of CrashPlan's scheduled activities, but it can also be triggered by several events. This article describes:
- Events that trigger the scan
- How to verify whether or not files are backing up for the first time (i.e., restarting your backup)
- Where to find solutions for issues with the file verification scan
File verification scan
The file verification scan inspects your file selection for any new, changed, or deleted files that real-time file watching may have missed. Think of it as CrashPlan's second line of defense for detecting changes to your backup file selection.
By default, the scan is set to run daily at 3:00 a.m., but this schedule can be changed. CrashPlan periodically runs additional verification scans to detect data corruption, purge files that are no longer selected for backup, and prune file versions and deleted files according to your frequency and version settings.
In addition, there are times when a file verification scan is automatically triggered:
- Changing the file selection: If you update your backup file selection, either to add or remove files, the scan runs to look for new, changed, or deleted files.
- Computer adoption: After adopting a previous archive (for example, if you recently changed computers), the scan runs to compare the files on your computer to the files in your existing backup archive.
- Clearing your cache: The cache includes information about your destinations and the data on your computer. When the cache is cleared, a file verification scan initiates to help rebuild this information.
- Manually: The file verification scan can be triggered at any time from Settings > Backup > Now.
If the file verification scan is in process when a backup status report is sent, the backup status report may reflect the percentage of your file selection that has been verified instead of the amount backed up. You can verify the actual size of your backup archive using Option 1 below.
There are several items you can check to verify that your backup archive is intact and that CrashPlan isn't starting your backup over.
Option 1: Verify the size of your archive
Verify that the amount of data being stored is a number that is consistent with your file selection size and previous backup completion. From Backup, click the name of the destination to view stats for the chosen destination. Under Space used, verify that this number is an amount of data reasonable for your file selection size and previous backup completion.
Option 2: Review history for scan
To confirm that the verification scan is running, you can check the History in the CrashPlan app. The messages below are typical of a file verification scan running:
06/14/13 03:00AM [Default] Scanning for files to back up 06/14/13 03:00AM [Default] Stopped backup to CrashPlan Central in 4.5 hours 06/14/13 03:00AM - Reason for stopping backup: Full filesystem scan started. 06/14/13 03:06AM [Default] Scanning for files completed in 6 minutes: 110,368 files (157.40GB) found
Option 3: Review effective speed of your backup
Another indication that CrashPlan is running the file verification scan - not backing up files - is an effective rate that is significantly higher than the sent rate.
To compare the rates, click on History in the CrashPlan app. Look for a line like this (sent and effective rates are shown in bold for this example):
I 02/09/14 12:45PM [Default] Stopped backup to CrashPlan PRO Online in 15 minutes: 439 files (558.10MB) backed up, 24.50MB encrypted and sent @ 86.2Kbps (Effective rate: 6.1Mbps)
In this case, the effective rate is 6.1 Mbps while the sent rate is only 86.2 Kbps. You may notice discrepancies that are even larger than this.
When the file verification scan is running, the effective rate is much higher than the sent rate because it takes into account CrashPlan's de-duplication of the data that's already been sent. When CrashPlan comes to a file in its to-do list that's already backed up, it adds the size of the file to the amount of data it's completed during that backup. It does this even though it didn't actually send anything.
Option 4: Review your logs
Using the backup_files.log file, you can definitively identify whether or not a file is backing up for the first time. The first two numbers summarize CrashPlan's analysis of the file:
- First number identifies new data blocks that need to be backed up
- Second number identifies old data blocks that have already backed up
If the first number is greater than zero, and the second number is zero, then it's a new file that's backing up for the first time. For example:
If the first number in the bracketed sequence is zero, and the second number is greater than zero, then it's an existing file that has already backed up. There is nothing new to back up. For example:
If both the first and second numbers are greater than zero, then it's an existing file that has already backed up but there is a new version that needs backing up. For example:
Scan working as expected
If you determine that the file verification scan is running, and that it is only detecting a minor amount of changes that the real-time file watcher may have missed, give the scan time to complete. You can still restore files while the scan is running, if necessary. If the CrashPlan app is synchronizing, you can't restore from the app, but you can perform a web restore.
The most likely explanation relates to how CrashPlan prioritizes files for backup. CrashPlan backs up your most recent changes first. When the scan finds new files for backup, these files go straight to the top of CrashPlan's “to do” list. This impacts the estimated time to complete backup because the estimate is based on the type of files the scan is reviewing (i.e., new or existing) and your current network speed.
As these new or newly modified files complete backup, CrashPlan moves on to your already-backed-up files. At that point, the effective transfer rate rises dramatically because CrashPlan sends significantly less data to your backup destinations for previously-backed up files. This is data de-duplication in action. For more information, see our article on How Backup Works.
Scan not working as expected
- File verification is running: If the scan detected a unexpectedly large amount of changes that need to be backed up, it could indicate there is a problem with your file verification scan schedule that is preventing changes from being detected on a regular basis.
- File verification scan is not running: If CrashPlan is backing up files that were previously backed up and treating them like new files, contact our Customer Champion team by sending your log files for review.