BackupPC-users

Re: [BackupPC-users] Uneffective rsync transfers?

2014-06-30 03:55:58
Subject: Re: [BackupPC-users] Uneffective rsync transfers?
From: Holger Parplies <wbppc AT parplies DOT de>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Mon, 30 Jun 2014 09:55:15 +0200
Hi,

Les Mikesell wrote on 2014-06-28 20:15:30 -0500 [Re: [BackupPC-users] 
Uneffective rsync transfers?]:
> On Sat, Jun 28, 2014 at 3:31 AM, Franti??ek Starý <frantisek AT stary DOT 
> net> wrote:
> >
> >> Every file should show at least 2 links [...] but those files show a
> >> lot more. [...]
> >>
> > The count of hard links is high because all the testfiles have the same
> > content and I have more backups and more testhosts. Its a proof the
> > pooling works. But the merging of the backups made using rsync xfer
> > method not (although using tar xfer method works good).

technically, it's not "merging", it's "building a view". Backups are not first
built sparsely and then filled in. The links should be created at the point in
the transfer where BackupPC detects that the file is unchanged.

But I have to correct myself. Building an incorrect view can't be the cause,
because then the file would simply be transfered (and logged as "pool" instead
of "same"). Maybe we should think more closely about the rsync on the *remote
end*, the host to be backed up. I'm not quite sure which side (of rsync) is
responsible for doing the file list comparison, and I haven't really got the
time to look right now, but failing to detect/signal unchanged files would
result in exactly what you see.

There *might* be traces of this in the attrib files, though for full backups,
I guess there would not be. If you like, you can send them to me (off-list,
preferably), and I'll have a look.

> [...]
> That is the way an incremental should look at the filesystem level,

We're talking about full backups here.

> I think you are the first person to report anything like that,

I agree.

> [...] I'd be inclined to start with a fresh install in a VM to
> get something that works normally and then try to compare the systems.

Well, aside from looking at the *remote end*, I'd suggest starting with
'debsums' to verify the integrity of at least the packages involved, though it
can't really hurt to let it check the whole system (it's probably faster that
way than finding out exactly which packages would need to be checked, although
backuppc and libfile-rsyncp-perl are the main candidates).

A rather easy way to check the remote end would be to set up an rsync backup
of a different host - the more different, the better. Basically, any (UNIX)
system you have at your disposal should do. My preference would be either a
rather old or a rather new system (different version of rsync is the key).

Regards,
Holger

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/