Firebird хранит и обрабатывает метаданные о собственных и созданных пользователями объектах - в базе данных! Точнее, в отдельных таблицах непосредственно в самой базе данных. Названия системных таблиц, столбцов и других системных объектов начинаются с букв RDB$.

Учитывая, что это обычные объекты баз данных, с ними можно работать (извлекать, манипулировать ими) так же как и с Вашими пользовательскими объектами. Однако, то что Вы можете это делать совершенно не означает, что Вам нужно это делать! Для определения и манипулирования метаданными в Firebird реализовано высокоуровневое подмножество SQL - DDL (Data Definition Language), в частности операторы CREATE, ALTER и DROP.

Конечно же, мы не можем требовать того, чтобы Вы использовали исключительно DDL, и запретить Вам использовать прямые SQL-операции над системными таблицами, когда бы Вам не потребовалось изменить или удалить метаданные. Но мы рекомендуем Вам отложить использование возможностей по «быстрому решению проблем» до тех пор, пока Вы не будете достаточно хорошо владеть SQL и знать механизм Firebird. Поврежденную базу данных не особо приятно созерцать и не легко починить.

По умолчанию Firebird устанавливается с включенным режимом принудительной записи - forced writes (синхронная запись). В этом режиме изменения и новые данные сразу записываются на диск.

Существует возможность использовать режим асинхронной записи данных – в этом случае изменения и новые данные хранятся в памяти и периодически сбрасываются на диск подсистемой ввода/вывода операционной системы. Общепринятое название такой конфигурации - forced writes off (или disabled). Её иногда применяют с целью повышения производительности во время пакетных операций, связанных с обработкой (модифицирующего характера) большого объема данных.

Совет: не отключайте режим принудительной записи на Windows-серврере. Замечено, что серверные платформы Windows не сбрасывают кэш записи до останова сервиса Firebird. На Windows-сервере потенциально много чего может пойти не так, не говоря о возможном перебое с питанием. В этом случае, проблемы с подсистемой ввода/вывода закончатся потерей результатов работы пользователей.

Одна из опций утилиты gbak (gbak -r[eplace]) позволяет Вам восстановить gbak-файл поверх существующей базы данных. При этом возможна ситуация, при которой вы не получите предупреждений о наличии подключенных к базе данных пользователей, в результате чего, практически гарантировано Вы получите поврежденную базу данных (с утратой работавшего экземпляра).

Рекомендуемый подход заключается в следующем. Восстановите резервную копию в отдельную базу данных (в отдельный файл или файлы), используя опцию gbak -c[reate], и протестируйте её работоспособность, например, используя утилиту isql или Ваше любимое средство администрирования. Если база данных работает нормально, остановите сервер (shut down). Сделайте файловую копию старой базы данных и затем скопируйте файл (или файлы) восстановленной базы данных поверх существующей.

Если Вы не заблокируете доступ пользователей к базе данных в процессе её восстановления командой gbak -r[eplace] , то они будут иметь возможность, подключившись, осуществить некоторые действия по изменению данных, что, в свою очередь, приведет к порче базы данных.