Morning Jocob,

> Using FB2.5, I'm doing a simple restore of my database alias MYDB
> Before doing so, I shut it down:
>
> gfix -user sysdba -password masterkey -shut full -force 0 MYDB

This is good! Beware that at version 2 and previous (I've not yet tested
this on 2.5) the -force option acts exactly as per the -attach option.
However, unless you see an error message, the database will indeed be
closed down. (See www.firebirdsql.org/pdfmanual/Firebird-gfix.pdf)

Anyone attempting to connect to the database will be prevented from
doing so and will see the following error:

Statement failed, SQLCODE = -901
database <database name> shutdown

> Here is the restore command:
>
> gbak -user sysdba -password masterkey -r o c:\backups\MYDB1.fbk MYDB

No no no! ;-)

You are asking for trouble here. The manual for gbak explains this in
the section you are quoting (below):

<quote>
Restoring a database is the process by which you take the existing file
and delete prior to replacing it on disc with a backup copy. Gbak does
this when you specify the -r[ecreate_database] o[verwrite] switch or the
-rep[lace_database] switch.
</quote>

> Is the database file MYDB.gdb completely shielded from being accessed by the clients while it is shut down? I.e. during the restore process?

Only if the gfix command worked without error. But surely you would test
a connection after shutting it down, just to be doubly sure?

> I ask because in http://www.firebirdsql.org/pdfmanual/Firebird-gbak.pdf it says:
>
> "In addition, if you have only partially completed the restore of a database, and some users decide to see if they can login, the database may well be corrupted."
>
> Is this possible with FB 2.5 and while the database is shut down???

Not while it is shut down, the very paragraph you quote has the details
"you might corrupt the database especially if the database is in use and
has not been shut down using gfix."

The (implied) advice is that you should always restore the dump file to
a brand new database file. That way, if anyone does try and attach to
the (original) database, and it hasn't been shut with gfix, they won't
corrupt the recovering database.

You should, as advised in the manual, never ever restore a database over
the original in the manner you indicate above. The first thing a restore
does is clear the contents of the file(s) being restored to, if they
exist. This means that your database will be "empty" just after the
start of the restore.

In the event of a problem with the backup file, you now are in a
situation where you have no original database and no workable backup.
Not a good position to be in!

So, always restore to a copy database and test that it is fine before
allowing the users back in - either by editing the aliases.conf file to
point at the new database, or, by moving the (closed) original database
away somewhere, closing the copy, and moving it to the original location
and filename(s) - no editing of aliases.conf is required.

HTH

Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767