Sean,

I am sure that others know more about the internals of
GBAK than I do but, one of the things that I believe
could greatly increase the performance of a restore
would be the ability to create indexes in parallel.

Today, index creation on a restore takes a long time
if you have many and the database is large. Part of
the reason why is that if you have multiple indexes
on a table gbak does multiple full table scans ( one
per index per table ) to create the index. If gbak
restore could be taught to scan the table once and
build all indexes for ( a table ) in parallel the time
to restore would come down.

Also, there are likely performance improvements possible
in the remote or loopback protocol layer. As seen by
Greg Deatz's post recently, his large database took
~6 hrs to restore on a big Sun machine running 6.0
SuperServer and ~3 hrs to restore on a smaller Linux
system running 6.0 Classic. Classic has 'true' local
access where as SuperServer ( non-Windows ) goes though
local loopback to simulate a local connection.

My hope is that some day ( and I don't think we're all
that far away from it ) an InterBase database will be
self maintaining and stable enough to be able to for-go
the restore process entirely. Of course a backup will
_always_ be a necessary recovery strategy in a production
environment.

Markus