|
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:1.9.2.18) 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 affected. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
[Prev in Thread] | Current Thread | [Next in Thread] |