At 11:49 AM 25/10/2005 +0000, you wrote:

>I'm doing a daily backup of a 10GB firebird database (classic server
>v1.5) using a cron job on the server hosting the database. Using FC4
>on a twin 3.6 GHz Xeon machine.
>
>If I use:
>
>/opt/firebird/bin/gbak -b /path/to/database.gdb restore.gbk
>
>the backup takes about 30 minues.
>
>However if I use:
>
>/opt/firebird/bin/gbak -b localhost:/path/to/database.gdb restore.gbk
>
>the backup takes 7 hours.
>
>/etc/hosts:
>
>127.0.0.1 localhost
>
>ifconfig shows:lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:4158543 errors:0 dropped:0
>overruns:0 frame:0
> TX packets:4158543 errors:0 dropped:0
>overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:700653166 (668.1 MiB) TX
>bytes:700653166 (668.1 MiB)
>
>
>I'm assuming that the only 'safe' wasy to do this is via the
>localhost: loop, but I'm baffled as to the time difference and I would
> find any advice to speed the backup up helful.

In the fast version, you are making gbak connect directly to the database
file, i.e. not going via an xinetd process. In the slow one, you're kind
of doing the same thing, but by a contorted route.

Try this syntax instead, i.e. have gbak start the service manager and
perform the database read via an xinetd process:

/opt/firebird/bin/gbak -b -se localhost:service_mgr /path/to/database.gdb
/path/to/restore.gbk

It's still likely to be a bit slower than the direct connection (the first
way), though. If you're using Classic, there's actually nothing wrong with
letting a cron job use a direct connection for running a backup....

./heLen