How should a user of OS X verify whether backed up data comprises everything required for lossless restoration?

n8gray.org: Backup Bouncer

Improvements to Backup Bouncer were noted in March 2012 by Mike Bombich, developer of Carbon Copy Cloner.

rsync dry run with checksumming to include extended attributes, resource forks and ACLs

Basics

From the rsync(1) Mac OS X Manual Page:

  -c, --checksum

This forces the sender to checksum every regular file using a 128-bit MD4 checksum. It does this during the initial file-system scan as it builds the list of all available files. The receiver then checksums its version of each file (if it exists and it has the same size as its sender-side counterpart) in order to decide which files need to be updated: files with either a changed size or a changed checksum are selected for transfer. Since this whole-file checksumming of all files on both sides of the connection occurs in addition to the automatic checksum verifications that occur during a file's transfer, this option can be quite slow.

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking its whole-file checksum, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer "Does this file need to be updated?" check.

   -E, --extended-attributes

Apple specific option to copy extended attributes, resource forks, and ACLs. Requires at least Mac OS X 10.4 or suitably patched rsync.

   -n, --dry-run

This tells rsync to not do any file transfers, instead it will just report the actions it would have taken.

Considerations

I assume that when options --checksum and --extended-attributes are combined, the checksum includes the attributes.

A 2010 discussion in Bombich Software Support may help to clarify – verify with rsync -- symlink mismatches on Tiger