Имеется сервер Firebird 2.5.9 classic под Windows.
БД размером 60 Гб. Ночью - полностью свободна от пользователей. В это время делается бэкап, который потом копируется на несколько хранилищ по сети. Из-за того, что в течение дня идет довольно большое количество Insert|Update, счетчики транзакций довольно быстро увеличиваются. Читал, что при переполнении счетчика количества транзакций может случиться беда, поэтому я сбрасываю счетчики - после бэкапа еще ежедневно подменяю рабочую базу восстановленной из только что сделанного бэкапа. Таким образом еще и "чищу мусор". Разумеется восстановление идет не на файл рабочей БД, а в сторонку и только если все прошло хорошо, то подменяется файл .fdb. Подобные действия уже обсуждались на этом форуме, некоторые меня ругали, но если я буду подменять БД не раз в день, а раз в неделю/месяц, то от этого особенно ничего не изменится. Хотелось бы чтобы все действия шли в автоматическом режиме.
Так же имеется другой сервер тоже Firebird 2.5.9 classic под Windows, использующийся в качестве горячего бекапа сервера БД. Утром он берет ночной ежедневный бэкап и разворачивает у себя копию вчерашней БД. Если с основным сервером все совсем плохо (железо погибло, БД не лечится и т.п.) - то все пользователи начинают работать на вчерашней БД на резервном сервере - это лучше чем ничего, но все-равно очень плохо с точки зрения потери данных за рабочий день с утра до момента поломки.
Задача - иметь на резервном сервере как можно более свежую копию БД.
Кроме репликации HQBird или другими инструментами можно ли это сделать с помощью стандартного средства Firebird 2.5 - nbackup? Например, создавая снимки БД каждые 10-15 минут. Полноценного зеркала БД при этом конечно не получится, но потеря данных за 15 минут лучше, чем потеря данных за 8 часов.

С nbackup я до этого еще ни разу не работал, поэтому провел несколько экспериментов на резервном сервере, пытаясь обыграть все возможные ситуации и понять, можно ли каким-то образом если "что-то пойдет не так", поломать рабочую БД.
Ежедневный бэкап БД с помощью gbak я не трогаю - он в любом случае останется. Кстати, он выполняется около 15 минут.
Предполагаю работать так - делать дельты одного уровня (допустим 0-го) с помощью nbackup на рабочем сервере, затем копировать их на резервный и сразу же заливать на копию БД. Если прошло с ошибкой, то повторять что? Заново копировать ту же дельту и заливать? Ведь новая дельта того же уровня уже не зальется в копию БД, поскольку будет нарушена цепочка версий. Исходя из этого получается, что необходимо делать дельты нескольких уровней. Например: 0 - раз в 2 часа, 1 - раз в час, 2 - раз в 15 минут. Тогда если с файлом дельты 2 уровня была проблема, то можно надеяться, что дельта уровня выше зальется без ошибок.
Нагрузку на БД эмулировал периодическими INSERT|UPDATE по паре табличек в БД, как оно пойдет на рабочей БД - пока не знаю.
Далее я через 1 час сделал копию БД 0 уровня, затем через каждые 15 минут - 1 уровня. Заметил, что время создания копий 1 уровня меньше, но не кардинально, чем создание копии 0 уровня, хотя объем создаваемой дельты-бэкапа меньше. Вероятно это из-за того, что nbackup при создании копии БД любого уровня приходится в любом случае читать весь файл с БД. Ошибаюсь? Так же предполагаю, что на рабочем сервере nbackup будет выполняться гораздо быстрее, поскольку скорость диска примерно в 5 раз выше, чем на резервном. Проверял тупо копируя файл с БД в ту же папку на тот же диск при неактивных пользователях. На резервном сервере скорость 230 МБ/с, на основном - 1 ГБ/с.

Далее попробовал "поломать" БД своими некорректными действиями:
1) Запуск нескольких экземпляров nbackup отрабатываются нормально. Точнее 2й запущенный экземпляр nbackup выдает ошибку. Это логично и с БД ничего плохого не происходит. Дельта-бэкап создается первым nbackup нормально.
2) Во время работы nbackup прибил его процесс. БД осталась в заблокированном виде, при работе с БД данные не потерялись, дельта-файл (с данными после блокировки БД) лежит рядом с БД, пользователи работают с БД нормально. Разблокировка БД с параметром -N проходит нормально, данные не потерялись. Получается, что процесс работы nbackup мне необходимо контролировать - если за определенное время после запуска текущего процесса nbackup БД не вернулась в разблокированный режим, то прибиваем процесс nbackup и вручную разблокируем БД?
Передавать при этом на резервный сервер нечего - повторяем запуск nbackup или ждем следующего запуска по расписанию.
3) Если БД осталась заблокирована с помощью запущенного nbackup, то еженощный gbak сделает бэкап данных на момент блокировки БД, а не на момент конца рабочего дня. Это мне тоже нужно контролировать.
И тем более если я ежедневно подменяю рабочую БД из backup-restore, то будет совсем беда - потеря данных до конца рабочего дня. Кстати, дельта данных при попытке разблокировки БД с параметром -N в БД, которая прошла через backup-restore, зальется в нее? Я сам еще не проверял.
4) Если попытка разблокировки БД на основном сервере прошла с ошибкой, то что делать? Такой ситуации я пока воспроизвести не смог, поэтому поэкспериментировать не на чем.
5) Если за рабочий день произошло что-то непонятное с резервной БД (дельты перестали заливаться, поломалась копия БД во время заливки дельт-бекапов и т.п.) то это все не так страшно, поскольку каждой ночью на резервном сервере база все-равно будет разворачиваться из полного бэкапа, созданного gbak на основном сервере. А вот если из-за работы nbackup на основном сервере что-то произойдет с рабочей БД, то тогда уж лучше вообще не заниматься зеркалированием данных таким способом.

Подобное уже кто-то реализовывал? С чем мне еще придется столкнуться?

Я успешность рестора контролирую. После этого подмена файлов идет - бывшая база меняется на только-то отресторенную. На всякий случай старый файл с базой кроме создания бэкапа еще и копируется как обычный файл на соседний диск. Кроме этого периодический бэкап-рестор будет выполнять функцию микроремонта базы.
По вашему опыту поддержки пользователей, какие причины приводили к проблемам при автоматической замене БД? Кроме переполнения диска, где лежит база, больше ничего в голову не приходит.



Согласен с замечаниями. Плохо разобрался.
Т.е. если мне надо чтобы файлы дельт бэкапов были небольшими по размеру, то начинаем с утра с 0 уровня, а далее 1, 2, 3, ... уровень каждые N-минут.
Ограничения на количество собираемых файлов судя по инструкции нет. Будет только ограничение windows на 2047 знаков в командной строке. Но в таком случае для сборки всей БД, допустим в конце 12-тичасового рабочего дня при периодичности раз в 15 минут понадобится 48 файлов (уровней) с дельтами бэкапов относительно небольшого размера.
Если же стоит задача уменьшить количество файлов, то необходимо будет делать допустим раз в 1 час дельту 1 уровня, затем 3 дельты 2 уровня и при этом у каждой следующей дельты 1 уровня будет расти объем по сравнению с ее предыдущей того же уровня. При этом для сборки копии БД понадобится только 3 файла: 0, 1 и 2 уровней. И в сумме по объему они будут меньше, чем суммарный объем тех 48 файлов.

Посмотрел транзакции за пятницу - 520000. При таком количестве счетчиков хватит на 4130 дней, т.е. 11 лет.
В середине недели поинтенсивнее работают - до 700 тыс. транзакций в день. В итоге - достаточно будет делать замену БД на свежеотресторенную 1 раз в год.

Так же сделал замеры по времени создания инкрементного бэкапа и обратно сборки рабочей БД.
Создание бэкапа что 0, что 1 уровня (к этому моменту сделал вставку около 20 тыс. записей в одну из таблиц) заняло одинаковое время - 6 минут (замерял bat-ником).
Обратная "сборка" БД из 4 файлов (с 0 по 3 уровень) общим объемом 70 Гб с помощью nbackup на тестовом сервере заняло 3 минуты (замерял дважды). Это получается, что анализ измененных версий записей при создании инкрементного бэкапа занимает 50% времени.

Попробовал еще в процессе создания бэкапа очередного уровня при подключенных пользователях менять структуру некоторых таблиц и ХП - все работает так же как при незалоченной БД - к примеру, DDL используемых клиентами ХП блокируются при попытке изменения.
Почему про это пишу - я делаю такие действия с рабочей БД при подключенных пользователях. Изменения типа полей у используемых таблиц и создание/удаление индексов не делаю (из-за практически гарантированной вероятности проблем из-за этого), но создание новых полей в используемых таблицах, создание новых ХП, таблиц или изменение неиспользуемых ХП - делаю.

Меня беспокоит надежность заливки дельты-БД в рабочую БД при какой-либо проблеме во время работы nbackup.
Те, кто использует nbackup - как вы отслеживаете успех его работы? Контролируете через определенное время после запуска nbackup факт наличия дельты рядом с базой? Или делаете это к примеру раз в день, после окончания работы (если база не 24х7)? При каком-либо сбое nbackup наличие нерабочего зеркала меня будет волновать меньше, чем потеря данных в рабочей базе из-за потери данных в файле-дельте.

Еще подскажите, пожалуйста, какая проверка рабочей БД будет более правильная - восстановимость бэкапа или валидация БД (gfix -v -full)?
Как я понял из статьи ( http://www.ibase.ru/db_repair/#gfix) восстановимость бэкапа более показательна и для автоматической ежедневной проверки достаточно пользоваться только ей?

Теперь понятно, подробно разъяснили. Спасибо.

Про сервисы не знал. Почитал сейчас, запустил - все работает одновременно - и изменение данных пользователями (скриптом) и action_validate и создание инкрементного бэкапа. Диск только при таком наборе сильно просаживается по скорости.