On Thursday 08 December 2005 14:27, Russell Howe wrote:
> Mordechai T. Abzug wrote:
> > On Thu, Dec 08, 2005 at 12:05:40PM +0000, Russell Howe wrote:
> >>If you look at the recent "Project voting" email, I think this is what
> >>Kern terms "Base Jobs". In short, no, not yet, but it's planned I think.
> >
> > Ah, thanks. I've only just joined the list, but the archives have it.
> > "Base jobs" sounds similar, but not quite the same -- the intent of
> > this is to catch not only OS and apps, but even data files that are
> > identical (ie. a bunch of users have a copy of the same 50MB
> > powerpoint presentation), and it (should be) automatic.
>
> If things were implemented the way you describe below, then it would
> seem that base jobs would be possible as a specific case, with no code
> changes needed.
>
> > Ie. after
> > archiving any file, you store the file size and the crypto checksum in
> > a DB, right? If you later encounter another file with the same size
> > and crypto checksum, instead of backing it up, you put a reference in
> > your DB that says it's the same content as the earlier file. Restores
> > may take longer, because files are spread out, but if the restore
> > software is smart, it should be able to reorder its queries so it only
> > needs to make a single pass over the backup media.
>
> I think this would be a lovely feature to have, but it's not the way
> bacula works at the moment, and it would probably require quite some
> code changes, and changes to the way restore behaves. I guess care needs
> to be taken here - restores are not something you want to break :)
Bacula's Base project will accomplish something similar, but *much* more
secure from the stand point of making a false match. In the Bacula model,
instead of Bacula just blindly looking at all files, the user must
*explicitly* backup the files he/she desires to be used as a *base* for
comparison. The user can have any number of such backups. Bacula will then
compare the time/date, size, and hash code of any files on the system having
*exactly* the same name, including the path. If they all match, then the
file will not be backed up again. I see no reason to add a few more options
to this scheme for those who want to live a bit more dangerously -- for
example, I could imagine allowing a different time/data, and different paths,
but these would be optional. Those of us who are more conservative would get
the conservative options by default. Note, one nice thing is that Landon
has added two more hash codes, which are *much* more secure (i.e. much less
chance of a false match), but take more time to compute.
>
> > I've been using AMANDA for a while, particularly because it can easily
> > support bare-metal-recovery and it's free.
For Mordechai:
I haven't looked at AMANDA's bare metal recovery, but if someone thinks it is
easier to use than Bacula's, I would appreciate to hear about it ...
> > But I'd like something
> > that supports single instance storage, and has better support for
> > multiple volumes per backup. Guess bacula isn't it, at least not yet.
> >
> > :(
>
> No, although you could possibly emulate it by sticking whatever backupPC
> commands you need to use as a ClientRunBeforeJob and then backing up the
> backupPC tree, although restores would be irksome.
>
> The multiple volumes per backup bit is quite a 'selling point' for
> bacula in the open source backup world at the moment I think.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
