Subject Re: [IB-Architect] Full and Differential Backup
Author Olivier Mascia
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
| servers to have any sort of drive connection to the rest of the world, in
| direction).
| Using the gbak as a client would allow a backup to occur over the net
| 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
| also on NT. Our backup process went for 52 hours (not including the
| In order to minimize the time lost while we came up with better solutions,
| had multiple backups occuring, with time spacing between them. (at any
| time, we would have 8 backups going on the database.) We did this to try
| 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
| does alot more than copy the data. It creates the script (very loose term
| 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
| possible with the only problem being, that you need to shut down the
| 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
| working once you need it.
| The difference with what I am talking about and your process is that you
| have multiple shadows being created. This means that you can have
| 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

| just my 2c

Welcomed, Dalton !

Olivier Mascia T.I.P. Group SA
Director, Chief Software Architect +32 65 401111