On 13-01-2020 16:36, Kjell Rilbe kjell.ri...@marknadsinformation.se [firebird-support] wrote: > Please see my question here: > https://dba.stackexchange.com/questions/257259/is-it-safe-to-risk-multiple-firebird-nbackup-l > > Quoting here, but wish you will reply at the site, if acceptable to you. > > I'm using Firebird 3.0 nbackup to lock + copy + unlock each night. > > If some steps fail or are skipped e.g. due to system restart (updates), > it may happen that the master is not unlocked (-N). Next night, it will > already be in locked state, but the scheduled backup task will lock it > again (-L). > > Is this safe? > > Will the second -L have any effect, or is it a no-op, so a single unlock > (-N) will restore it to normal state? Or do I have to safeguard against > a second lock (-L) if it's already in locked state?
As I also answered on dba.stackexchange.com: Executing nbackup -L when a database is already locked will produce an error (and the executable will return exit code 1 instead of 0): [ PROBLEM ON "begin backup". unsuccessful metadata update -ALTER DATABASE failed -Database is already in the physical backup mode SQLCODE:-607 ] In that case, Firebird (or nbackup) won't change anything in the state of the database. So the locked database will remain locked. Continuing would be fine in theory (as the database is locked), but I don't think it is a good idea to just ignore errors and continue, because it could be a different error than this. So, for proper error checking, you would need to check if the error is "Database is already in the physical backup mode and not some other error". As an aside, you can achieve the same effect with ALTER DATABASE BEGIN BACKUP and ALTER DATABASE END BACKUP[1], which will also work with SuperServer mode (as the nbackup tool needs direct file access, while SuperServer uses an exclusive lock on the file). [1]: https://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-db.html#fblangref25-ddl-db-alter -- Mark Rotteveel
