BackupPC-users

Re: [BackupPC-users] Change RsyncShareName - will BackupPC reuse existing backup data?

2008-07-23 19:31:07
Subject: Re: [BackupPC-users] Change RsyncShareName - will BackupPC reuse existing backup data?
From: Holger Parplies <wbppc AT parplies DOT de>
To: Michael Stucki <mundaun AT gmx DOT ch>
Date: Thu, 24 Jul 2008 01:30:13 +0200
Hi,

Michael Stucki wrote on 2008-07-23 16:49:49 +0200 [Re: [BackupPC-users] Change 
RsyncShareName - will BackupPC reuse existing backup data?]:
> 
> Well, so if BackupPC doesn't know it, I should probably follow Adams
> suggestion and simply rename the directory? I will try that, but maybe
> someone already knows if that's really so simple?

I didn't suggest it for the simple reason Adam mentioned: you will probably
need to modify the attrib file. While that's not hugely complicated, it does
involve a bit of programming. If it's your only [reasonable] option, I'll look
into it.

> > Aside from that, why didn't you use rsync over ssh or sudo instead of
> > rsyncd for the initial local backup (of course the paths would still have
> > to match, but maybe chroot can help there)? That seems even more
> > straightforward than naming the rsyncd module according to
> > what the real path is.
> 
> Because rsync over SSH compresses the data and rsyncd doesn't. That means
> it's less CPU intensive - or am I wrong?

You probably mean encrypt, not compress (though ssh *can* compress if asked
to). As for CPU usage, you are correct. It should however not make enough
difference to worry about for a one time local backup intended to speed up
a remote transfer. In any case, you can use sudo instead of ssh to localhost
to avoid the encryption/decryption overhead. As Adam says:

Adam Goryachev wrote on 2008-07-23 23:41:42 +1000 [Re: [BackupPC-users] Change 
RsyncShareName - will BackupPC reuse existing backup data?]:
> 
> [...] If you are trying to save a few hundred meg on a multi megabit link,
> then I'd suggest don't bother, it will be easier. If you are trying to save
> multi-gigabyte data over a small link, then persevere, I am sure someone
> will help solve the problem for you.

So your options seem to be (in order of increasing difficulty):

1. Let the remote transfer finish. Subsequent transfers will be faster.
2. Try renaming the directory without touching the attrib file and see if
   that works.
3. Redo the local backup with rsync/ssh or rsync/sudo.
4. Rename directory and modify attrib file (note that attrib files are
   pooled!)

Please be sure to tell us if (2) works, for us, the archives, and the
wiki :).

Regards,
Holger

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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/