Pieter Wuille wrote at about 21:40:46 +0200 on Tuesday, June 2, 2009:
> On Tue, Jun 02, 2009 at 12:31:54PM -0400, Jeffrey J. Kosowsky wrote:
> > Pieter Wuille wrote at about 17:57:06 +0200 on Tuesday, June 2, 2009:
> <cut>
> > > If anyone's interested at trying/looking at it:
> > > https://svn.ulyssis.org/repos/sipa/backuppc-fuse/backuppcfs.pl
> > >
> <cut>
> > > It is only tested on one 3.1 backuppc pool on a Ubuntu 8.04 system, and
> > not
> > > very extensively. It only opens files/directories in read-only mode,
> > thus
> > > shouldn't be able to damage a working backuppc pool if something goes
> > wrong.
> > >
> > > I'd like to get some feedback; ideas, bugreports, ... are very welcome.
> >
> > Just took a quick spin on it -- looks AWESOME!
> > In my mind this is the way to go and *much* more useful and infinitely
> > faster than trying to navigate the web interface. This gives me
> > *exactly* what I want which is rapid access to all my backup files in
> > a CLI format that allows me to apply common *nix utilities like 'cp',
> > 'less'
> > 'grep', 'diff' etc. to examine and manipulate different backup
> > versions.
> Thanks :)
>
> > Couple of questions/comments:
> > 1. Is there anyway to get the root share directory to mount as '/'
> > rather than as '_/"? Having root mount differently detracts a
> > little from the naturalness of it all.
>
> It shouldn't be too hard to change that. The only problem is what to do when
> you have a '/' share and a '/etc' share, and he '/' share contains a 'etc'
> dir/file/.... probably won't occur, and i agree it's a more natural way.
You could always add a flag that would add an (arbitrary) base name to
the root share if needed.
>
> > 2. What happens when a new backup is run while the fusefs is mounted?
> > Is there an easy way to get the new backup to appear automagically
> > or do you need to unmount/remount?
> Refreshing of nodes in the directory cache occurs when:
> - an expire happens (depending on where in the filesystem, the TTL is
> either 80000s, 40000s or 1000000s (see the source code))
> - there's a request for something inexisting. eg. if a new backup #35
> is created while the cache only has backups up to #34, and you'd do a
> "cd 35" even though "ls" does not show a dir '35', it should work
> (and the 35 should exist afterwards in the listing too) - untested though
Would a refresh of the parent node catch a newly created backup before
the timeout?
> > 3. What happens when a backup is expired or deleted while the fusefs
> > is mounted?
> Completely untested... i assume a lot of errors might occur when you try to
> read files - maybe empty files, crashes, ...
> Errors don't propagate upwards in the tree, so only a refresh of the parent
> node in the tree would fix it - so either an expire or the request of
> something
> inexisting.
Probably should be tested at some point... and then behaviors adjusted
to minimize the nastiness of and maximize the recovery from any
resulting errors.
> > 5. It might be nice to add a feature that allows you to get info on
> > the backup itself - say time/day created, incremental level,
> > etc. Also, it might be nice to be able to print an ascii tree of
> > the backup hierarchy. I know this is not strictly speaking part of
> > any fuse filesystem but it would be a nice companion CLI accessory
> > since now when I start listing backups I realize that I only see
> > the 'number' and don't get a good handle on the other data about
> > the backup.
> I've thought about this myself too - just not sure in what format and where.
> The information you can get from backuppc about a host is limited, but you
> can get somewhat more about specific backups. Creating one or more "files" in
> a "host"-directory is quite simple, but inside the backup#-directories is
> harder (since there may be real backup data already there if you have a '/'
> share).
> About the CLI tool: do you mean 'tree' ?
Yeah a tree something like the way pstree displays: e.g.,
Machine 1:
1 +
|- 2 +
| |- 3 +
| |- 4 +
|- 5 +
|- 6 +
|- 7 +
8 +
|- 9 +
|- 10
Machine 2:
1 +
|- 2 +
| |- 3 +
| |- 4 +
|- 5 +
|- 6 +
|- 7 +
8 +
|- 9 +
|- 10
> > 6. If it is too complicated to make the filesystem writable at the
> > individual file level by allowing the deletion of individual files,
> > an easier first step would be to allow the deletion of backups (and
> > all descendants backups). This is a *much* easier problem than
> > individual file deletion and only requires deleting the root
> > directory trees and deleting the corresponding lines from the
> > 'backup' log file.
> Currently all data comes from the BackupPC libraries itself, and i'd like to
> keep it that way for now. Such modifications to the tree require some
> duplication of knowledge about backuppc backups.
OK - but it is a fertile area for future development...
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
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/
|
