Re: Что делать если не проходит Backup/Restore

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

Ну а что делать если резервной копии нет, в БД много наработок, или просто нужно попытаться получить отчет по тому что же делалось в последнее время чтобы попробовать восстановить информацию. Есть платные услуги сторонних фирм по восстановлению баз www.ibase.ru, хотя насколько они помогут не известно никому. Здесь будет описан путь по которому нужно пройти чтобы восстановить базу и что в результате можно будет получить.

Итак шаг 1. Нужно получить Backup. Этот шаг можно пропустить если у вас есть уже копия Backup с которой вы просто не можете сделать Restore, но это как раз наихудшая ситуация, когда из рабочей базы данных не удается сделать даже Backup – это означает что были какие то сбои в работе сервера БД (подробности на www.ibase.ru/devinfo/db_repair.htm ).

Итак, для начала проверяем БД на ошибки запускаю из командной строки утилиту Interbase ( она должна лежать там где установлен Interbase в папке Bin, например "C:\Program Files\InterBase Corp\InterBase\bin\gfix.exe ")


gfix -v -full database.gdb

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


gfix -mend -ignore database.gdb

в данном случае эта утилита фактически выкусывает ошибочные страницы из БД. От того, что лежит на этих страницах будет все и зависеть. Если там лежали индексы – то ничего страшного, они будут перестроены и вы ничего не потеряете. Если ваши данные – то вы их потеряли, и скорей всего то, что на них ссылалось. Например если в сбойных страницах хранилась номенклатура, то вы потеряете часть справочника номенклатуры (какую сказать сложно, придется выверять весь справочник) и, например, если эта номенклатура использовать в спецификациях, то придется удалить эти строчки из спецификации (хотя тут можно будет уже уточнить какие именно спецификации были повреждены, а по ним, возможно, и потерянную номенклатуру). Бывает что удается отделать таким мелочами и получить рабочую базу, но это возможно не всегда sad. Ну а если в сбойных страницах лежали системные таблицы то результат сильно не предсказуемый. Это как объяснение того, что происходит, думать о нем пока рано, а потому двигаемся далее.

Проверяем снова на ошибки и надеемся что теперь все пройдет (что бывает не всегда)


gfix -v -full database.gdb


Если ошибки были, можно наверное повторить исправление, но видимо вряд ли удастся. Пробуем сделать Backup (как рекомендуют в статье отключив сборку мусора www.ibase.ru/devinfo/db_repair.htm)


gbak -b -v -ig -g database.gdb database.gbk

если бакап получить так и не удалось, то сделать с этой базой видимо ничего уже нельзя. [/ul]

Шаг 2. Итак мы имеем Backup, которые не восстанавливается, или который нужно восстановить после Шага 1. Делаем Restore БД командой


@echo off
rem --------------------------------------------------------------------
rem -b[ackup_database]    Back up database to file or device.
rem -e[xpand]        Do not create a compressed back up.
rem -fa[ctor] n        Use blocking factor n for tape device.
rem -g[arbage_collect]    Do not garbage collect during backup.
rem -ig[nore]        Ignore checksums during backup.
rem -l[imbo]        Ignore limbo transactions during backup.
rem -m[eta_data]    Back up metadata only, no data.
rem -ol[d_descriptions] Back up metadata in old-style format.
rem -pa[ssword] text    Check for password text before accessing a database. 
rem -t[ransportable]    Create a transportable back up (useful for copying a database to different operating systems).
rem -u[ser] name     Check for user name before accessing remote database. 
rem -v[erify]        Show what gbak is doing.
rem -y [file | suppress_output]     
rem     Direct status messages to file or suppress output messages. 
rem     Suppresses messages if file is omitted. 
rem --------------------------------------------------------------------

gbak.exe -create_database -kill -page_size 4096 -user SYSDBA -password masterkey -verify Restore.msg database.gbk databaseNew.gdb

и с нетерпением ждем. Если все прошло – значит проблем уже больше нет (видимо на Шаге 1 мы удалили сбойные страницы индексов, и при restore они восстановились). Ну скорей всего ошибки есть. Полученный в результате этой работы лог Restore.msg обязательно сохраняем где-нибудь с пометкой – restore не проходил с таким сообщением – он бывает очень полезен.

Шаг 3. Пробуем восстановить базу данных с дополнительными ключами


gbak.exe -create_database -kill -page_size 4096 –inactive -one_at_a_time -user SYSDBA -password masterkey -verify Restore.msg database.gbk databaseNew.gdb

Теперь мы пытаемся восстановить БД без индексов и по одной таблицы. Возможно теперь нам удастся получить хоть часть данных,(но часть будет точно потеряна). Если restore не прошел и в этом случае – то видимо дело совсем плохо и сделать с этой базой ничего уже нельзя sad. Ну а если мы получили успешный restore то переходим к следующему шагу.


Шаг 4. Итак мы имеем хоть как то восстановленную БД. Работать с этой БД нельзя ни в коем случае!!! Берем утилиту CSDNBackup.exe из дистрибутива TechnologiCS (эта утилита предназначена в первую очередь для перехода между платформами, но она поможет так же и в данном случае). Итак запускаем ее, указываем путь к нашей восстановленной базе и говорим сделать Backup. Эта утилита вытаскивает все данные из вашей БД и складывает их в файле с расширением cbk. Если она в процессе работы выдала ошибку, значит скорей всего в БД серьезные ошибки (видимо были повреждены системные таблицы) и восстановить БД будет невозможно, только отдельные таблицы, но такая информация вряд ли будет полезной. В любом случае сохраните лог выданный этой программой, и вместе с логом полученным при restore  вышлите в службу техподдержки ( technologics@csoft.ru ), но работа с этой базой данных скорей всего будет невозможна.


Шаг 5. Если мы получили backup сделанный программой  CSDNBackup.exe, то теперь следует запустить ее снова и Restore в новую БД. Программа работает таким образом, что пропускает ошибки создание индексов и выводит их конце работы с программой. В этом случае она пишет что работа завершена успешно, и выдает протокол работы. Это значит мы получили более менее работоспособную копию БД.

Шаг 6. Теперь нужно взять лог созданный при restore Interbase-ом (restore.msg он назывался у нас), взять лог созданный при Restore программой CSDNBackup (называется CSDNRestore.log обычно), запустить программу CSDNUpdate из дистрибутива TechnologiCS, снять в ней скрипты с БД (там есть такая команда отдельно), взять все содержимое папки REPORT созданной при этом,  выслать все это в службу техподдержки и ждать результата. Сразу скажу что мгновенного результата не будет, так как требуется проанализировать все протоколы, по ним сделать вывод о возможности не возможности дальнейшей работы с базой, после чего начнется процесс постепенного! выявления потерянных данных ( по времени довольно непредсказуемый с учетом дистанционного общения ) . Результатом этого станет скрипт исправления ошибок в БД, выполнение которого через программу CSDNUpdate даст работоспособную БД, по возможности с указанием всех мест где имеют место ошибки.  После чего на полученной БД нужно сделать Backup/Restore средствами самого Interbase и продолжать работу.


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

PS. Все вышеперечисленные программы относятся к версии 2.9.5.0 (название и состав в других версиях может измениться). 

PPS. Так же эта инфомация не относится к случаю, когда Backup/Restore перестают проходить после процедуры обновления БД (а до обновления все проходило нормально). В этом случае считается что не прошло обновление, и требуется выслать содержимое папки REPORT в службу техподдержки.