Hi Olivier,

>
> 1. The backup processing is a server issue. The client is not concerned by
> the operation, except for starting it, eventually reporting its progress,
> stopping (cancelling it) and reporting its final status when finished.
>

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.

>
> 2. The backup processing is exclusive. There can only be *one* and only
> *one* backup in progress per database.
>

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.

> 3. The backup processing requires a separate processing thread. And
> synchronization of this thread actions with all engine actions that modify
> pages. To be considered modified ("touched") a page does not need to be
> rewritten to disk (cache). So the synchronizations needed will have to occur
> where logical modifications to pages are done. That backup thread only
> exists when a backup is in progress.

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.

>
> 4. The whole process requires to be able to identify unambiguously any page
> at any time, and requires to be able to "know" if some page is or is not
> before or after another one, sequentially speaking in the physical files.
>
> 5. If implementation is feasible, this backup technique works at the
> physical level (page level) and gives you a backup file which can (in the
> non-differential mode of operation) be restored later to give you a complete
> image of the entire database, -- at the time the backup finished -- and not
> at the time the backup started.
>

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.

> Without anything more, this backup has at least the same disadvantage as
> gbak. It copies everything (even the indexes, and some or many pages may
> even be backuped many times during the process if they are "hot" pages) and
> this may be a pain on huge databases.

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

just my 2c

Dalton