> Dump/Restore will not drop into retirement unless there's a free replacement
> for it (I may have missed that part, I don't know -- I didn't see anything
> suggesting it).  Here's why:
> 
> 1.  As a sysadmin, from my own point of view, if I cannot restore a tape
>     dumped from five years ago, I'm gonna be a bit put out.

So, it'll spend it's twilight years restoring tapes. That's not a big deal.
Hmmph. You got a RSX-11 BRU or DSC reader lying around?

> 
> 2.  As a programmer (sort of), I think they're pretty effective.  I can't
>     think of a quicker way to get the data than to parse the filesystem
>     directly.  You also avoid updating the atimes that way, something which
>     is necessary for true image recovery (though you screw the ctime on
>     restoral).
> 
> If there's a later restoral which will work with the old dump(5) format,
> I could move forward to a new restore.  If the new dump scheme can un-
> obtrusively retrieve the data from the filesystem, I could move to a new
> dump.

I think that neither the dump format nor the dump/restore program set itself
is anything close to adequate for the amount of storage out there. I shouldn't
have said "retired" I suppose- but I don't see trying to continually update
it.

There is a growing consensus in a number or areas that tape backup is
completly pointless anyhow by now. Bob Snively has said so several times on
the ANSI and Fibre Channel (t11) committee mail lists- which is why it's only
with great reluctance that FCP-2 accomodates some of the 'special' needs of
tape drives as full FC attached devices (I haven't fully grokked those changes
yet- ISTR Bob saying that buffered mode should get tossed in favor of ordered
tags becuase you can't easily do buffered mode when frames arrive out of
order, or something like that...)

> So far:
> 
> - Alexandria has been eaten by Veritas, which is a fscking NIGHTmare to
>   work with.  It's proprietary, which means there's no way to restore from
>   a tape if you lose the software.  It turns into a catch-026.
> 
> - Legato is proprietary.  See above.

I agree. You also forget NetBackup, which is the Seagate stuff that Veritas
bought (and still is alive && well && in Minnesota...)


> - Amanda does not handle spanning multiple volumes.

Amanda is irretrievably broken, and really counts as a pre-Perl/pre-TCL/TK
backup script despatcher.


> This leaves us with dump/restore and various (possibly interactive) scripts.

Because of brokenness in Amanda && proprietariness in Legato, etc., neither
are appropriate for *BSD unless you, as sysadmin, are willing to use them as
part of a larger environment or like breakage. It is the latter situation
which caused me to move my ftp site to a 384Kbit DSL because of all the Legato
client downloads. Saying that the Legato/propietary solution is 'all bad'
(which you and others within NetBSD have said before) is a bit of 'head in
sand'.

But I agree it's not optimal- which is why I am trying to schedule time to
implement NDMP which, as a public and open standard that has some substantial
support in Veritas, Legato and NetApp proprietary backup programs, might
provide an adult and modern backup toolset that can assist *BSD to work in the
commercial space (and thus be a selling point- I mean, really, when you talk
to most enterprise sites and say, "*BSD? Data managment and backup? Uh, tar,
cpio, dump.....").

> Now, either there's a real trick to writing dump/restore software, or nobody
> knows WTF they are doing.  Until either one of these is disproven, I'm going
> to elect what works.

I wouldn't have you do things any other way. Really. But we may not agree on
what works and what doesn't. I mean, if ANSI labelled tapes work for you,
that's great. Nobody is requiring you to change. Polite interest or
disinterest in somebody offering to try and implement something else, which
you can then try out, seems not inappropriate either.

-matt