Thank you for your advice.

Restore NEVER restores garbage - because it never backs it up!!

makes sense ...

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

Up to you whether you restart or let it run now...but running a backup with the -g switch creates a backup file *without* attempting to look for garbage to clean up in the database it is attached to. The point Thomas makes is that, if you plan to restore immediately from that backup, it is pointless to perform garbage collection on it!

I have decided to stop the current backup and restart with the -g flag ie

gbak -v -t -g -user SYSDBA -password "masterkey" CALLTRAK.FDB CALLTRAK.FBK

I will adopt the above command as standard for my procedures, considering I immediatley do restores.

coincidentally, the gbak process is continuing as expected ie the command is now displaying

gbak: 20000 records written
etc
etc

however significantly slower, than without the -g option. Great to see the records scrolling.

>There are no users on the system currently.

What Thomas means is that, if you still have users logged in and having long-running transactions, then sweep will have little or no opportunity to clear garbage. When you are running apps that are tying up more than 22 million transactions over three weeks, it is better to disable auto sweep and deliberately do a manual sweep every day when users are all off-line.

Even better would be to fix the apps!!

I will disable the auto sweep and yes you are right, I should fix the app, however didn't prioritise it considering the backup/restore was quite simple and straight forward (until this instance).

FYI I will let you know when complete process of backup (using the -g option) and restore completes.

Thanks again

Theodore

[Non-text portions of this message have been removed]