[Top][All Lists]

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

Re: [rdiff-backup-users] Activity

From: Robert Nichols
Subject: Re: [rdiff-backup-users] Activity
Date: Mon, 01 Aug 2011 09:29:54 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Red Hat/3.1.11-2.el6_1 Thunderbird/3.1.11

On 08/01/2011 08:02 AM, address@hidden wrote:
and I would add:

* ability to run a thorough verification of an rdiff-backup archive.
The current verification process is flawed as has been discussed in
earlier threads here. The best strategy at the moment is to run a
verification for a date at or earlier than the earliest backup run
date, and then to run one or two backups for dates between the
earliest date and the current date, but although this provides 'high
confidence' about the integrity of the overall archive it does not,
at least from a theoretical point of view, guarantee that the full
history of all files, whether currently present or deleted, can be
recovered. The only way to get this at present is to run a separate
verification for every previous backup run, which is not realistic
for a long-standing repository.
* add a switch to enable 'forced' regression of an archive. At present
rdiff-backup will only regress an archive that it considers to be
broken. (However you can work around this limitation.)

and I would add:

* Correct handling of hard-linked files.  This is currently broken in
two places.  (1) During a verify operation, rdiff-backup will
complain about a missing checksum for each link other than the one
that appears first in the mirror_metadata file.  (2) If you add more
hard links to a file that already had multiple hard links, then a
restore operation may result in those links being divided into two
or more groups, each with its own, independent copy of the file.

Auditing the database to detect and correct item (2) is decidedly
non-trivial since the reverse-diffs of the metadata file are also

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]