We are using Windows 11 and a Firebird 2.5 database engine.
We have three locations that all use the same version of Firebird. We have an automatic backup routine that runs daily to create a zipped copy of the database. Up until a few months ago the backup routine was working correctly.
Now, the backup routine fails due to a “file in use” error. If I try to use the Windows built in method to zip the file (right-click and select “send to zip file”) we get the error : “The action could not be completed as the file is open in Firebird default instance”.
If I do the exact same thing using Windows 10, there is no such error, has anyone else experienced this problem? And if so, can anyone offer any solution or work-around? We could copy the file – but this is not desirable as the databases can be over 700MB.
1
When a database is in use by the Firebird server process, the file is locked, and you cannot create a copy of it if you’re using SuperServer mode (the most common mode), and if you’re using Classic or SuperClassic mode, then copying the file is a good way to end up with an unusable/inconsistent backup of your database. This inconsistency happens as ongoing transactions will modify the database, while your copy/zip process will read some of those changes, but possibly not all of those changes.
You should use the gbak tool or nbackup tool to backup the database instead of trying to create a file copy. And if you do want to create a file copy, you need to put the database in “backup mode” first to ensure that the file contents is consistent.
There are two ways to put the database in backup mode:
- Execute
ALTER DATABASE BEGIN BACKUPwhen connected to the database, perform the copy, and then executeALTER DATABASE END BACKUP - Lock the database with
nbackup -L <database>(same asBEGIN BACKUPabove), perform the copy, and then unlock the database withnbackup -N <database>(same asEND BACKUPabove); see also nbackup – Locking the database and making the backup yourself.
When the database is in “backup mode”, the database file itself will be stable (it is not modified by ongoing transactions), and instead the modifications are temporarily stored in a “delta” file. After you end the “backup mode” those changes are reintegrated into the normal database file.
A copy of the database created in backup mode, needs to be “fixed up” to be usable, otherwise it will complain about a missing delta file. You can do this with nbackup -F <database>