On Dec  2, 2000, Chris Karakas <[EMAIL PROTECTED]> wrote:

> "But it is the interplay of tar, vfat and the Linux kernel, all of which
> are out of AMANDA's influence", you will say. This is correct, but it is
> exactly the problem here: in order to compute incrementals, AMANDA
> relies on mechanisms which in my special case do not work.

Not true.  I agree it doesn't work out of the box, given how unusual
your configuration is.  It's just like introducing support for a new
kind of backup program: it may take a little bit of effort, but it can
be done, because Amanda is not a backup program, it's a backup manager
that tells backup programs when to do their job and manages to get the
output they create (the so-called backups) out to tape in a very
efficient manner.

You might as well decide to use zip as the backup program, and
convince Amanda to use it.  Now, if the kernel of the OS you run fails
to handle files whose pathnames are longer than 2 MB, would you blame
Amanda?  Or zip?  Or the kernel?

If Windows NT crashes while serving files to a client (which is what
smbtar is), how can you claim it might possibly be Amanda's fault?

I'm unfortunate enough to have a couple of NT boxes around that are in
the backup system I help to run, and NT has never crashed on that.
Maybe it's just a matter of installing a service pack?  Maybe the
crashes elsewhere are caused by some other service installed on the NT
box that gets Windows NT confused (not unusual :-) to the point that
it crashes?  It just can't be said that it's Amanda's fault: any other
tool that relied upon the SMB protocol to backup the files in the
Windows NT server would likely fall victim of the same bug in Windows
NT.  OSs aren't supposed to go crashing just because someone asks them
to do something they claim to be able to do.

> I don't care if the mechanisms are out of AMANDA's influence - this
> is a design issue.

Indeed.  Amanda is designed to be a backup manager, that knows how to
use a couple of existing backup tools.  If none of them fit your
needs, well, then you just have to go find some backup program capable
of backing up stuff you need and plug it into Amanda.  See?  It's not
Amanda's fault.

> If you say that AMANDA can backup SAMBA shares, people will believe it
> and be happy.

And they can believe it.  I do it every day.  Many others do it.  Just
because it fails for some unlucky souls, it doesn't mean it doesn't
work at all.  Most likely, it's some detail in these souls' setups
that can be easily fixed.

> The case that does not work is when you have a dual boot system
> (Win/Linux) and the SAMBA shares you are trying to backup with
> AMANDA (when running Linux) are the vfat partitions of Windows.

Ok, so how about this idea: get Plex86 or VMWare, boot Windows atop
GNU/Linux, share the disks you want to back up and tell Amanda to back
them up using Samba.  Then, wait for the blue screens :-) :-)

> You understand a chance as a curse: AMANDA _has_ the qualities to become
> a real, integrative, superlative backup tool.

According to last COMDEX, it has already become one.  Except for this
minor detail people keep forgetting, which is that Amanda just
*manages* backups, it doesn't *create* them.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Reply via email to