Keep in mind that the original goal of the backup/restore exercise
was to upgrade from Interbase to Firebird at about 80 remote
locations. We use the following steps to accomplish this (some paths
and file names have been changed to protect the innocent):

1) Shutdown all running applications that could be accessing the
database.

2) Make a phyical copy of the database file in case something
goes wrong. (ex: copy c:\database.gdb c:\backup\database.gdb)

3) Use IBConsole (under Interbase 6.0) to make a backup of the
database to a .gbk file. The options used are the defaults:
format=transportable, metadata only=false, garbage collection=true,
transactions in limbo=process, checksums=process, convert to
tables=false, verbose output=to screen.

4) Uninstall Interbase and Interclient.

5) Reboot

6) Install Firebird Super Server using the default options (version
1.5.2.4731)

7) Install JayBird JDBC driver

8) Restore the database from the command line using GBAK (Firebird
version) with the following syntax:

cd c:\Program Files\Firebird\Firebird_1_5\bin

gbak –c –user SYSDBA –pas password c:\backup\database.gbk
localhost:/database.gdb

9) Add users and change application specific JDBC connection strings
to point to the JayBird driver and Firebird database server.

I should note that we have had problems on both Windows 2000 and
Windows XP. I can guarantee that the original database was not
manually shutdown before the backup. As for the owner of the tables
being SYSDBA, I have seen that reported out here before. One thing
that I have just noticed is that we don't end up adding the original
owner of the database tables to the Firebird security file until
AFTER the restore has been processed. Is it possible that the
restore is failing because the owner of the tables done during the
backup is not on the system when the restore takes place? One final
note, the process listed above has worked on 10 other machines
without any issues.

Thanks,
Matt

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 08:37 PM 30/08/2005 +0000, you wrote:
> >I have a client who performed a backup and restore using the GBAK
> >routine. When we try to connect to the resulting database we get
> >the "database [database name] shutdown" error. Does anyone know

what

> >could be causing this?
>
> The database that was backed up was shut down.
>
> >Here are some more details.
> >
> >1) I can "fix" the issue by bringing the database back online

using

> >the GFIX -online option. However, this just lets users other than
> >SYSDBA connect. There are data integrity issues (see below).
> >
> >2) All of the database tables are completely empty. None of the

data

> >was restored.
>
> If the restore operation completed without throwing any

exceptions, then it

> looks likely the backup was done as a "metadata only" one.
>
>
> >3) The owner of each table is SYSDBA instead of the real owner
> >assigned in the original database.
>
> That doesn't make sense.
>
>
> >4) No one ever manually "shut the database down". GBAK must have
> >done it during the restore (or else never got to the point where

it

> >brings it online in the first place).
>
> It depends. Something looks fishy about the backup. When a gbak

is being

> restored on a Fb 1.5 Superserver, the gbak program has an

exclusive lock on

> the file until it completes the task and logs out.
>
>
> >5) We are upgrading from Interbase 6.0 to Firebird 1.5. The backup
> >was made using GBAK against the Interbase database.
>
> What server was running when the IB 6 database was backed up?
>
> Which gbak was used?
>
> On each side, is gbak being called from the command line or

through an

> application?
>
> Exactly what switches are being used on each side?
>
> Did the switches used include -v and -y to create logs?
>
> >The restore was made using GBAK from version 1.5 of Firebird.
>
> Superserver or Classic? Which sub-release? Which OS platform?
>
>
> >It appears that either the backup or restore failed to complete
> >(probably the restore). Any ideas as to why this happens?
>
> Not from the info thus far provided. Both IB and Firebird (can)

do hot

> backups, i.e. the database doesn't have to be in a shutdown state

for the

> backup. The backup will be done in a single snapshot transaction

that

> reflects the state of the database when the process starts.
>
> > It actually happened on two different databases/machines today

so we

> > are really getting spooked.
>
> Does this statement tell us that you are running IB6 and Fb 1.5 on

the same

> machine and are arbitrarily connecting to the same database

through one or

> the other server?
>
> What about the client library?
>
> ./heLen