научите про gfix...

[sydenis]

FB 1.5.3
Выполняю такой вот батничек на базе, к которой есть несколько подключений:

gbak -b -g host:d:\base.fdb d:\base.fbk --архивируем
gfix -sh -force 2 host:d:\base.fdb --останавливаем
gbak -r -p 4096 d:\base.fbk host:d:\base.fdb --ресторим

если не вдаваться в дискуссию о вреде рестора на рабочую базу, возникает такая вот проблема:
скрипт отрабатывает нормально, но ресторить не даёт - говорит, что database in use...
А чем тогда gfix занимается? Да и реально в оставшихся коннектах работать невозможно - они говорят, то lost connection.
Так непонятно кто же врёт и как тогда надо правильно организовывать останов базы для рестора?

[Merlin]

FB 1.5.3
Выполняю такой вот батничек на базе, к которой есть несколько подключений:

gbak -b -g host:d:\base.fdb d:\base.fbk --архивируем
gfix -sh -force 2 host:d:\base.fdb --останавливаем

Это только кажется. Что останавливаем. Во-первых, бага там, зафтксированная в тракере - форс работает правильно только с параметром 0.

gbak -r -p 4096 d:\base.fbk host:d:\base.fdb --ресторим

если не вдаваться в дискуссию о вреде рестора на рабочую базу,

LOL вообще-то.

возникает такая вот проблема:
скрипт отрабатывает нормально, но ресторить не даёт - говорит, что database in use...
А чем тогда gfix занимается?

А gfix занимается установкой флага в хидере. И фсё. Соединения никуда не деваются, но сделать ничего кроме как завершиться не имеют права. В теории.

Да и реально в оставшихся коннектах работать невозможно - они говорят, то lost connection.

Врёш. Они говорят что датабазе шутдовн.

Так непонятно кто же врёт и как тогда надо правильно организовывать останов базы для рестора?

Кто врёт, мы уже разобрались а про дальше ты же просил не вдаваться.

[sydenis]

большой сенкс
бум работать дальше в этом направлении

[WildSery]

Всё же глупо.
Неужели трудно ресторить с именем, к примеру, base.rs, а затем если gbak ошибок не вернул переименовывать после рестора в рабочее состояние?

[CyberMax]

Как база грохнется, сразу поумнеет.
P.S. Дураки учатся на своих ошибках, умные - на чужих. Вывод - дураки учат умных .

[kdv]

в общем, в третьем пункте надо ресторить в БД с другим именем.
потом останавливать сервер ib/fb (net stop или instsvc stop), потом переименовывать оригинальную БД, переименовывать ресторенную БД в оригинал, и стартовать сервер (net start или instsvc start).

т.к.
а) когда сервер остановлен, пользователям некуда ломиться, и они не подсоединятся при ресторе (включая SYSDBA)
б) если вдруг приспичит перейти на линукс, то даже при 1-м коннекте сервера к БД удаление БД реально файл не удаляет, т.е. этот коннект останется на "удаленном файле".

[sydenis]

коль уж всё-таки начали это обсуждать, то...
конечно опасности моего рестора очевидны, но как ни извращайся ошибка может возникнуть на любом этапе - ресторь ты на живую базу или манипулируй с остановами и переименованиями imho...
в любом случае приходится как-то надо анализировать поток ошибок и надеяться на удачу.
100% защищённого варианта автоматического бэкапа я не встречал.

[CyberMax]

конечно опасности моего рестора очевидны, но как ни извращайся ошибка может возникнуть на любом этапе - ресторь ты на живую базу или манипулируй с остановами и переименованиями imho...

Парень, ты ходишь по краю кратера. Неверное движение - и тебя "жарит" начальник и твои сотрудники, так как ты остаешься без актуальной базы (потеряешь данные с момента последнего бэкапа). Если же ресторить в другой файл - в случае ошибки база будет жить. Максимум - потеряешь один (или несколько) бэкапов, что в принципе не страшно. Такое бывает, но редко (например, свободное место закончилось либо что-то другое). Далее. А если бэкап не сработает и gbk'шником останется предыдущий бэкап? Тогда твоя рабочая база будет замещена старой копией. Что тоже популярности тебе не прибавит.

в любом случае приходится как-то надо анализировать поток ошибок и надеяться на удачу.
100% защищённого варианта автоматического бэкапа я не встречал.

И не встретишь. Все равно надо проверять. Да и зачем тебе каждый день разбекапленная база? Раз в неделю/две недели/месяц обычно достаточно.

[sydenis]

дык я ровно про то же самое и говорю...
несколько строчек скрипта, которые приведены вначале треда - просто выжимка из более сложной конструкции и нужны тока, чтоб мне спросить о том как работает gfix
реальный скрипт позволяет воссоздать базу на любое состояние в течении последних 2х недель (такой срок нужен по специфике),
он ресторит в другой файл, а вывод gbak сливается в файл, в котором потом ищется error и тока потом...
в общем там ещё до хрена чего делается, но всё это лишь извращения на тему, о которой я писал выше - при "удачном" стечении обстоятельств могут не спасти никакие шаманские пляски с переименованиями.

[Dimitry Sibiryakov]

Если вообще не трогать базу с которой делался бэкап, вероятность такого стечения обстоятельств можно сильно уменьшить. В чем вообще фенька рестора? Индексы перестроить?..

[sydenis]

вопрос не в бровь, а в глаз )
это ты меня, Василий Иванович, крепко поправил

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

[CyberMax]

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

[kdv]

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

дело вкуса. так многие делают. даже на ~5-гиговых базах, не имея проблем с длительной работой БД.

[CyberMax]

А вот и обещанный bat-файл:

Код: Выделить всё

@ECHO OFF

REM Имя учетной записи
SET FB_USERNAME=SYSDBA

REM Пароль учетной записи
SET FB_PASSWORD=masterkey

REM Путь к базе данных на сервере
SET DATABASE_PATH=G:\Abonent\

REM Имя файла БД (без расширения)
SET DATABASE_NAME=Abonent

REM Путь для хранения архива резервной копии БД
SET BACKUP_PATH=G:\ABONENT\BACKUP\

REM Путь к утилите gbak.exe
SET GBAK=c:\progra~1\firebird\bin\gbak.exe

REM Путь к архиватору
SET WINRAR=c:\progra~1\winrar\winrar.exe

REM Если уже есть бэкап базы, удаляем его
IF EXIST %BACKUPPATH%%DATABASENAME%.GBK DEL %BACKUPPATH%%DATABASENAME%.GBK
REM Если уже есть распакованная база, удаляем ее
IF EXIST %BACKUPPATH%%DATABASENAME%.GDB DEL %BACKUPPATH%%DATABASENAME%.GDB

REM Создание резервной копии БД
%GBAK% -b -v -user %FB_USERNAME% -password %FB_PASSWORD% "%DATABASE_PATH%%DATABASE_NAME%.GDB" "%BACKUP_PATH%%DATABASE_NAME%.GBK"
IF ERRORLEVEL == 1 GOTO GBAK_ERROR

REM Выполнение архивирования созданной резервной копии БД
REM Переход в саму папку, чтобы в архиве не было вложенных папок
G:
cd Abonent\backup\
%WINRAR% a -agYYYY-MM-DD z:\kms_ *.*
IF ERRORLEVEL == 1 GOTO ARC_ERROR

NET SEND 127.0.0.1 Archive "Abonent" created.
GOTO END

:GBAK_ERROR
NET SEND 127.0.0.1 Error Firebird.
GOTO END

:ARC_ERROR
NET SEND 127.0.0.1 Error WinRAR.
GOTO END

:END
EXIT

[sydenis]

Хорошая штука, правда кое-что делаю иначе, но это дело вкуса...
Но вот, насчёт проверки на ресторабельность бакупа тут, имхо, слабовато:
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
И это единственная проверка?
Дык у меня сколько раз было бэкапится нормально, а рестор не идёт - например у тебя там где-нть поле есть с кондишеном, а в нём одно значение, оставшееся от каких-то давних тестов и не проходящее по кондишену... или просто файл бэкапа на бэд сектор записался...

[CyberMax]

Но вот, насчёт проверки на ресторабельность бакупа тут, имхо, слабовато:
IF ERRORLEVEL == 1 GOTO GBAK_ERROR
И это единственная проверка?

Здесь нет проверок на ресторабельность бэкапа . Только проверка на то, что *.gbk создался нормально. Просто у меня бэкап и рестор базы разнесены во времени. То есть сначала делается этим батником (немного измененным) бэкап с архивом, а через несколько часов запускается уже другой батник с рестором, в котором стоит аналогичная проверка на ErrorLevel. Конечно, ничего не мешает делать все это в одном батнике.