Subject | Re: FBKs being left open |
---|---|
Author | Steve Harp |
Post date | 2006-04-18T22:28:44Z |
--- In firebird-support@yahoogroups.com, Alexandre Benson Smith
<iblist@...> wrote:
before certain key data changing events. Restores are only done when
the end user does something stupid and screws up their data or when
one of the key data changing events fails.
Backup files are named with an FBK extension and the database files
are FDB. The backup process involves first renaming any existing FBK
file. The Firebird backup is then performed using the
TIBOBackupService component. Lastly, the FBK is stored in a zip file.
Upon restore, any existing FBK files are deleted, then the zip is
restored and, if an FBK exists in the zip file, it is restored using
the TIBORestoreService component.
We've seen occational failures on both backup and restore due to FBK
files being open. The failure occurs when we try to delete or rename
these open files.
Steve
<iblist@...> wrote:
>try to
> Steve Harp wrote:
> > --- In firebird-support@yahoogroups.com, Steve Wiser <steve@> wrote:
> >
> >> Can you put the database in shutdown?
> >>
> >
> > I don't know how to do this. Are you talking about closing the
> > TIBConnection object? What effect would this have on the FBK?
> > Remember, my problem is with the FBK; not the FDB.
> >
> > Steve
> >
> >
> >
> Hi Steve,
>
> Let me ask some questions to understand better your problem.
>
> You do a back-up on a regular time frame (daily, hourly, etc.), so far
> so good.
>
> But you said when you need to restore you get the FBK in use, gbak
> closes the FBK file as soon as it finishs it's job. So here lies your
> problem.
>
> My question is:
> Do you do the restore on a regular time frame too ?
> To restore the database no one should be using the database (of course
> :-) ) this is a regular task that you do ?
> If so, why are you restoring it so frequently ?
>
> Another question:
> Assuming that you do the back-up and as soon as it terminates you
> restore it, there is any chance that the process of the back-up are notThe system does backups whenever the application closes as well as
> finished when you try to delete the old FBK file ?
>
> I do something like this for a back-up routine:
> 1.) create the fbk using gbak (in LocalA)
> 2.) zip it (in LocalA)
> 3.) extract it to another location (localB) to test the ziped file
> 4.) restore the fbk that is on localB to another location to make sure
> the fbk is ok
> 5.) delete the fbk file that is on LocalB
> 6.) copy the zip file to a safe location
> 7.) delete the zip file from LocalA
> 8.) delete the fbk file that is on LocalA
>
> Using this approach you make sure you have a valid zip and fbk file,
> after the test process are finished you remove the garbage (fbk and zip
> file) so no fbk file will be anywhere when you need to restore it
>
> I run this script in a cron job (in some sites hourly, in some sites
> twice a day, in some sites once a day) and had never encoutered and fbk
> file that could not be deleted.
>
> Could you tell us how are you doing your tasks ?
> Did you make the back-up using gbak or using the services API ?
before certain key data changing events. Restores are only done when
the end user does something stupid and screws up their data or when
one of the key data changing events fails.
Backup files are named with an FBK extension and the database files
are FDB. The backup process involves first renaming any existing FBK
file. The Firebird backup is then performed using the
TIBOBackupService component. Lastly, the FBK is stored in a zip file.
Upon restore, any existing FBK files are deleted, then the zip is
restored and, if an FBK exists in the zip file, it is restored using
the TIBORestoreService component.
We've seen occational failures on both backup and restore due to FBK
files being open. The failure occurs when we try to delete or rename
these open files.
Steve