Ann Harrison wrote:

>Hi Nickolay!
>
> I'm copying this to Architecture because Jim doesn't follow this
>list and I'd be interested to hear what he has to say - well actually,
>he's about six feet from me so I could just ask, but then the rest of
>you wouldn't have the benefit of his advice.
>
>Nickolay originally suggested:
>
>
>
>>>>The idea of new backup engine is that main file is locked for changes
>>>>during backup process and tools may access the file at hardware read
>>>>speed. Changes are placed in separate difference file and then merged
>>>>with main file after backup.
>>>>
>>>>

I think a strategy well worth considering is to implement a "clone
database" operation using
the "create shadow" code, but closes the file as soon as the copy is
complete. As mentioned
earlier, this a page level copy with the engine propagating random
access page updates below
the running high water mark to the shadow. Following the operation, the
clone is an exact
copy of the database file as it existed when the last page was written.
The clone database
can either be copied or just retained.

An interesting observation is that IDE disks are now cheaper per unit
storage than high performance
removable tapes. There are issues of removability, but IDE trays exist
that handle electrical
state changes gracefully, so the only real issue is whether or not a
particular operating system
can be tricked into believing that a fixed disk is, in fact, a removable
(hints are graciously
accepted here).

While Netfrastructure doesn't make any provision for physical backup to
a serial device, it
does have an internal scheduler than can be used to spit out cloned
images on a cron-like
schedule. Whether or not the image files are actually preserved off
line is a separate,
organizational paranoia issue.

In any case, however, in my very own, highly humble opinion, contorting
a database system
that runs 24x7 to run with OS backup tools designed to backup TECO files
is a waste of
talent.

As a side note, I've had enough first and second hand experience with
backup tapes writing
six months worth of unreadable tapes to believe that any device that
isn't implicitly tested
to readability every minute or so can be counted on not to work when the
chips are down.
Long experience at DEC convinced me that tape engineering is not a place
that attracts
smart guys.