Under Review
over 4 years ago

Remove exclusive access requirement from Timeslips 2017 backup utility

Problems with the Timeslips 2017 scheduled backup utility led me to research the Firebird command line utility, GBAK.EXE, that is included with the Timeslips 2017 installation. It appears that this utility can run successfully without exclusive access to the database. According to the GBAK documentation:

"Gbak creates a consistent backup of the database by starting a transaction that spans the backup period. When the backup is complete, the transaction is ended and this means that the backup process can be run while users are working in the database. However, any transactions started after the backup process begins will not have any of the changed data written to the backup file. The backup will represent a copy of the entire database at the moment the backup began."

Source: https://firebirdsql.org/manual/gbak-backup.html

Since it is often difficult to obtain exclusive access to the Timeslips database at a site with many active users, removing this constraint from the backup process would result in more frequent backups and improve chances of successful recovery from database problems.

I have successfully tested using GBAK in a Windows batch file to run a scheduled backup of a Timeslips 2017 database. The .bat file is excuted by the Windows server task scheduler. (Before running GBAK, the FIREBIRD.MSG file must be copied to the parent folder of the server Timeslips 2017 folder.) Here is a sample .bat file:

:: Timeslips Rotating 7 Day Firebird database backup procedure
::
del D:\tsBackup\%date:~0,3%FBLog.txt
gbak -v -t -user SYSDBA -password "masterkey" -y D:\TSBackup\%date:~0,3%FBLog.txt "C:\ProgramData\Sage\Timeslips\Databases\amicusc.fdb" D:\TSBackup\%date:~0,3%.tbu

The Firebird documentation available through the URL above explains the function of the GBAK option switches. The automatic naming of the daily backup and log files is accomplished through Windows batch file features.

  • hello,

    You are correct in that GBAK can be called and ran on its own with out the restriction. That does not mean we recommend it be ran with our implementation of Timeslips and the database.

    there is more to the Database than just a container of Db files, when you are dealing with a database and open connections to that database, you have locked files or possibilities for data corruption or missing data in a network environment depending on what active connections re open and present at the time you would want to call gbak.

    It is for this reason why we have Exclusive mode implemented.

    it sounds like despite that you currently have a work around to get what you need manually calling Gbak with the command line parameters via batch file however we do not support data corruption in databases that have been "backed" up via this method.

    An alternative method via batch file would be just to copy the *.FDB file from one location to another if you are looking for something with more simplicity but again there are no guarantees that all data is present, accurate and accounted for at the time the backups are made via methods outside of exclusive mode>backup DB