[Top][All Lists]

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

Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

From: Robert Nichols
Subject: Re: [rdiff-backup-users] Incredibly slow i/o to NAS server
Date: Sun, 4 Dec 2016 08:58:08 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0

On 12/03/2016 09:32 PM, Andrea Bolandrina wrote:
Bob - yes, lots of files under /mnt/vms/docker/ have more than one hard link.
I might try your suggestion (--no-compare-inode) if I run into trouble again.
What problems does rdiff-backup have with hard linked content?
As far as I know hard links should be supported...

Supported?  Yes, but with plenty of bugs.  If links are added and removed from 
a set, you can end up with two or more separate subsets (i.e., what should be a 
set of 10 links to a single file becomes 3 files with link counts of 3, 5, and 
2), and the link arrangement in the metadata files won't always match the link 
arrangement in the mirror.  The checksum is stored only for the first link in 
the collating sequence.  If that first link gets deleted, the checksum is lost. 
 If a link with a path that comes earlier in the collating sequence is added, 
it sometimes does not inherit the checksum.  I have a massive and 
time-consuming audit that I run after every backup session to patch that up.

Verification always complains about missing checksums for all the links that do 
no have one stored.  I have to filter out all the verbose 2-line messages for 
those from the verification report.

And of course there is the issue I mentioned with huge numbers of zero-diff 
increment files if the device number changes, and that device number can vary 
randomly when LVM and/or encrypted devices are involved.  My only solution for 
that is a script that refuses to run the backup if the device numbers don't 
match what was previously recorded.

I really want to look into SafeKeep <http://safekeep.sourceforge.net/> as an 
alternative, but I haven't had a chance to do that.

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]