[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] How does rdiff-backup really detect changed fil

From: Robert Nichols
Subject: Re: [rdiff-backup-users] How does rdiff-backup really detect changed files?
Date: Sun, 10 Apr 2016 10:10:41 -0500
User-agent: 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
compare-full options?

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]