On Sun, 2007-02-25 at 16:07 -0800, Eric wrote:
Yes and no. Basically, when /rdiff-fs/10-11-2007/some/file is accessed,
it performs a
"rdiff-backup --restore-as-of 10-11-2007 /backups/some/file /tmp/file" and
proxies the IO on /rdiff-fs/10-11-2007/some/file to /tmp/file. When
close() is called on the proxy'd IO, /tmp/file can be deleted. I am
thinking of using this method so that users who need to restore files can
SFTP into the server, traverse to the directory they want to read and pull
the files as if they are real files instead of reaching them rdiff-backup
command line options (...they are generally windows monkies). Opening a
file would be slow since each open() invokes rdiff-backup --restore, but
some read-ahead like inteligence might help this out.
Eric,
This makes sense - I didn't have a clear picture how the 2 tools
co-existed before.
(http://rdiffbackupweb.sourceforge.net/) - I'm removing the MySQL stuff
and the ability to create backup sets, and going more for a "viewer"
interface. The one thing I haven't added yet is the ability to do user
security... Not totally sure how to do that one, because of my target
Anyway, if you're interested I can throw the code your way - It's a
single page, and for now does no security - I'm relying on a single
"admin" user via apache security. The page has a calendar and a "backup
set" selector, and for a given date, time, and backup set, it will show
a folder hierarchy which uses <div> tags to hide/show the folders &
subfolders. Really clean UI, takes a few seconds to load larger folders.