BackupPC-users

Re: [BackupPC-users] Status of fuse for viewing backuppc backups

2008-12-29 20:56:30
Subject: Re: [BackupPC-users] Status of fuse for viewing backuppc backups
From: "Jon Craig" <cannedspam.cant AT gmail DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Mon, 29 Dec 2008 20:54:01 -0500
On Mon, Dec 29, 2008 at 7:53 AM, Craig Barratt
<cbarratt AT users.sourceforge DOT net> wrote:
> Tino writes:
>
>> BTW: Why would that ease support for rsync 3.x? (Just curious.)
>
> Instead of updating File::RsyncP to rsync 3.x protocol, the idea
> would be to use native rsync on both sides of the connection,
> and the BackupPC trickery would be hidden behind FUSE.
>

The POC work I did on a FUSE interface for BackupPC never got to a
point that was useful / releasable.  What I quickly identified was
that there were two approaches to doing a FUSE interface.  The first
was an interface that provided a fileystem layout over top of BackupPC
(which is what I did) to provide fileystem type access to the backup
catalog via BackupPC API.  The second approach would involve a rewrite
of BackupPC to extract the "dedupe" functionality and place it within
the filesystem to provide an abstracted storage layer.

The second approach is ultimately more interesting as it is no longer
an extension of BackupPC and becomes a product that would stand on its
own.

BackupPC - Config, Schedule, Catalog Interface, Alert Notification
FUSE Storage Engine - Dedupe, Catalog Replication for Disaster
Recovery, General Interface to catalog
Rsync -  Replication Protocol
SSH - Transport Protocol

One weakness I can see with eliminating the Perl interface comes in
the area of MD4 caching.  Currently, BackupPC can speed the MD4
process by caching signatures to avoid recalculating MD4 hashes.
While it would be trivial to extend the FUSE filesystem to store MD4
hashes, the generic rsync command doesnt provide an interface for
providing these values to avoid the client from calculating the hashes
on its own.

The other thing I struggle with is how complex to make this storage
layer.  Do you tie it to a database (like mysql) to offload
replication and speed access to file metadata (list generation and
access to cached MD4).  Do you extend rsync to provide hooks to make
use of this functionality?


Hmm, how big is this elephant and where do you start and how do you
know when your done.


-- 
Jonathan Craig

------------------------------------------------------------------------------
_______________________________________________
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>