"Helen Borrie" <helebor@...> wrote in message
news:5.1.0.14.0.20020127134201.04444c60@......

> At 09:03 PM 26-01-02 -0500, you wrote:
> >Hi:
> >
> >> If you don't have a copy of the gdb file, then you have just learnt the

hard way why it is not a good idea to restore backups over the top of your
existing gdb file.

> >
> > So where do you restore backups? The whole purpose of the backup is
> >to restore the database.
>
> No, the whole purpose of the backup is three main things:
>
> 1. to back up the database and provide a fallback strategy in case

subsequent events should corrupt the database.

> 2. to clean up and release space on pages from which rows have been

deleted

> 3. to identify and report anomalies that might have occurred in the event

of an abnormal termination of the server or clients.

>
> gbak does 2 and 3 in the course of doing 1.
>
>
> > Or do you mean restoring when the db is corrupted? That is a pain
> >since the user can do it from within the app.
>
> Do what? Are you saying that you develop systems where all users are

logged in as sysdba and anyone can restore a gbak by hitting a button?

>
> > So what should one do in
> >such a case, copy the db to another location before restoring over the
> >working db?
>
> Always.
>
> A restore is not usually the outcome of a decision to run a backup.

Our policy that a spare machine is cheap and a restore after backup at least
of a 1 in n times is crucial to ensure that the backup has integrity. We
don't actually do anything with the restore, we just need to know it can.
This used to be on an everyday basis, now is it more like once a week.

We have found that on dual processor machines without IBaffinity, that
restores fail, but succeed if restarted (IB 5.6).

Cheers,