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. Restore should (if possible) be done periodically for database hygiene, even on databases that are running ok. It's like doing spring-cleaning even though the house looks clean. You know there are cobwebs lurking in hidden places, mould in the bottom of downstairs wardrobes...

And, when you restore, you either take a copy and store it safely away so that a gbak -r won't end the world if it finds corruption; or you restore the gbak in another location first to verify that there is no corruption and/or fix any that is reported.

One should ALWAYS copy/move the working db to another location before attempting to restore. Not just when corruption is suspected, but ALWAYS.

Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________