Здравствуйте!

На одном из серверов при создании бэкапа, с помощью nbackup -B 0 ..., произошла ошибка и больше пока не воспроизводится.

Команда:


Ошибка:



В каких случаях может происходить такая ошибка?
Судя по ошибке, она произошла в конце бэкапа во время выполнения команды END BACKUP, т.е. BEGIN BACKUP был выполнен успешно. А раз так, то как БД оказалась в "not in the physical backup mode"?

В логе firebird.log ничего интересного нет (за интервал времени выполнения этого бэкапа), кроме:
1)
Sat Jan 8 07:00:16 2022
Fatal lock manager error: invalid lock id (309760), errno: 0
2)
Sat Jan 8 11:55:05 2022
Shutting down the server with 1 active connection(s) to 1 database(s), 0 active service(s)

1-е сообщение не относится ко времени бэкапа - оно на 3 часа раньше его старта. Или время в логе пишется в UTC?
2-е сообщение, на сколько я понимаю, штатное для nbackup, которое происходит во время его дисконнекта от БД, из-за того что он работает в embedded режиме? Или тут ошибаюсь?

БД на "побитость" проверял (gfix -validate -full) - ошибок нет.
Используется Firebird 4.0.0.2496 Classic x64.

hvladКто-то другой уже выполнил END BACKUP
Это совершенно точно исключено. С БД в это время админских задач больше никто не выполнял.

Сейчас проверил, в rdb$backup_history есть только 1 запись с временем окончания (RDB$TIMESTAMP) как раз в 11:55:05.

Есть ли способ как-то обеспечить монопольный доступ к БД для nbackup? И почему он сам этого не делает?
Получается, что в процессе его работы кто-то может легко сделать END BACKUP, и nbackup остановится с такой ошибкой? И после этого не получится найти никаких концов (ни в логе, ни в rdb$backup_history) - кто это сделал и откуда?

В целом понятно, спасибо.

>>Монопольный доступ обеспечивается шатдауном, например с gfix.
Но ведь после такого шатдауна sysdba все равно сможет соединиться с этой БД и выполнить END BACKUP, пусть даже и по ошибке. Т.е получается, что внешними средствами не обеспечить монопольный доступ.

Мне кажется, такой доступ должен обеспечиваться внутренними средствами и nbackup-у он нужен, т.к. раз уж он смог сделать BEGIN BACKUP, то только он в этом же сеансе бэкапа и должен мочь сделать END BACKUP.
И только если что-то пошло не так (по сути это только прибитие процесса, т.к. обработанные исключения должны снимать блокировку - сейчас это не так, но по логике вещей должно быть так), то только тогда sysdba может явной отдельной командой снять такую блокировку (с записью в лог).

>>nbackup этого не делает, т.к. это совершенно не нужно.
nbackup рассчитан на одновременный параллельный бэкап? Если нет, то кто-то должен обеспечивать блокировку. Сейчас это предлагается делать регламентными средствами (на уровне договоренностей), а нужно иметь технические.

kdvречь про single-user shutdown mode
Ага, увидел новые опции, спасибо! Хорошо, что nbackup однопоточный, и не создаст несколько соединений :)
Хотя, это может измениться, да и зачем разрабатывали целую механику дельта-файлов..., если нужно делать целый shutdown.

kdvвообще-то, если из ДВУХ isql дать alter database begin backup, то второй получит.
то же самое должно быть и при параллельном запуске двух нбэкапов
Да, это так и есть и это правильно. Но раз ни nbackup, ни BEGIN BACKUP не должны работать одновременно в разных сеансах, то почему бы не обеспечивать монопольный доступ к блокированию БД для одной конкретной операции BEGIN BACKUP в рамках одной команды бэкапа в nbackup?

kdvp.s. самое смешное, что второй isql, увидев ошибку, может дать alter database end backup, ибо они оба равноправные sysdba, а первый isql при такой же команде теперь обломится.
Однако, они оба SYSDBA, и их конкуренция - не проблема FB.
Очень "удобная гибкость" ... для создания граблей. А для решения простых административных задач требуется прямолинейная однозначность - если процесс начался, то на пол пути его у тебя никто не уведет, хоть по ошибке, хоть по злому умыслу.
И самое печальное, обо всех этих вклиниваниях не будет никакого упоминания в логах...

kdvПервый isql мог вообще сделать дисконнект, и потом опять коннект и alter ...
Если рассматривать BEGIN BACKUP и END BACKUP как инструмент решающий 3 задачи за один присест - для бэкапа nbackup, для блокировки nbackup -L и для непосредственных команд sql BEGIN BACKUP, то да, такое компромиссное решение выглядит логичным.
Но если рассматривать конкретную операцию бэкапа с nbackup, то такая гибкость уже не выглядит логичным.

hvladНевозможно на 100% защититься от ошибок админа. Ни в какой системе.
Но залогировать и выдать warning можно.
Сценарий когда nbackup начал бэкап, и вдруг по среди процесса в другом сеансе сделали END BACKUP - не может считаться нормальным. Это, как минимум, нужно залогировать, а как максимум, другому сеансу нужно было дать отлуп.
Остальные варианты с shutdown и прочее произрастают из невозможности достичь исходной цели штатными средствами. Я только за параллельную работу с пользователями, но не за одновременную работу над одной задачей, в данном случае процессом бэкапа.

hvladВы сейчас придумываете какие-то правила под себя, но хотите чтобы они действовали для всех.
Еще раз, речь только про сценарий когда nbackup начал бэкап, и вдруг по среди процесса в другом сеансе сделали END BACKUP. Я сильно удивлюсь если такой сценарий ожидаемый для всех.

hvladКакую блокировку ? Может стоит почитать - как работает nbackup?
Фраза вырвана из контекста.
Там не описывалось текущее поведение nbackup. Там описывался гипотетический вариант блокировки которая могла бы быть:
rashid.abzalovМне кажется, такой доступ должен обеспечиваться внутренними средствами и nbackup-у он нужен, т.к. раз уж он смог сделать BEGIN BACKUP, то только он в этом же сеансе бэкапа и должен мочь сделать END BACKUP.
И только если что-то пошло не так (по сути это только прибитие процесса, т.к. обработанные исключения должны снимать блокировку - сейчас это не так, но по логике вещей должно быть так), то только тогда sysdba может явной отдельной командой снять такую блокировку (с записью в лог).

hvladPS я правильно понимаю, что про это речь уже не идёт?
Нет, идет. Там никто не мог выполнить sql команды END BACKUP, а бэкап с nbackup-ом это был регламентный процесс, выполнялся планировщиком заданий. Но подтвердить это я никак не могу (в тексте ошибки нет никаких подробностей кто и когда опередил nbackup, и в логах ничего нет, и в rdb$backup_history тоже ничего нет), поэтому, чтобы не наступать на эти же грабли и ведется этот разговор. А сейчас пока придется пробовать это воспроизводить или наблюдать пока не воспроизведется снова.

PS. База ~200 Гб, бэкапилась на внешний USB диск, обычно процесс занимается от 2,5 до 3,5 часов, но на этот раз ошибка произошла примерно через час после старта. По крайней мере, судя по коду nbackup, "commit history insert" произошел успешно и завершился в это время, но commit был последним действием перед блоком catch, т.е. получается, что internal_unlock_database вызывался не из catch блока.