nbackup unlock causes internal Firebird consistency check (next transaction older than oldest active transaction) [CORE6059]

[firebird-automations]

Submitted by: Omacht András (aomacht)

Hi!

Our backup script uses nbackup.
1. It locks the database with -L
2. Copy it (with scp) to an another box
3. Unlock with -N

We have running and newly starting transactions while the backup process running.

Backup log:
2019-04-30 23:19:56 /u1/firebird/database.fdb LOCKED [ OK ]
2019-04-30 23:20:00 /u1/firebird/database.fdb SCP[ OK ]
2019-04-30 23:20:00 /u1/firebird/database.fdb UnLOCKED [ OK ]

Firebird log (same time as unlock):
server<--->Tue Apr 30 23:20:00 2019
<------>Database: /u1/firebird/database.fdb
<------>internal Firebird consistency check (next transaction older than oldest active transaction (266), file: cch.cpp line: 6523)

server<--->Tue Apr 30 23:22:01 2019 (2 mins later!)
<------>Database: /u1/firebird/database.fdb
<------>deadlock

We have 3 other databases following with the same error (internal Firebird consistency check (next transaction older than oldest active transaction (266), file: cch.cpp line: 6523)).
But only 2 of 4 have deadlock entry.

[firebird-automations]

Commented by: @hvlad

Few questions:

What architecture is used (SS\CS\SC) ?
Does "3 other databases" served by the same Firebird host\instance ?
How long you using this way of backup ?
How often it happens ?
How to reproduce it ?

[firebird-automations]

Commented by: Omacht András (aomacht)

Hi Vlad!
Classic architecture.
All databases served by the same instance (we have other instances too, but this dbs have the same).
We've been using nbackup at least two years. (Switched from gbak.)
It happens first time.
We try to reproduce it, if it succeeds, I describe the way.

[omachtandras]

We cannot reproduce the issue since then, so Vlad, please close it. Thanks!