Сильно не пинайте, занимался уже 2 раза востановлением своей базы. К сожалению информации приложенной к файлику fbtools не хватило, поискал и нашел статейкую Приведу цитату
4. Проверьте базу данных на повреждения.
gfix при проверке БД на наличие повреждений выводит информацию о повреждениях в interbase.log или firebird.log (подробно) и на экран (суммарно). Поэтому чтобы посмотреть на подробное описание повреждений, перед запуском команды ремонта БД следует переименовать interbase/firebird.log (например, firebird1.log, firebird20071010.log и т.д), чтобы уже хранимая там информация не мешала дополнительному выводу gfix. Когда сервер не обнаружит лог-файл, он его создаст заново.
gfix -v -full database.gdb
Если выдаются ошибки checksum error, то нужно выполнить следующую команду
gfix -v -ignore database.gdb
5. Если предыдущая команда обнаружила ошибки, то нужно их исправить командой.
gfix -mend database.gdb
! ключ -mend помечает поврежденные структуры как исключаемые при backup. В результате целостность между таблицами может быть нарушена, и даже если после этого backup пройдет, не факт что базу данных удастся восстановить из backup. В этом случае придется вручную копировать данные при помощи утилит вроде IBPump.
6. Проверим, все ли починилось.
gfix -v -full database.gdb
7. Если на этот момент вы все еще видите ошибки, то надо попытаться сделать backup, при этом обязательно нужно отключать сборку мусора (ключ -g):
gbak -b -v -ig -g database.gdb database.gbk
ключ -ig игнорирует ошибки при чтении структур данных, и пытается сохранить в backup все неповрежденные структуры и данные.
! Никогда не указывайте ключ -ig при обычном бэкапе - если в базе есть ошибки, gbak их проигнорирует и вы не узнаете, что база была повреждена. В результате такой бэкап может быть невосстановимым.
! если ваши приложения работают с двухфазным коммитом, то возможно потребуется ключ -limbo для игнорирования зависших 2pc транзакций (limbo).
8. Теперь надо попытаться восстановить базу данных из backup:
gbak -c -v database.gbk new.gdb
! никогда не делайте restore поверх существующей базы данных. В случае ошибки при restore вы лишитесь оригинальной базы данных.
9. Если при restore есть ошибки, то нужно попробовать следующие ключи:
-inactive, если есть проблема с индексами, то с этим ключом база будет восстановлена с деактивированными индексами. Их можно потом активировать (altex index X active) поодиночке.
-one_at_a_time, этот ключ приводит к commit после восстановления каждой таблицы. По крайней мере будет восстановлена хотя бы часть таблиц.
! gbak в InterBase 7.x по умолчанию не проверяет при restore следующие ограничения - not null, check, primary, unique, foregin key. Для восстановления оригинального функционирования gbak процесс restore должен проводиться с ключом -validate. У Firebird наоборот, проверка ограничений включена, поэтому для ее отключения нужно указывать ключ -no_validity. Если до сих пор так и не получилось сделать нормально backup и restore, но доступ к поврежденной базе все-таки есть, можно попробовать утилитой IBPump (или другими) скопировать хотя бы часть (неповрежденную) данных.
Невосстанавливаемый backup
Получить backup, который не пройдет restore ("невосстанавливаемый" или "невосстановимый") вполне возможно по ряду причин и без сбоев сервера или оборудования. Для минимизации потраченного времени на поиск мест, где эти ошибки происходят, всегда нужно делать restore с ключом -v, и еще лучше - с выводом в файл (gbak .... -v -y rest_log.txt). Если с починкой не сможете справиться сами, то тогда как минимум сможете предъявить в news-конференции или службе технического сопровождения точное сообщение об ошибке.Существует утилита IBBackupSurgeon, которая позволяет вытащить из бэкапа БД необходимую информацию, даже в случае повреждения файла бэкапа. Также его можно использовать для нормальных или поврежденных бэкапов с целью извлечения из них только части хранимой информации (данных, структур и т.п.).
Полный текст
http://www.ibase.ru/devinfo/db_repair.htmУпомянутые утилиты можно найти в
этом архиве.
