Hi, Helen. Firebird-2.0.3-SS, gbak runs on the same mashine where
fbserver runs. I'm pretty sorry, but it seems to be my mistake: there
was wrong permission for directory where 2-th, 3-th,... multiple files
should be created. Upgraded fbserver runs as user 'firebird', but
previous was configured as 'root' user. Setting correct permission
solves the problem.
Sorry for my English. Thank you.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 10:25 PM 3/02/2008, you wrote:
> >After the upgrading from v1.5 to v2.0.3 gbak doesn't work like
previous:
> >
> >slackware-linux:#gbak -C -P 4098 backupfile.bk dbfile.fdb 200000
> >../somedir/dbfile.fb1 200000 ../somedir/dbfile.fb2
> >
> >gbak from firebird-2.0.3 kit doesn't split database, but creates one
> >full size dbfile.fdb (3Gb). May be there is some changes in gbak
> >syntax? Thank you.
>
> Are you using Classic or Superserver? With Superserver, of course
you can't do a "local" backup. However, it seems there might be an
undocumented effect (or perhaps an unintended effect) with Classic,
arising from the security changes, whereby you cannot perform a
restore using libfembed.so as the direct-connect client any more. You
need to use either *that* library as a remote client connecting
through the TCP/IP local loopback server *or libfbclient.so* as a
TCP/IP client, in both cases invoking gbak -c with the full
-se[rvice_mgr] switch and argument.
>
> Also, according to a recently reported experience, you might still
have a problem with the *correct* syntax for a multi-file restore,
which has the effect you report, unless you preface the primary file
name with the server name, i.e., localhost or server_name, according
with what you specified in the argument for the -se switch.
>
> Could you try that, please? One way or another, this has to be
dealt with, either as an ackowledged bug (and fixed) or as an issue
that has to be documented. Your report back here would be much
appreciated.
>
> ./heLen
>