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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/