BackupPC-users

Re: [BackupPC-users] BackupPC Pool synchronization?

2013-03-07 09:17:19
Subject: Re: [BackupPC-users] BackupPC Pool synchronization?
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: Thu, 7 Mar 2013 15:15:49 +0100
Hi,

Les Mikesell wrote on 2013-03-06 13:42:17 -0600 [Re: [BackupPC-users] BackupPC 
Pool synchronization?]:
> On Wed, Mar 6, 2013 at 12:16 PM, Mark Campbell
> <mcampbell AT emediatrade DOT com> wrote:
> > Interesting.  Well then I guess the answer is to not muck with pooling (as 
> > redundant as it is, at least it theoretically shouldn't hurt anything), 
> > disable compression, and enable dedup & compression on ZFS.
> 
> Yes, I'd do that and try out the mirroring and send/receive features.
> If you are sure everything else is good you can probably find the part
> in the code that makes the links and remove it.

It's a bit more than one "part in the code". *New pool entries* are created
by BackupPC_link, which would then be essentially unnecessary. That part is
simple enough to turn off. But there's really a rather complex strategy to
link to *existing pool entries*. In fact, without pooling there is not much
point in using the Perl rsync implementation, for instance (well, maybe the
attrib files, but then again, maybe we could get rid of them as well, if we
don't use pooling). It really sounds like a major redesign of BackupPC if you
want to gain all the benefits you can. Sort of like halfway to 4.0 :).
Basically, you end up with just the BackupPC scheduler, rsync (or tar or just
about anything you can put into a command line) for transport, and ZFS for
storage. Personally, I'd probably get rid of the attrib files (leaving plain
file system snapshots easily accessible with all known tools and subject to
kernel permission checking) and the whole web interface ;-). Most others will
want to be able to browse backups through the web interface, which probably
entails keeping attrib files (and having all files be owned by the backuppc
user, just like the current situation). Then again, 'fakeroot' emulates
root-type file system semantics through a preloaded library. Maybe this idea
could be adapted for BackupPC to use stock tools for transport and get attrib
files (and backuppc file ownership) just the same.

ZFS is an interesting topic these days. It's probably best to gain some
BackupPC community experience with ZFS first, before contemplating changing
BackupPC to take the most advantage. Even with BackupPC pooling in place,
significant gains seem possible.

Regards,
Holger

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
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/

<Prev in Thread] Current Thread [Next in Thread>