Раньше я успешно делал бекапы с помощью gbak, но, поскольку их дольше восстанавливать, решил попробовать nbackup,
как мне тут советовали. И вот такая неприятность:

Firebird 2.5.2, Windows Server 2003, архитектура Классик.

Бекап делается так: запускается файл *.vbs (windows scripting host),
который запускает батник, содержащий команду:

nbackup -B 0 ..\DatabaseFileName BackupFileName

Также он архивирует полученный бекап и пишет в логи всё, что может, включая stderr всех команд.
Всё это настроено работать по расписанию два раза в день. Как правило работает, но уже два раза повисло
за те 10-15 дней, когда я этот скрипт написал.

Он запустился в 14.30. Сам бекап идёт в норме 5 минут.
В 14.44 ко мне обратились пользователи, что у них "3-5 минут" система висит.

Залез на сервер. В диспетчере задач видно, что ничего не происходит: процессор не занят,
чтения - записи процессом nbackup и fb_inet_server не происходит. Подключиться к базе нельзя.
Другая база на том же экземпляре сервера firebird работает нормально.

Файл дельты, о котором говорится в мануале nbackup, отсутствует.

Остановил сервер, убив все процессы fb_client_server - сначала клиентские, потом серверный, потом ещё раз клиентские - я всегда так делаю, если что-то идёт не так. Давайте не будем сейчас обсуждать правильность этого.
nbackup я не убивал, он закончился сам с кодом 1, записав в лог следующее:



После этого скрипт vbs продолжил выполнение и создал архив из того "огрызка", который успел породить nbackup -B.

Параллельно с этим или после этого (неважно) я запустил сервер firebird заново и база продолжает работать без всяких проблем.

Как выяснилось потом, nbackup успел создать копию до того, как ко мне обратились пользователи.
99%, что эта копия - полная и хорошая. Во всяком случае, я поднял её из бекапа с помощью nbackup -R под новым именем, после чего она успешно прошла курс backup/restore с помощью gbak. Затем я к ней подконнектился и нашёл записи, созданные в 14.30, т.е., за миг до начала бекапа.

С тех пор, как я создал этот скрипт и задание, это уже второй такой случай. Расписание достаточно
просторное, наложение двух последовательных вызовов nbackup исключено. В логах системы ничего нет на это время.

Кто-нибудь сталкивался с чем-то подобным?

На всякий случай - база, с которой это случилось, регулярно проходит цикл backup-restore с помощью gbak, последний раз это с ней случилось 23-го, а сегодня 25-е. Хотя эту практику я ввёл довольно недавно, до этого база несколько месяцев работала без всяких проблем.

Заметил ключ -T. Триггеры на коннект/дисконнект у меня есть. Отключил, посмотрим. Правда, эти триггеры у меня уже сто лет не менялись и никто вроде не жаловался на зависания клиента.

Ухты, а тут ещё лог есть:

Gallemar, одна база 2.5 гиг, вторая 14. Ну я так уже и понял по ответу hvlad-а что альтернативы gbak-у пока что, по сути, нет. Не считая репликаций и пр. Всем спасибо, батники от gbak только недавно переложил "в долгий ящик" - недолго и вернуть :)

hvladbuddenНу я так уже и понял по ответу hvlad-а что альтернативы gbak-у пока что, по сути, нет.Офигительно. Я так вообще перестану сюда что-либо писать.
ладно, ладно. Добавлю энлеперское "для меня" ;)