[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] How does rdiff-backup really detect changed fil
Re: [rdiff-backup-users] How does rdiff-backup really detect changed files?
Sun, 10 Apr 2016 10:10:41 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
On 04/10/2016 09:15 AM, David Croll wrote:
Dear wizards of rdiff-backup,
as a user of rdiff-backup and main author of the German Wikipedia page
on rdiff-backup I want to ask you a few questions because the manual
pages are not very clear on this:
- Is SHA-1 always used to determine if a file has been modified?
Absolutely not! That would require running sha1sum over every file in
the source directory, which could take many hours or even days for a
complete system with terabytes of data. What is tested are those fields
in the inode that are also stored in the latest mirror-metadata file:
type, size, mtime, uid, gid, and permissions. For non-directory files
with more than 1 hard link that also includes the device and inode
numbers unless the --no-compare-inode option is used.
- What is the exact meaning of the --verify, --compare-hash and
The --verify and --verify-at-time options check the internal consistency
of the archive. Every file is reconstructed from the mirror + diffs, and
its sha1sum is compared with the stored value.
The --compare-hash and --compare-full options (and their *-at-time
variants) compare the current contents of the source with the
archive. The --compare-hash option just computes the sha1sum of the
source files and compares that against the metadata stored in the
archive. The --compare-full option actually reconstructs each file from
the mirror + diffs and compares that file byte-by-byte with the source.
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.