Does Back In Time Checksum?

No. BIT use rsync to take snapshots (and check that the snapshots are done OK). If rsync reports OK, BIT will say OK too. You can check rsync on google to get more informations.

Regards,
Dan

> I'd like something that generates checksums of files as it backs them up...

BiT doesn't indepenedently store just checksums to a file, but...

> ...and has the ability to "check" the backup archive's files and compare the
> checksums to make sure the backup archive has not been corrupted.

If you enable "Use checksum to detect changes" in Settings -> Options, I believe BiT will pass the --checksum (-c) option to rsync, so that it uses a checksum (MD5 hash) to compare the current file version with the version from the last session.

However, if a difference is found, you won't get a warning of corruption. rsync will simply recognize it as a change in the source data and overwrite the backup copy so it faithfully matches the source.

Using the checksum option will likey considerably slow down the backup process compared to the default behavior of comparing only file sizes and time stamps. This option requires reading every byte of both the source and destination copy of each file in your backup set.

The rsync man page notes that, "rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred," and that happens regardless of whether --checksum is used. But this is to catch transmission corruption, which doesn't apply to BiT's use of rsync, where only one rsync instance operates by making a local disk-to-disk copy (even if one disk is a network share). This post-transfer checksum also doesn't catch corruption introduced by your storage system (disk) or that happens after the transfer.