Subject | Re: gbak going slow |
---|---|
Author | stevemilner_2000 |
Post date | 2005-10-25T12:47:15Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:
Using the -se localhost:service_mgr works a treat.
I have a couple of questions.
Why is it safe letting a cron job use a direct connection. It is
possible, though unlikely, that the database may be in use at this
time, and since gbak does garbage collection, isn't there a danger
that direct file and networked write access together may corrupt the
database?
Since I'm using Classic I though I was using xinetd for all database
connections (certainly external access can be disabled by swiching the
firebird xinetd service off). Is it the case that by default gbak does
not use xinetd in my earlier example, and does the -se
localhost:service_mgr force xinetd usage?
If you are UK based I'll buy you a drink nect time I'm in your area.
Steve
wrote:
> /opt/firebird/bin/gbak -b -se localhost:service_mgr/path/to/database.gdb
> /path/to/restore.gbkfirst
>
> It's still likely to be a bit slower than the direct connection (the
> way), though. If you're using Classic, there's actually nothingwrong with
> letting a cron job use a direct connection for running a backup...../heLen, please, let me come and worship at your feet.
>
> ./heLen
>
Using the -se localhost:service_mgr works a treat.
I have a couple of questions.
Why is it safe letting a cron job use a direct connection. It is
possible, though unlikely, that the database may be in use at this
time, and since gbak does garbage collection, isn't there a danger
that direct file and networked write access together may corrupt the
database?
Since I'm using Classic I though I was using xinetd for all database
connections (certainly external access can be disabled by swiching the
firebird xinetd service off). Is it the case that by default gbak does
not use xinetd in my earlier example, and does the -se
localhost:service_mgr force xinetd usage?
If you are UK based I'll buy you a drink nect time I'm in your area.
Steve