>>> Can anyone tell me why the backup command is taking so long? Have I reached a FB limitation?
>
> Initial backup still running 14hrs later and at same display ...
>
>> If it is the backup which needs that long then it possibly is the
>> garbage collection, which takes place in the source database.
>
>> If you actually will replace the production database with the restored
>> database, then use the -g switch in the backup process to omit garbage
>> collection in the source database.
>
> So does that mean that if I omit garbage collection in the backup process by the command,
>
> gbak -v -t -g -user SYSDBA -password "masterkey" DBNAME.FDB DBNAME.FBK
>
> when I create a new database using
>
> gbak -c -v -p 8192 -user SYSDBA -password "masterkey" DBNAME.FBK DBNAME2.FDB
>
> there will be no garbage transactions in the newly created DBNAME2.FDB database?

Correct. The backup process never stores garbage in the backup file.
It's all about doing garbage collection in the source database you are
attached to with the gbak utility during the backup process.

> Would you advise to stop the current running backup and restart using the -g option?

If you restore your backup and make this one your production database,
then yes, doing a garbage collection in your source database during the
backup doesn't make sense. So in this case, use the -g switch.

ATTENTION: DON'T RESTORE YOUR BACKUP OVER YOUR PRODUCTION DATABASE.
Restore it under a different name, just in case something goes wrong
during the restore!




--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!