cer · August 29, 2015 14:27
diff --git a/CrashplanCorruption.txt b/CrashplanCorruption.txt
 When files are uploaded to CrashPlan, a checksum is generated for the file, but is not verified immediately upon receipt.

 These checksum values are logged and checked when archive maintenance is performed on the archive, every 7 days.
 If CrashPlan were to verify the checksum for each file upon receipt, this would cause each file's upload to take considerably more time to complete, relatively speaking.
 Plus, if the drive that the source data was being backed up from was failing, this could potentially cause the drive to fail much more quickly, as there would be a great deal more disk I/O, caused by the file block verification occurring on a per-file basis, while being backed up.

 By default, CrashPlan gathers the data that has been collected by a process known as a file verification scan on a daily basis, and then uses this file block information to analyze the files that exist in the backup archive.
 If CrashPlan runs into any files that do not match the checksum, it attempts to self-heal the archive, usually by attempting to fetch a valid, verified copy of the file(s) from the source device.

 If CrashPlan has not had a chance to perform maintenance on data that has recently been uploaded, and finds that the checksum of the restored file does not match the checksum that was generated when the file was uploaded, it causes errors to occur, exactly like the errors that you received during the restore process.

 So, in this particular scenario, the term "Corrupt" is referring to a file that, when restored, did not match the checksum of that file that was backed up.
	When files are uploaded to CrashPlan, a checksum is generated for the file, but is not verified immediately upon receipt.

	These checksum values are logged and checked when archive maintenance is performed on the archive, every 7 days.
	If CrashPlan were to verify the checksum for each file upon receipt, this would cause each file's upload to take considerably more time to complete, relatively speaking.
	Plus, if the drive that the source data was being backed up from was failing, this could potentially cause the drive to fail much more quickly, as there would be a great deal more disk I/O, caused by the file block verification occurring on a per-file basis, while being backed up.

	By default, CrashPlan gathers the data that has been collected by a process known as a file verification scan on a daily basis, and then uses this file block information to analyze the files that exist in the backup archive.
	If CrashPlan runs into any files that do not match the checksum, it attempts to self-heal the archive, usually by attempting to fetch a valid, verified copy of the file(s) from the source device.

	If CrashPlan has not had a chance to perform maintenance on data that has recently been uploaded, and finds that the checksum of the restored file does not match the checksum that was generated when the file was uploaded, it causes errors to occur, exactly like the errors that you received during the restore process.

	So, in this particular scenario, the term "Corrupt" is referring to a file that, when restored, did not match the checksum of that file that was backed up.