From: David on
Hi list.

I've posted this problem to a few other lists over the past few days
(rdiff-backup, my local LUG), but I haven't had a reply yet, so I
thought I'd try here.

Short version: rdiff-backup is using 2 GB of memory (1 GB RAM, 1 GB
swap) on one of my backup servers. I'm using the latest Etch versions,
so there shouldn't be a memory leak in librsync.

Here is my (somewhat long) mail to my LUG:

http://lists.clug.org.za/pipermail/clug-tech/2008-May/040532.html

Does anyone on this list have suggestions?

Thanks in advance,

David.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Matthew Dale Moore on
I read you CLUG post. It seems like you should be able to do everything that
you want using rdiff-backup and not using your temp work directory with rsync
(which looks to be messing things up).

Also, if you are using rdiff-backup on backup1, why do you need to preserve
file history on backup2? Shouldn't the copy of backup1 on backup2 also
contain the rdiff-backup-data directory? If this is the case then you can
just use rsync to move the backup from backup1 to backup2.

MM


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: David on
Hi there and thanks for your reply.

On Wed, May 7, 2008 at 6:39 PM, Matthew Dale Moore
<Matthew.D.Moore(a)colorado.edu> wrote:
> I read you CLUG post. It seems like you should be able to do everything that
> you want using rdiff-backup and not using your temp work directory with rsync
> (which looks to be messing things up).

Last time I checked, rdiff-backup only works over a network if you
have rdiff-backup on the other side. This means that for Windows boxes
we would need to install Cygwin etc. If there was a simple Windows
installer for rdiff-backup (similar to DeltaCopy for rsync) it would
be another story.

Also, I don't trust rdiff-backup as much as I do rsync. It seems a bit
too complicated/fragile by comparison. Rsync is very robust, simple,
and works every time. The only reason I use rdiff-backup is because of
it's reverse delta support. I would prefer to replace rdiff-backup if
possible, rather than rsync.

And finally, we already have rsync on most of the workstations (after
a long period of phasing it in, to enable faster backups than with SMB
shares). There would need to be a strong reason to change from rsync
(on the machines being backed up) to rdiff-backup.

>
> Also, if you are using rdiff-backup on backup1, why do you need to preserve
> file history on backup2? Shouldn't the copy of backup1 on backup2 also
> contain the rdiff-backup-data directory? If this is the case then you can
> just use rsync to move the backup from backup1 to backup2.
>

This is for a few reasons:

1) I'm using the same backup script on both servers (with different
config). It would be extra work to disable the rdiff-backup part.
2) If backup1 looses data, and backup2's backup runs, I don't want to
lose the data from backup1 at that time
3) I also want to keep history for the entire backup1 (not just the
backups). This is so I can restore the entire backup1 server as it
was X days ago if there are problems.

David


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Matthew Dale Moore on
On Wednesday 07 May 2008 11:58:20 am David wrote:
> Also, I don't trust rdiff-backup as much as I do rsync. It seems a bit
> too complicated/fragile by comparison. Rsync is very robust, simple,
> and works every time. The only reason I use rdiff-backup is because of
> it's reverse delta support. I would prefer to replace rdiff-backup if
> possible, rather than rsync.

If you are looking for a replacement, I don't know of any that do rdiffs
besides rdiff-backup. I think that a good incremental backup would be your
best option.

It looks like all the stuff with making the hardlinks and temp directory are
to avoid a potential conflict between the existing "rdiff-backup-data"
directory on backup1 and the other "rdiff-backup-data" directory that gets
written to on backup2. If backup1 and backup2 both have rdiff-backup
installed then you can do something like

rdiff-backup backup1::/backup/files /backup/path/on/backup2 --exclude
**rdiff-backup-data**

on backup2. This avoids making hardlinks and a temp directory and also avoids
your problem of having the two "rdiff-backup-data" directories conflicting.

MM


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org