On Thursday 08 December 2005 17:09, Mordechai T. Abzug wrote:
> On Thu, Dec 08, 2005 at 02:49:22PM +0100, Kern Sibbald wrote:
> > Bacula's Base project will accomplish something similar, but *much*
> > more secure from the stand point of making a false match.
>
> [snip]
>
> Would you also consider allowing an option to do away with the
> requirement to explicitly specify the base backups? Or,
> alternatively, an option to make all backups be considered base
> back-ups? :)
Since the project isn't yet started, it isn't fully defined, but other than a
few small details, I don't expect a base backup to be any different from any
other backup. The difference might simply be in calling it a "Base" level
backup, and possibly applying different pruning rules to it. To be
defined ...
>
> OS patches, application patches, and popular documents are moving
> targets, so I don't want to have to manually specify a base.
I'll probably not eliminate the requirement to make and specify a Base job
because in a large shop, doing so would be disasterous from a performance
stand point. This may change as the project develops or as we understand the
problem better. Typically, a base might contain everything in /usr, and /bin
for example.
> Meanwhile, crypto hash algorithms such as SHA-1 typically have
> collision rates on the order of 1 in 2^69 (even with the recent
> weaknesses), and I only have a few million files, so I'm not too
> worried about accidental hashes. You're more likely to have a media
> error than a collision! But if you really want to be paranoid, maybe
> have an option to actually compare, byte by byte, the two files in
> question, either using the copy on tape or by asking the previous host
> to send it again? It would make your tape drives and/or your hosts
> more busy, but it would eliminate any possibility of a hash collision
> leading to lost data.
>
> > > > I've been using AMANDA for a while, particularly because it can
> > > > easily support bare-metal-recovery and it's free.
> >
> > 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 ...
>
> I wasn't comparing AMANDA to Bacula, since I don't know Bacula. But
> AMANDA bare-metal recoveries are easy. AMANDA is typically configured
> to use system native backup/restore tools on the backend --
> dump/restore, tar, cpio, whatever. The tape has an AMANDA-specific
> header, but you can just mt fsf over it. So, you get AMANDA to print
> out a copy of that night's backup tape layout and dumplevels after
> making the backup, and you keep the last few sheets. Then, if you
> need to do a bare-metal recovery, you can just read through the sheets
> and figure out which tape files need to be restored (ie. latest level
> 0, then latest level 1 if more recent than level 0, etc.) Then mt fsf
> to the right entry on the tapes, and run restore, tar, or whatever to
> pull the data off. No AMANDA-specifics needed.
>
> Of course, since AMANDA uses the system native tools, it is limited by
> their capabilities. For example, if your OS native dump/restore
> doesn't support exclude lists, and you need exclude lists, you could
> have trouble. If you use tar instead, you're likely to run into tar
> limitations such as ACL support. And, of course, a "Base" or single
> instance storage setup would probably not fit in the design, either.
> I didn't even bother asking.
>
> Thanks, Russell, Kern, and Phil, for answering my questions! It's
> nice to see an active community.
>
> - Morty
--
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
