Commented by: @hvlad

Looks like by some reason database state was changed from "stalled" to "merge" while backup was in progress.
It could happen if someone "unlock"ed database or run "ALTER DATABASE END BACKUP" statement.

I see no harm for database here, but backup process is aborted.

Commented by: Lucas Schatz (arvanus)

Hello Vlad, thanks for your reply!
I`m almost 100% sure this wasn`t manually unlocked, but what I`d seen is this error too (in another day, not related in the same error log):

 lost connection \[ PROBLEM ON "end backup"\. unsuccessful metadata update \-ALTER DATABASE failed \-deadlock \-update conflicts with concurrent update \-concurrent transaction number is 434463421 SQLCODE:\-607 \] 

So I think that there is a small window of opportunity were a previous running nbackup is overlapped by a new one, is it even possible?

Note: I`m using a crontab script that runs nbackup and gzips it every minute, and I`m not verifying if nbackup is already running because I trusted it`s internal control.... should I change it?

Thanks!

Commented by: Sean Leyne (seanleyne)

Lucas,

I believe that you should change your approach. I would:

- create 1 job that endlessly loops to continuously create backups and then move the backup file to a "to be archived" folder. {This can result in backups having interval > 1 minute, but will ensure that you are not "stepping over" any existing nbackup jobs.
- create another job which would archive any files in the "to be archived" folder, then move the archive file to an "archived" folder, then delete the source backup file.