Дополнительные параметры restore

-c[reate]	создать (восстановить) базу данных из резервной копии
-bu[ffers] n	изменить (или указать новый) размер кэша БД. Принимается значение больше 0.
-p[age_size] n	указать новый размер страницы для базы данных
-i[nactive]	не активировать индексы.
-k[ill]	не создавать (и удалить) имеющиеся у базы данных shadow
-m[etadata]	восстановить только метаданные (без данных
-use_[all_space]	максимально заполнять страницы данных (для read-only баз). Обратного ключа нет.
-mo[de] <режим>	восстановить в режиме read_only или read_write (по умолчанию read_write)
-o	делать commit после восстановления каждой таблицы
-no_validity	не выполнять контроль данных (InterBase 6, Firebird, Yaffil)
-va[lidate]	выполнять контроль данных (InterBase 7.x, 2007, 2009), по умолчанию контроль не выполняется
-user <имя>	имя пользователя, SYSDBA или владельца БД
-pas[sword]	пароль пользователя
-v	полный вывод лога действий
-y <файл>	вывод лога в файл
Новые опции Firebird 2.1
-nodbtriggers	отключает срабатывание триггеров уровня базы данных. эту опцию может указать только SYSDBA или владелец БД
дополнительные опции Firebird 2.5 для исправления кодировки метаданных - автоматизация действий, которые при переходе с предыдущих версий на Firebird 2.1 нужно выполнять вручную.
-fix_fss_d[ata]	исправить кодировку данных
-fix_fss_m[etadata]	исправить кодировку метаданных, например -fix__fss_metadata win1251
Обе опции указываются ОДИН раз в том случае, если при восстановлении бэкапа возникает ошибка malformed string. При указании этих опций повторно при backup/restore база данных будет испорчена.
Дополнительные опции InterBase 2007
-pr[eallocate] n	Изменить или установить размер преаллокирования базы данных, где n - новое минимальное число страниц, из которых будет состоять файл базы данных. ! "Преаллокирование" на самом деле "добивает" базу данных до заданного количества страниц после выполнения restore, а не до заливки данных в БД.
Дополнительные опции InterBase 2009
-decrypt	расшифровать зашифрованный бэкап.  Подробнее читайте Data Definituin Guide, раздел Encrypting backup files.
-sep	указание System Encryption Password
Дополнительные опции InterBase XE
-eua_user -eua_password	имя и пароль пользователя БД, если включено Embedded User Authentification

Что здесь отсутствует? Правильно, знакомый многим параметр -r. Параметр -r на самом деле не -r[estore], а -r[eplace], т.е. не "восстановить", а "заменить" имеющуюся базу данных. Т.е. если в предыдущем примере команды заменить -c на -r, то существующая база данных e.fdb будет молча удалена. Этого допускать нельзя, потому что по разным причинам восстановление из резервной копии может не состояться, и тогда вы останетесь без оригинальной базы данных и с невосстановимой резервной копией.
Интересно, что иногда у людей в командной строке восстановления БД из резервной копии можно встретить и такой оксюморон:

gbak -c -r e.fbk e.fdb

Причина написания такой командной строки кроется в неверном чтении документации по InterBase. Там указано

gbak {-c|-r} [options] source dbfile

Что означает - "или -c, или -r", но никак не оба вместе. Тем не менее, лучше такие неоднозначности не устраивать.

Кроме того, в Firebird 2.0 параметр -r сам по себе был фактически запрещен, т.к. "убиение" оригинальных баз данных при помощи -r имеет массовый характер. Теперь в Firebird 2.0 параметр -r просто не работает, и вместо него нужно использовать явно -rep (или -replace_database полным текстом), или -r o (-recreate_database overwrite).

Таким образом, если требуется сделать резервную копию базы данных и тут же восстановить базу из нее на том же сервере, нужно

1. gbak -b -g e.fdb e.fbk
2. переименовать e.fdb например в tmp.fdb
3. gbak -c e.fbk e.fdb

если восстановление прошло успешно, то tmp.fdb можно удалить. До этого момента tmp.fdb категорически удалять нельзя. (есть вариации - можно восстановить не в e.fdb, а например в e1.fdb, после успешного восстановления удалить e.fdb, а e1.fdb переименовать в e.fbk)

Поборники параметра -r могут сказать, что они или выполняют пункт 2, или вместо пункта 2 копируют базу данных в другой файл (остановив сервер InterBase или Firebird, разумеется). На это могу сказать следующее - все равно использовать -r не надо. Во-первых, он несовместим с Firebird 2.0, и во-вторых, что будет, если переименование или копирование вдруг произойдет с ошибкой?

Теперь можно перейти к более подробному описанию параметров restore.

-bu n

Изменить размер кэша базы данных. По умолчанию кэш базы данных задан в файле конфигурации сервера (firebird.conf, ibconfig), и равен 2048 страниц. Это значение действует для всех баз данных, у которых размер кэша задан неявно. Если вы используете на сервере несколько баз данных, то может потребоваться указать для них разный размер кэша, в зависимости от назначения этих баз. Параметр -bu n позволяет при восстановлении базы данных задать или изменить этот размер. К сожалению, у gbak можно указать значение -bu только больше 0. Если вы обнаружили, что в бэкапе уже "зашито" значение кэша, то "сбросить" его при restore не получится. Для убирания размера кэша в БД придется использовать gfix. 
Если размер кэша вообще задан в БД (а в большинстве случаев это не делают), то этот параметр используется обычно при переносе базы данных например со старого сервера на новый, или при переносе БД между архитектурами Classic и SuperServer. 
Эквивалентно команде gfix -bu n.

-p n

Позволяет задать новый размер страницы базы данных. Это единственный способ, которым можно изменить размер страницы БД. На текущий момент можно сказать следующее - если вы посмотрели параметры БД через gstat -h, и увидели, что у базы данных размер страницы 1024 или 2048 байт - рекомендуется сделать backup и restore с указанием размера страницы 4096, 8192 или 16384 байт (если ваша версия сервера поддерживает страницы в 16к). Потому что даже небольшие базы данных с таким небольшим размером страницы имеют явно худшую производительность, чем базы со страницей 4 килобайта и выше.
Сервер сохраняет размер страницы БД при создании резервной копии, поэтому повторно указывать размер страницы при restore нет необходимости. 
Не вставляйте этот параметр в "автоматизированную командную строку restore", потому что если вы захотите изменить размер страницы текущей БД вручную, то "автоматизированный restore" поменяет ее обратно.

-i

Не выполнять создание (активацию) индексов (последняя фаза restore). После восстановления базы данных все индексы в ней останутся отключены (неактивны). Фактически с такой базой данных работать нельзя, т.к. при отключенных индексах Primary key, Foreign key и Unique возможны нарушения целостности данных в таблицах (дублирование первичных ключей и т.д.).
Данный параметр имеет смысл использовать разве что в специфических целях - например, восстановить только данные из бэкапа за максимально быстрое время, или определить длительность создания всех индексов (замерить время gbak -c, затем замерить время gbak -c -i, после чего вычесть одно время из другого - получите длительность активации всех индексов), чтобы определить или текущую производительность каталога temp, или сравнить ее с явно заданным в конфигурации расположении temp на другом физическом диске.

если вы восстановили бэкап с опцией -i, индексы можно активировать командой alter index nnn active (для каждого индекса).

-k

Не создавать shadow, если таковые были созданы в оригинальной базе данных. На самом деле этот параметр не только "не создает" shadow, но и еще удаляет существующие, например в варианте с backup/restore с промежуточным переименованием базы данных. Впрочем, поскольку использовать shadow (программный raid 1) сейчас нет смысла, то и параметр -k можно считать атавизмом.
Эквивалентно команде gfix -kill.

-m

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

-mode <режим>

По умолчанию база данных восстанавливается в режиме read_write. Однако, если вам нужно получить базу только для чтения, особенно для размещения ее на CD или DVD, то можно воспользоваться -mode read_only.
Эквивалентно команде gfix -mode read_write/read_only.

-use_

По умолчанию базы данных InterBase и Firebird резервируют примерно 30% пространства на страницах данных, для размещения версий при будущих вставках, удалениях или обновлениях записей. Если предполагается запись базы данных на CD или DVD, то лучше базу данных несколько "сжать", указав параметр -use_ при restore (одновременно указав -mode read_only).
Эквивалентно команде gfix -use full. Обратная команда (снятие режима максимального заполнения страниц)- gfix -use reserve.
! при помощи restore вы не можете указать -use reserve, такой опции у gbak при восстановлении нет ни у InterBase, ни у Firebird.

-o

Помогает при некоторых случаях "невосстановимого backup". Тут больше добавить нечего.

-n

Отключает проверку constraints, если при обычном восстановлении БД оказалось, что логическая целостность оригинальной БД была повреждена (например, из-за битого индекса PK возникли дубликаты первичного ключа).
Крайне не рекомендуется для использования в "командной строке автоматизированного restore".

-va

В InterBase 7.x, 2007 и 2009 при восстановлении БД из резервной копии параметр -n (см. выше) включен по умолчанию. Это опасно тем, что можно не заметить появление в базе данных нарушений целостности Primary key, Foreign key и Unique в случае повреждения оригинальной базы данных. Поэтому в данных версиях InterBase параметр -va рекомендуется использовать всегда, кроме случаев восстановления "невосстановимого backup".

примечание: если требуется восстановить сразу несколько баз из бэкапов, то нужно выполнить команду gbak -c для каждой базы данных отдельно, но ни в коем случае не указывать нечто вроде gbak -c *.gbk *.gdb. Шаблоны и маски в данном случае не работают.

-fix

Опции -fix_fss_metadata и -fix_fss_data у Firebird 2.5 предназначены для приведения чарсета метаданных (и данных), которые были записаны в некорректной кодировке. Например, при редактировании процедур или триггеров в код могли попасть комментарии или константы в кодировке none, в то время когда они на самом деле являются символами 1251.

Если при restore gbak выводит сообщение об ошибке

Malformed string

то нужно принудительно указать нужную кодировку при помощи указанных опций. После этого в столбцах unicode данные будут записаны корректно.

gbak от Firebird 2.5 также может выдавать сообщение

gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option.

что сигнализирует об аналогичной ситуации, и требует явного указания данной опции с нужной кодировкой.

! Указывать опции -fix... можно ТОЛЬКО ОДИН РАЗ! Если вы сделаете еще раз backup/restore этой же базы данных с этими опциями, то исходные тексты процедур и триггеров БУДУТ ИСПОРЧЕНЫ!

Другие параметры gbak - InterBase 2007 и выше

-preallocate n

весьма странная опция, учитывая то, что она "добивает" базу данных до указанного в n размера страниц, а не аллокирует сразу эти страницы в момент начала restore. Физически это выглядит следующим образом:

gbak -c -pr 1300000 db.gbk db.gdb...

1. сначала пройдет restore
2. в конце restore сервер добьет базу нужным числом страниц до заданного размера. Если размер страницы базы db.gdb был 4096 байт, то размер файла будет ровно 5324800000 байт (1.3 млн страниц умножить на 4096. то есть, к счастью, preallocate не плюсует размер преаллокирования к размеру БД).

Причем, с этого момента значение preallocate будет кочевать из базы в бэкап и обратно, до тех пор пока при очередном restore не будет сброшено опцией -pr 0.
Одновременно, если вы поменяете при restore размер страницы, автоматически изменится и значение preallocate, чтобы соблюсти заданный размер независимо от размера страницы.

Если вы делаете restore бэкапа рабочей базы себе на компьютер, то сначала посмотрите gstat -h db.gdb, нет-ли там опции preallocate. Если есть - при restore придется указать -pr 0, иначе сервер развернет базу у вас на компьютере в полный размер preallocate.

Services API - restore

Здесь все то же самое, что и при создании резервной копии:

gbak -c -se server:service_mgr d:\e.fbk c:\db\e.fdb

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

Ошибки при restore

Причины "невосстановимости" резервных копий подробно описаны в статье. Здесь я опишу в общих чертах причины и моменты, когда такие ошибки могут произойти. Если вернуться к описанию последовательности процесса restore, то можно сказать следующее:

• на этапах 1 и 2 (создание БД и создание описаний таблиц и индексов) ошибки вряд ли могут произойти. Разве что если вы пытаетесь создать БД там, где это сделать невозможно - нет прав, read-only носитель и т.п.
• на этапе 3 (заливка данных) могут быть ошибки, которые "чинятся" повтором restore с параметром -o
• на этапе 4 (заливка процедур, триггеров и т.п.) могут быть ошибки, связанные с некорректным blr (двоичным кодом) процедур и триггеров. Текст процедур и триггеров в этот момент никакого значения не имеет, он даже может отсутствовать в оригинальной базе и резервной копии.
• на этапе 5 (создание индексов) могут быть ошибки, связанные с нарушением целостности первичных, вторичных и уникальных ключей (повреждения индексов в базе). До Firebird 2.0 такие ошибки приводили к прекращению restore, и в базе оказывались неактивными все индексы, шедшие после "проблемного". Firebird 2.0 продолжает активирование индексов после такой ошибки.

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

Если в БД не оказалось процедур или триггеров, то их надо извлечь в виде скрипта из оригинальной базы, и создать в новой БД. Если в БД нет части индексов, то их надо пробовать активировать по очереди (вручную), одновременно корректируя данные, которые препятствуют созданию соответствующего индекса (дубликаты первичного ключа, отсутствующие данные для вторичного ключа, и т.д.)

Хуже, если резервная копия оказывается битой сама по себе. В данном случае сможет помочь только инструмент IBBackupSurgeon, который позволяет "вытащить" все что было в резервной копии, полностью или по частям, даже если резервная копия имеет повреждения "посередине".

Заключение по restore

Никогда не используйте параметр -r. Всегда используйте -v - это поможет вам определить в случае ошибки, что восстановилось из БД, а что нет. Если во время restore произошла ошибка, то база данных будет в состоянии shutdown, т.е. к ней сможет присоединиться только SYSDBA или владелец БД. Поэтому невозможность для обычных пользователей подсоединиться после restore может служить дополнительным сигналом, что восстановление не прошло нормально, если вы не проверяете логи restore.

Как правило, restore по времени занимает в 2-4 раза дольше, чем backup. Это не относится к восстановлению из резервных копий nbackup или online dump.

Замечание по Services API

Вы уже в курсе, что можно заставить сервер делать backup или restore, через Services API - компонентами или утилитой gbak с опцией -se.

Как показывают тесты, как минимум backup через Services API происходит быстрее, чем с использованием локального протокола или tcp. Однако, если потребуется прекратить процесс backup или restore, то

• для gbak -b/-c достаточно принудительно снять (завершить) процесс gbak.exe, или если он запущен интерактивно, нажать в окне cmd Ctrl-C. Поскольку backup или restore выполняется не сервером, а утилитой gbak, этот процесс будет прекращен.
• для backup и restore, выполняемых через Services API, это возможно только остановкой сервера, т.к. именно он выполняет этот процесс.

Автоматизация резервного копирования

Автоматизацию резервного копирования можно выполнить как самостоятельно, так и при помощи готовых инструментов. Например, как готовое решение можно использовать наш FBDataGuard Community Edition, который не только защищает базу данных от повреждений, но и может делать резервные копии по расписанию, тестовое восстановление, а также отправку уведомлений по email, и много других полезных вещей. Кроме него, разумеется, есть ряд других инструментов для автоматизации резервного копирования (только), но здесь мы их рассматривать не будем.

Что нужно помнить при самостоятельной автоматизации резервного копирования, производимой скриптами, написанными вручную

1. команда gbak -b database.gdb database.gbk сотрет имеющуюся резервную копию с именем database.gbk
2. не рекомендуется сохранять резервную копию на тот же самый логический диск, где находится база данных. Исключением можно считать одинокий клиентский компьютер, у которого есть только один диск C:.

Итак, у нас есть утилита командной строки gbak, и средства операционной системы для периодического выполнения команд - в Windows это AT или "планировщик заданий", в Unix - cron. Вот пример использования at в Windows:

Создаем файл backup.cmd. В файле должна быть одна команда создания резервной копии БД, возможно с параметром, указывающим некое число или день.

@echo off
set DOW=%1
del d:\backup\data%DOW%.log
c:\interbase\bin\gbak -b -g -user sysdba -pass masterkey localhost:c:\db\data.gdb 
d:\backup\data%DOW%.gbk -v -y d:\backup\data%DOW%.log 

Здесь всего три строки - последние "две" на самом деле одна строка, здесь разбита на две части для облегчения читаемости. Полные пути прописаны для того, чтобы backup.cmd можно было вызвать из любого каталога.

Если мы вызовем командный файл как

backup.cmd 1

то в результате в каталоге d:\backup будет создана резервная копия data1.gbk и лог data1.log

Теперь автоматизируем вызов at. Можно открыть окно командной строки (Пуск, выполнить, cmd), а можно открыть в Панели управления окно планировщика задач и задать нужные параметры интерактивно. Я приведу текст командного файла conf_at.cmd, который автоматически задает для AT создание резервных копий каждый день недели:

at %1 /every:M   c:\backup.cmd Mon
at %1 /every:T   c:\backup.cmd Tue
at %1 /every:W   c:\backup.cmd Wed
at %1 /every:Th  c:\backup.cmd Thu
at %1 /every:F   c:\backup.cmd Fri
at %1 /every:S   c:\backup.cmd Sat
at %1 /every:Su  c:\backup.cmd Sun

Теперь можно вызвать этот командный файл как

conf_at 03:00

в результате каждый день недели ровно в 3 часа ночи at будет запускать backup.cmd с соответствующим параметром. И мы в каталоге d:\backup получим т.н. "револьверный" бэкап, то есть по одной резервной копии на каждый день недели, которые будут перезаписываться каждый день.

Имена резервных копий будут dataMon.gbk, dataTue.gbk и т.п., что не совсем удобно при просмотре каталога. Вместо Mon, Tue и так далее можно задать номера дней 1, 2, 3..., только главное не забыть, какой день недели у вас соответствует цифре 1.

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

Если backup делается на другой компьютер, то нужно задавать команды AT от имени пользователя, который имеет право доступа к разделяемой папке на этом компьютере. Также можно добавить обработку ошибок в backup.cmd, даже с отправкой email в случае ошибки, но это выходит за рамки статьи.

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

Автоматизированное восстановление

на самом деле зло. Что, если автоматический бэкап завершился с ошибкой? Что будет, если при автоматизированном восстановлении возникнет ошибка?

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

Соответственно, примеров автоматизированного восстановления не даю. Схематически верный вариант изложен в разделе об опциях restore.

Есть вопросы по статье? присылайте на support@ibase.ru.

• Причины повреждений баз данных. Как починить базу данных InterBase или Firebird?
• Администрирование