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

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

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

В программе мониторинга БД (*:\StroySoft\Utils\IBBackup_Configurator.exe)Выбираете "Действия" - "Восстановление из резервной копии"Указываете путь к файлу из папки BackupДалее указываете путь, куда будет сохранена восстановленная БД

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

Здравствуйте!В продолжение темы поведаю свою историю.Выделенный сервер со Сметой 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 результата не дало.. Хорошо, что чисто случайно при настройке копирования бэкапов на другой ресурс админы случайно галочкой отметили и саму базу (правда выснилось это неделю спустя ). Сейчас запустил, но осадочек остался - тем более что на форуме уже кто-то о похожей проблеме писал. Получается не стоит доверять штатному механизму? (галка проверки базы на корректность стояла) или все-таки какие-то ошибки в моей базе приводят к такому результату? Готов предоставить доп. информацию, файл бэкапа для анализа.

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

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

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

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

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

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

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