Dalton Calford wrote,

| Hi Olivier,
|
| This does not help when you want the backup file created on a machine not
| accessible to the server (alot of multi-layer firewalls will not allow
data
| servers to have any sort of drive connection to the rest of the world, in
either
| direction).
| Using the gbak as a client would allow a backup to occur over the net
using
| standard IB protocals.

I agree with you. That's why I announced the "color" first.
Now, it may be a disadvantage or not. Depends on the needs of everybody.
Byt the way, nothing, by design, would prevent to flow the output of my
backup proposal through the network connection between the client and the
server. Or to a tape drive... My original idea is that it *may* be quicker
to do it locally, then why not retrieve a copy of the backup file.

| When we were questioning the design of the database over a year ago, we
were
| also on NT. Our backup process went for 52 hours (not including the
restore).
| In order to minimize the time lost while we came up with better solutions,
we
| had multiple backups occuring, with time spacing between them. (at any
one
| time, we would have 8 backups going on the database.) We did this to try
to
| keep the window of loss to a minimum.

Point taken. The goal of my proposal is to get a quicker full backup
process, so reduce, if possible considerably, that window of 52 hours.
Having multiple backups running at the same time could become less needed.
But again, this is a new limitation of my proposal that gbak didn't have.

| This sounds like a physical backup. This sounds very similar to what the
| shadowing routines do. Maybe they can be made to do this, or modify the
| shadowing routines to run as a 'physical' vs logical backup. The gbak
process
| does alot more than copy the data. It creates the script (very loose term
here)
| to create a totally new database. This removes any cruft that may have
built up
| in the origional.

...

| If you see my earlier posting, you can do this with shadows. This is
already
| possible with the only problem being, that you need to shut down the
database
| and perform a OS command then restart the database. This means your
database is
| off line for about a minute.
|
| If you want to, once the new database is created with this process, you
can zip
| it and archieve it. It is a fully operational database so it is easy to
get
| working once you need it.
|
| The difference with what I am talking about and your process is that you
can
| have multiple shadows being created. This means that you can have
multiple
| backups working at the same time.


Indeed, that's true shadowing has details in common. But there are also
differences. The backup does not require the 1 minute shutdown. That may be
the whole difference for some needs. I would be happy the discuss possible
shadowing extensions to achieve the same goals. If at all feasible, I would
vote for something that build on existing engine technology.

| Gbak does not copy the indexes or any other dynamic data. Gbak
recreates the indexes upon restore.

Yes, knew that. The proposed behaviour is closer to shadows than to gbak as
you very correctly stated. Maybe, if indexes are always stored on separate
pages from pages where data lives, my scheme could be slightly updated to
skip over index pages. But I have no idea of the real internals of ODS for
now.

| just my 2c

Welcomed, Dalton !

---------------------------------------------------------------------
Olivier Mascia T.I.P. Group SA
om@... www.tipgroup.com
Director, Chief Software Architect +32 65 401111