How does RSYNC "verify" integrity of a backup???

mdgm wrote:
You do an incremental backup. It compares the files on the source and destination. If the files are different (I.e. checksum doesn't match) the changes will be transferred across.

ewok wrote:
bru wrote: What I want to happen is for rsync to compare dates and checksums of the file and to not backup files that have not changed so that the network does not get hit very hard and the disks to not get too much usage. That's what rsync does, using timestamp and filesize to check if a file needs to be transferred. Using checksums would be very slow....

mdgm wrote:
Oops. I guess I was wrong then. Using file size and timestamp should be sufficient because one of those is slightly off if the file wasn't copied successfully.

PapaBear wrote:

Yes. Because of the verification process in rsync it is like watching paint dry to do a full backup with rsync. Setting it up as NFS creates the backup, and then rsync only has to verify the check figure for each file to make sure all the data is there. Then every time you run the rsync job, it only copies over the changed portions of the file, so the "incremental" is very fast. If you were going from X-86 to X-86 it would take less than 1/2 the time used by the Duo to X-86, (or X-86 to Duo) but we are still only talking minutes to update gigabytes of data. Yesterday I added about 40GB of video files to my NAS1, and checking the logs from last night, it took about 24 minutes. If this had been from my NVX to my NV+ I would anticipate it would take around 45-50 minutes. But, I don't add 40 GB of data very often.

mdgm wrote:
ewok is part of the Jedi Council so I would take his explanation over what users (e.g. myself) have thought. If it notices a different timestamp or filesize Rsync will then do the calculations necessary to transfer just the changes to the file across.

Rsync  finds  files  that  need to be transferred using a "quick check"
algorithm (by default) that looks for files that have changed  in  size
or   in  last-modified  time.

-c, --checksum This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a "quick check" that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly. The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer. Note 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, 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. For protocol 30 and beyond (first supported in 3.0.0), the checksum used is MD5. For older protocols, the checksum used is MD4.