BackupPC-users

Re: [BackupPC-users] Change Archive Directory

2009-06-09 06:47:42
Subject: Re: [BackupPC-users] Change Archive Directory
From: Holger Parplies <wbppc AT parplies DOT de>
To: Filipe Brandenburger <filbranden AT gmail DOT com>
Date: Tue, 9 Jun 2009 12:44:00 +0200
Hi,

Filipe Brandenburger wrote on 2009-06-08 23:36:33 -0400 [Re: [BackupPC-users] 
Change Archive Directory]:
> On Wed, Jun 3, 2009 at 22:25, jbk<jbk AT mail2.gis DOT net> wrote:
> > [...] What I am
> >  not seeing is any pooled data. I am using the Fedora
> > distribution (10) binary of Backuppc. When I originally set
> > up the archive directory I pointed it to an external usb
> > disk that is mounted in a location that is not in the
> > original "topdir" path.
> 
> BackupPC-3.1.0-4.fc10 has a patch that fixes this exact issue.
> 
> >From the changelog:
> 
> * Sat Apr 11 2009 Johan Cwiklinski <johan AT x-tnd DOT be> 3.1.0-4
>   - Fix TopDir change (bug #473944)
> 
> If you upgrade, you might not need to change mountpoints or use bind
> mounts, your configuration file might start working as supposed to
> then.

yes, but however you fix it, you should be aware that you won't get pooling
for already completed backups. Until they expire, they will contain
independent copies of files. What's worse, rsync backups will hardlink 'same'
files to the reference backup file (which will be outside the pool as long as
it remains unchanged).

A simple example:
If you backup /lib on 10 machines, you will have 10 independent copies of all
those files to start with. As new files appear or existing ones are changed
(which is probably only if you install new packages or update existing ones
that have files there), these will be placed in the pool and shared among
machines (and with possible other occurrences of the same content). Unchanged
files will remain outside the pool and unshared even when all now existing
backups have expired and been replaced by new backups.

An even better example might be a source file tree where you have many - at
this point unshared - occurrences of CVS/Root and CVS/Repository. These are
typically never changed, so they will remain unshared forever, even if the
actual source code enters the pool over time.

Again, that applies to *rsync(d)* backups only. tar/smb have no notion of a
'same' file (meaning unchanged since the reference backup) [well, incrementals
don't transfer unchanged files as per timestamp, but full backups will
transfer everything], so everything actually transferred will be put into the
pool, regardless of where it was in earlier backups.


To sum it up: nothing will get worse than it is now, but not everything will
get fixed either - if you are using rsync, not even eventually. This may or
may not be a problem for you (it will only waste disk space, nothing worse).
If you have the bandwidth, you might consider changing to tar (or smb) Xfer
for one full backup. Or, of course, consider things messed up and start with
a fresh pool.


These thoughts appear courtesy of recent reiserfs corruption :-|.

Regards,
Holger

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
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/