Восстановление удаленной базы из бэкапа

**Vlassoff** Пт Окт 10, 2014 6:35

Путем не совсем адекватных моих действий, была удалена база DataSD.ssd
В папке c:\stroysoft\Server\Base\Backup\
Остались файлы с расширением gbk, можно с них как-то восстановить базу, или это невозможно?

Ваша реклама

**Akina** Пт Окт 10, 2014 9:56

Воспользуйтесь штатной процедурой восстановления через Программа мониторинга БД - восстановление базы данных. Или утилитой командной строки Firebird (gbak.exe).

**Vlassoff** Пт Окт 10, 2014 14:54

Хороший ответ. Синтасис утилиты где посмотреть. Надеюсь, тут консультируют все-таки сметчиков, а не линуксоидов.

**ArtemovSS** Пт Окт 10, 2014 15:30

В программе мониторинга БД (*:\StroySoft\Utils\IBBackup_Configurator.exe)

Выбираете "Действия" - "Восстановление из резервной копии"
Указываете путь к файлу из папки Backup
Далее указываете путь, куда будет сохранена восстановленная БД

**Akina** Вт Окт 14, 2014 10:47

Vlassoff писал(а):Надеюсь, тут консультируют все-таки сметчиков, а не линуксоидов.

В таком случае используйте штатные инструменты обслуживания баз данных.

**pogoda** Чт Окт 23, 2014 10:58

Здравствуйте!
В продолжение темы поведаю свою историю.
Выделенный сервер со Сметой 8.0.0.26, программа мониторинга 3.1.0.0. Ежедневные бэкапы.., которые хранились на внешнем носителе.
Случился падеж сервера. Остались бэкапы. Попытка восстановить штатными средствали успехом не увенчалась.
База около 3 гигов, и спустя примерно 1,5 часа процесс восстановления прерывался.
Вот выжимка из лога.
==========
[0143797] gbak: activating and creating deferred index FK_A_S_RES_CENLVL_ID
[0143798] gbak:cannot commit index FK_A_S_RES_CENLVL_ID
[0143799] gbak: ERROR:violation of FOREIGN KEY constraint "FK_A_S_RES_CENLVL_ID" on table "A_S_RES_CENLVL"
[0143800] gbak: ERROR: Foreign key reference target does not exist
[0143801] gbak: activating and creating deferred index FK_A_S_RES_CENLVL_IDCENLVL
[0143802] gbak: activating and creating deferred index FK_A_LZ_CENLVL_ID
[0143803] gbak: activating and creating deferred index FK_A_LZ_CENLVL_IDCENLVL
[0143804] gbak: activating and creating deferred index FK_A_S_ETALON_RES_CENLVL_ID
[0143813] gbak: activating and creating deferred index FK_D_GR_RES_CEN_LEVELS_UNDO_1
[0143814] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_ID
[0143815] gbak:cannot commit index FK_A_SMETA_INDLVL_ID
[0143816] gbak: ERROR:violation of FOREIGN KEY constraint "FK_A_SMETA_INDLVL_ID" on table "A_SMETA_INDLVL"
[0143817] gbak: ERROR: Foreign key reference target does not exist
[0143818] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_IDCENLVL
[0143830] gbak: committing metadata
[0143831] gbak:finishing, closing, and going home
[0143832] gbak:Database is not online due to failure to activate one or more indices.
[0143833] gbak:Run gfix -online to bring database online without active indices.
=================
Обновление программы мониторинга до 4.0 результата не дало.. Хорошо, что чисто случайно при настройке копирования бэкапов на другой ресурс админы случайно галочкой отметили и саму базу (правда выснилось это неделю спустя

). Сейчас запустил, но осадочек остался - тем более что на форуме уже кто-то о похожей проблеме писал. Получается не стоит доверять штатному механизму? (галка проверки базы на корректность стояла) или все-таки какие-то ошибки в моей базе приводят к такому результату? Готов предоставить доп. информацию, файл бэкапа для анализа.

**Voyager`tm** Чт Окт 23, 2014 11:16

Только что эта же тема обсуждалась здесь
forum4/topic36083.html
решение там же

Вообще, проблема проявилась не так давно и связана, по-видимому, с ошибкой разработчиков firebird (версия 2.5.0-2.5.2) в реализации поддержки целостности индекса. Причем, проверка такой базы не выдает наличия ошибок! Ошибка эта проявляется достаточно редко, поэтому и не носит характер массовости. Программа мониторинга баз данных на эту ситуацию действительно не заточена, более то, при ошибках при восстановлении файл БД удаляется (исходный остается).

**pogoda** Чт Окт 23, 2014 12:32

Да, замечательно.. Только как решить вопрос если на руках нет базы, а только бэкапы, созданные оказывается с неустранимой ошибкой..

**Voyager`tm** Чт Окт 23, 2014 13:10

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

**pogoda** Чт Окт 23, 2014 15:05

Хорошая позиция..
Т.е. обычный рядовой сметчик, использующий легально приобретенное ПО, в результате некорректной работы штатной функции (которая собственно и разработана для обеспечения восстановления данных на случай сбоя) должен занятся поисками каких-никаких профессионалов, которые может быть (естественно за деньги) не дадут пропасть результатам 10-летней работы..
А если еще это и сетевая версия с 20-и пользователями, то масштабы трагедии легко можно себе представить..
Так? Я все правильно понял?

**Kir** Пт Окт 24, 2014 10:31

pogoda писал(а):Только как решить вопрос если на руках нет базы, а только бэкапы, созданные оказывается с неустранимой ошибкой..

pogoda, что я могу вам порекомендовать в этом случае. Обратитесь к нашим региональным партнерам. Исхожу из того, что у вас есть договор на сопровождение. Через них передайте нам бэкап(ы). Устраним ошибки.

**pogoda** Пт Окт 24, 2014 11:43

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

**Akina** Пт Окт 24, 2014 12:29

pogoda писал(а): Я все правильно понял?

Ну как бы правильная схема резервирования данных предусматривает не только создание архива, но и контроль его валидности. Каковой можно сделать единственным способом - попыткой восстановить из него базу данных. В этом случае ошибка вылавливается на первом же проблемном бэкапе. Если система резервирования данных не организована правильно - стоит ли удивляться, что её "провал" выставляет владельца на деньги?

К тому же проблема у ТС была усугублена сознательным (пусть и по неосторожности) физическим уничтожением рабочего файла БД. Не будь она удалена - восстановление работоспособности БД значительно упростилось бы. Да и в текущем состоянии ничего фатального не произошло - просто надо было использовать не совсем тривиальный метод восстановления БД из бэкапа.