Matthew poses the same logic and questions we usually see: let's just
mirror the thing real well and get real fault tolerant.  Then we wont need
any daily/weekly/whatever backups - right?

Unfortunately, this scheme stops working when an unforseen programmer
error, user error, etc. gets propogated to the primary and all copies of
the database in question.  I usually win the argument here on this issue by
citing two examples our revenue systems had with this kind of problem.  One
was very serious and had only been discovered 3 MONTHS after the problem
actually occured.  These examples I use could have cost our company
millions of dollars if we had not had a "backup" - the mirror's were
corrupt, the primaries were corrupt and there was no way to rebuild.  But,
hey, the hardware was just fine.

If you don't mind taking the unforseen hit, then just mirror - it's a
business decision, not a technical one.

We struggle with providing appropriate hardware and resource to backup all
of our growing and very large databases (most these days come in the 100's
of GB to +1TB).  SAN, FC/AL, etc. will help.  The software needs to
catch-up and we need to stop funneling data "through" a server and start
sending data from device to device.  ADSM, Networker, Netbackup,
Alexandria...doesn't matter.  VLDB toasts each one because the paradigm
requires the client/server communication.  Yes, even with backup clients
(Networker), and slave servers (Netbackup).  You still need sufficient
backplane, CPU and I/O bandwidth on the "server" to send data to local
devices at appropriate speeds without impacting the application you are
trying to protect.

ADSM doesn't win the performance war, but it does well enough for us (last
example I gave to this list server was ~6MB/sec/stream for an aggregate
~300GB/hour backup speed on a E10K with ADSM).

We are looking forward to see what the vendors do with SAN.  They can't get
there fast enough for us...

Thanks,

David