Каталог
Поиск
Голосование
Сколько контроллеров в Вашей системе "АВАНГАРДЪ"?

Телефон: +7 (921) 898.45.35, +7 (495) 777.66.75 доб.118325 по рабочим дням с 11 до 17 по Мск.

Skype: mmayorov

Оглавление

Назначение

Утилита gbak, входящая в комплект любого дистрибутива СУБД Firebird и InterBase, является средством создания резервных копий баз данных, и восстановления баз данных из резервных копий.

Термин "резервное копирование" имеет достаточно общий смысл, целью которого является получение копии базы данных, пригодной для архивирования. Например, "резервную копию" БД можно изготовить простым способом - скопировать базу данных, предварительно остановив Firebird/InterBase (иначе, при работающем сервере, копия будет являться "поврежденным файлом", т.к. копирование производится последовательно, а база данных - файл произвольного доступа). Если же нужно сделать резервную копию базы данных "на ходу", во время работы СУБД, то для этого и предназначен gbak.

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

Создание резервных копий - backup

gbak является программой, которая подсоединяется к базе данных, стартует транзакцию snapshot, и затем сохраняет в специальный файл метаданные (описания таблиц, процедур, триггеров и т.д) и данные (запросами select * from tablename). Вы можете самостоятельно написать подобную программу, например для экспорта данных из БД в какой-либо другой формат.

Благодаря тому, что считывание данных происходит в транзакции snapshot, gbak на протяжении процесса чтения данных "видит" неизменные данные благодаря версионности. То есть, во время работы gbak другие приложения могут работать с базой данных. Однако, те изменения, которые были произведены приложениями во время работы gbak, разумеется не будут сохранены в резервную копию БД.

Формат командной строки для создания резервной копии простой

gbak <опции> <база> <резервная копия>

Основная опция при создании резервной копии -b (другие опции подробно описаны дальше). Причем опции могут быть указаны как в начале, так и в конце. Как правило, gbak при выполнении резервного копирования и восстановления требует указать имя и пароль пользователя. Это могут быть или SYSDBA, или имя владельца базы. Например:

gbak -b employee.fdb emp.fbk -user SYSDBA -pass masterke  

Чтобы не засорять текст постоянными -user... -pass... я дальше в примерах не буду приводить их в командной строке. Если же вы предполагаете вызывать gbak несколько раз подряд в одном окне консоли или bat/cmd-файле, то можно установить переменные среды

SET ISC_USER=SYSDBA
SET ISC_PASSWORD=masterke

после чего в этом окне консоли или bat/cmd файле вводить опции -user и -password не потребуется.

Также для облегчения читаемости я рекомендую использовать следующий "формат" командной строки:

gbak -b [другие опции] <база>  <резервная копия> [-v -y <имя файла>] -user ... -pass ...

То есть, "что делаем", "с какими параметрами", "база и копия", "полный вывод лога", "пользователь и пароль".
Такой порядок в левой части, где концентрируется внимание, содержит ключевую информацию, а правая часть - содержит вторичную информацию. Разумеется, вы можете выбрать иной порядок следования параметров gbak, но далее в статье я буду придерживаться указанного порядка.

Если вы хотите потренироваться по мере чтения статьи, то я рекомендую вам взять employee.fdb (или employee.gdb) из папки установки Firebird (InterBase), и скопировать эту базу в каталог bin, рядом с gbak. Затем открыть окно консоли, и перейти в каталог bin. Предварительно, чтобы не мучиться со вводом, рекомендую employee.fdb переименовать в e.fdb.

Итак, выполняем командную строку:

gbak -b e.fdb e.fbk

Что-то произошло, т.к. на диске образовался e.fbk, но никаких сообщений выдано не было. gbak в таком режиме выводит только сообщения об ошибках, если таковые возникли. Впрочем, для систем с регулярным резервным копированием, а также когда backup выполняется долго, лучше сразу указать опцию полного вывода лога действий. Даже в случае появления ошибки контекст этой ошибки будет виден четче, и также будет видно что именно сервер успел поместить в резервную копию до ошибки. Повторяем команду с ключом -v:

gbak -b e.fdb e.fbk -v

теперь видно, что делает gbak при -b. Правда, по умолчанию размер буфера консоли небольшой, и вы увидите только финальную часть лога. Чтобы лог можно было посмотреть полностью, придется еще раз повторить команду, только теперь уже с перенаправлением лога в файл:

gbak -b e.fdb e.fbk -v -y e_bak.txt

Теперь опять на экран ничего не выводится, зато можно посмотреть e_bak.txt и изучить его. Предоставляю вам сделать это самостоятельно. Кстати, если вы попытаетесь еще раз повторить такую же командную строку, то gbak выдаст ошибку.

Помните: gbak при создании резервной копии уничтожит файл с таким же именем. Однако для ключа -y при указании вывода файла лога этот файл не перезаписывается.

Замечание: параметр -v в справке, выдаваемой gbak, описан как -v[erify]. Это неверно, потому что опция gbak -v не имеет ничего общего с проверкой БД. Скорее, этот параметр должен расшифровываться как "verbose".

Имена файлов

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

Имя базы

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

e.fdb

надо было бы писать

server:c:\Firebird\bin\e.fdb

то есть штатную строку коннекта с указанием сервера и пути к БД (или алиаса, если таковой сконфигурирован в aliases.conf для Firebird 1.5 и выше, или admin.ib для InterBase 7.x и выше). В нашем примере вместо server надо указать или имя вашего компьютера, или localhost, поскольку мы все делаем на одном компьютере.

Разумеется, gbak создавая резервную копию, будет создавать ее локально, т.е. на компьютере где находится gbak. И если сервер - это другой компьютер, то фактически вся база данных будет считана по сети. Не стоит делать резервные копии баз размером гигабайт и выше например через 100мбит сеть. Быстрее будет сделать резервную копию на сервере, а затем просто скопировать ее файл на другой компьютер (если это нужно).

Имя резервной копии

Абсолютно любое, включая любое расширение. Вы можете встретить bak, gbk, fbk, и так далее. Никаких ограничений в этом плане не накладывается. Имя резервной копии лучше формировать как имя базы и дату, причем дату лучше всего указывать в "японском" формате, в виде YYYYMMDD - так имена файлов будут корректно сортироваться при просмотре папки.

Существует возможность делать многофайловый бэкап, разбивая бэкап на части. Однако, такая функциональность была нужна когда были распространены файловые системы, не поддерживавшие файлы более 2-4 гигабайт, а также когда InterBase не поддерживал как базы так и бэкапы более 4-х гигабайт. В настоящее время нет никакого смысла создавать как многофайловые бэкапы, так и многофайловые базы данных, поэтому данная функциональность в этой статье не описана.

Имя файла лога

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

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

Вот перечень опций командной строки gbak, которые используются при создании резервных копий БД:
(в квадратных скобках указаны символы, которые можно не указывать в командной строке)

Опция Назначение
-b[ackup_database] создать резервную копию
-g[arbage_collect] отключить сборку мусора
-co[nvert] конвертировать external table во внутренние таблицы БД
-ig[nore] при работе с поврежденной БД
-L[imbo] игнорировать изменения "застрявших" транзакций 2PC (указана прописная буква L, потому что в большинстве шрифтов на экране строчная буква l похожа на 1. Вы можете использовать строчный вариант)
-m[etadata] сохранить только метаданные (без данных)
-t[ransportable] для переноса БД между разными аппаратными платформами (по умолчанию)
-nt формат резервной копии, непереносимой между аппаратными платформами
-v вывод полного лога процесса backup.
-y <файл> сохранить вывод лога в файл
-user <имя> имя пользователя, SYSDBA или владелец БД
-pas[sword] пароль SYSDBA или владельца БД. опция может быть сокращена до -pass
-e[xpand] отключение сжатия данных при backup. По умолчанию резервная копия записывается в "сжатом" виде.
-ol[d_descriptions] для совместимости с InterBase 3.3, атавизм
-fa[ctor] n для ленточных устройств. атавизм
-z вывод версии сервера и gbak
Новые опции Firebird 2.1
-nodbtriggers отключает срабатывание триггеров уровня базы данных. эту опцию может указать только SYSDBA или владелец БД
Новые опции InterBase 2007
-d создать online dump (инкрементный бэкап). Подробнее см. Update Guide
Новые опции InterBase 2009
-encrypt шифровать базу с существующим в базе ключом шифрования. 
Подробнее читайте Data Definituin Guide, раздел Encrypting backup files.
-sep указание System Encryption Password

Подробное описание каждого параметра:

-g

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

gbak -b -g ... 

Если вы делаете бэкап в IBExpert, то включение опции -g производится отключением (!) галки на параметре Garbage collection (или Включить сборку мусора). Почему так сделано - не очень понятно, но такое "обратное" поведение присутствует во многих инструментах, аналогичных IBExpert-у. Возможно так случилось потому, что сам параметр командной строки называется -garbage_collect, в то же время он наоборот, не включает, а отключает сборку мусора в коннекте gbak.

примечание: разумеется, при backup никакой "мусор" никогда не попадает в файл backup, ни при каких условиях. Если это не очевидно, то прочитайте еще раз, что делает утилита gbak при backup. Если и там вы не увидели объяснения, то это значит, что вы не понимаете как сервер работает с транзакциями.

-t

Этот параметр можно часто увидеть в командных строках бэкапа, приводимых или цитируемых на различных форумах. На самом деле этот параметр действует по умолчанию, поэтому указывать его нет никакой необходимости.
transportable в данном случае означает, что полученный файл резервной копии можно восстановить на альтернативной аппаратной платформе, где порядок байт в целых числах отличается. То есть, например, между Intel и Sparc, или HP-UX и Intel, и так далее. Но между Windows и Linux (или другой ОС) на Intel файл резервной копии будет и так переносимым, даже при указании ключа -nt (non-transportable). Так что, про -t, как и про -nt можно забыть, и никогда не указывать их в командной строке gbak.

-e

InterBase был создан примерно в 1985-86 годах, а тогда жесткие диски были очень малого объема. Поэтому по умолчанию gbak -b производит некую легкую компрессию данных. Отключить ее можно параметром -expand. Я сделал тест бэкапа базы 2.6 гигабайт, и обнаружил, что вместо обычного 2.2 гигабайта (база только что после restore, поэтому разница между размером БД и бэкапом невелика, обычно она больше) файл резервной копии с параметром -expand стал 5.2 гигабайта. Провел еще тесты, с резервным копированием на другой диск. Получил ускорение с -expand на 5%. Визуально процессор загружен на те же самые 34-38%, что и без ключа -e. На restore, скорее всего, разницы вообще не будет заметно. Так что практическую полезность параметра -expand, учитывая сильное увеличение размера резервной копии, можно считать равной нулю.

-co

Если в базе данных созданы внешние таблицы (external tables), то при создании резервной копии они будут помещены внутрь бэкапа как обычные таблицы. Без параметра -co внешние таблицы в резервную копию не попадают.
Можно сказать, что -co нужен тогда, когда вам требуется для эксперимента "взять с собой" не только базу, но и внешние файлы. Правда, в зависимости от назначения эти файлы могут иметь разный размер, и может оказаться, что сами они будут больше чем база данных. Для обычного, регулярного backup, параметр -co не нужен.

-factor

В документации этот параметр указан как "uses blocking factor n for tape device". Что это такое - уже неизвестно, т.к. в документации по нынешним версиям InterBase описания этого параметра нет, да и на ленту уже мало кто делает резервные копии (разве что копии дисков целиком).

-ig

До InterBase 5 сервер использовал вычисление контрольных сумм страниц БД. С InterBase 5 эта функциональность была отключена, поскольку диски сами научились восстанавливать поврежденные блоки по контрольным суммам, и поврежденный блок либо восстанавливается автоматически и незаметно, либо не может быть восстановлен вообще.
Сейчас InterBase и Firebird вместо контрольной суммы записывают на страницу число "12345". Если произошло повреждение базы данных, и данные на страницах БД искажены (нули или другая произвольная информация), то сервер при чтении такой страницы будет выдавать ошибку контрольной суммы.
Параметр -ig позволяет игнорировать ошибки контрольных сумм страниц, и не останавливать резервное копирование из-за этих ошибок.

Поэтому, в обычной командной строке для создания резервной копии БД категорически не рекомендуется указывать параметр -ig! Если база данных вдруг окажется повреждена, то с этим параметром вы можете "не увидеть" повреждение. Так что, -ig для gbak используется только в крайнем случае - когда поврежденная база починена утилитой gfix, но обычный backup не проходит. Только тогда имеет смысл повторить бэкап с опцией -ig.

-m

Сохраняет только метаданные (описания таблиц, процедуры, триггеры и т.д.). Данные в резервную копию не сохраняются. Используется когда вам нужно сделать копию пустой БД.
Однако, при этом могут не сохраняться значения генераторов. В последних версиях Firebird и InterBase это исправлено, но если нет - при восстановлении такой копии вы можете получить "мусор" в значениях генераторов (не 0, а случайные значения). Проверьте вашу версию Firebird или InterBase на наличие или отсутствие данного бага.

-limbo

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

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

-y файл

Выше уже были приведены примеры перенаправления вывода в файл этой командой, однако, если просто в окне cmd (Windows) эта команда работает нормально, то при ее использовании в bat/cmd командном файле ошибки могут не сохраняться в файл, указанный в опции -y. Вы можете отказаться от этой опции, используя перенаправление вывода самостоятельно, в соответствии с документом
http://technet.microsoft.com/ru-ru/library/bb490982(en-us).aspx

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

В InterBase 2007 введена возможность создания резервных копий, аналогичная nbackup в Firebird 2. В то время как nbackup является в Firebird отдельной утилитой, функции, похожие на nbackup, в InterBase выполняет gbak. Вот краткое описание новых опций

gbak -d
выполнить онлайн-дамп базы данных в файл . Результатом будет копия базы данных в файле . Эта база по умолчанию находится в состоянии read-only. Если уже существует, то в него будут перенесены изменения, произошедшие в базе данных с момента предыдущей операции дампа (gbak -d)

gbak -d -ov ... 
перезаписать целиком, если он существует.

Подробнее о других опциях gbak (-archive_journals, -archive_database, -archive_recover, -archive_dumps) и новых функциях InterBase 2007 читайте в документе.

Services API - backup

По умолчанию gbak "прокачивает" данные через себя, как изображено на картинке.

Однако, в InterBase 6 было "опубликовано" Services API для выполнения сервером по команде действий, аналогичных выполняемым утилитами командной строки gbak, gfix, gsec. "Опубликовано" потому, что это API присутствовало в InterBase 5, но было секретным, и никак не использовалось программами, сопровождающими IB.

примечание: Services API - это например закладка компонент InterBase Admin в Delphi (компонент IBBackupService, например), компоненты pF...Service в FIBPlus (pFIBBackupService), также, IBExpert выполняет backup/restore только при помощи Services API, и т.д. Грубо говоря, если приложение не вызывает gbak.exe, но может делать backup, restore, и другие подобные "серверные" действия, значит оно использует Services API. И gbak.exe тоже использует Services API, если указана опция -se (см. далее).

Теперь (c 2000 года, с момента выхода InterBase 6.0) InterBase и Firebird могут делать так:

gbak или программа, использующая Services API, отправляет серверу команду, а сервер ее выполняет сам. В этом случае программа, отдавшая команду, может получать лог выполнения от сервера и выдавать все что сообщит о процессе сервер.

Пример:

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

-se

Это и есть команда серверу, чтобы не gbak, а сам сервер выполнил резервное копирование.

server - имя компьютера, где находится сервер InterBase или Firebird (если на этом же, то можно указать localhost). server можно не указывать, если сервер "локальный", и работает локальный протокол:

gbak -b -g -se service_mgr c:\db\e.fdb d:\bak\e.fbk ...

:service_mgr - имя интерфейса Services API, оно обязательно, неизменно, и пока только одно. Может быть в дальнейшем появится что-то еще, но пока есть только то что есть.

Поскольку не gbak, а сам сервер теперь выполняет резервное копирование, то есть несколько требований:

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

К слову, резервное копирование через Services API является самым быстрым, по сравнению с локальным протоколом или tcp (результаты тестирования).

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

Резервное копирование - "онлайновая" операция, т.е. может быть выполнена в любой момент, во время работы пользователей с БД. Эту операцию можно и нужно автоматизировать, сделав резервное копирование регулярным. Без резервных копий вы рискуете остаться ни с чем, если база данных окажется повреждена по какой-либо причине.
Отсюда же следует, что категорически нельзя делать резервные копии на тот же самый логический диск, где находится база данных. Еще лучше делать резервные копии на другой физический диск, поскольку чтение и запись будут разделены, и это даст как минимум 30% ускорение процесса резервного копирования.

Восстановление базы данных из резервной копии - restore

Операция, обратная резервному копированию.

gbak -c e.fbk e.fdb

База e.fdb будет восстановлена из резервной копии e.fbk. Процесс восстановления базы данных из резервной копии происходит следующим образом:

  1. сервер создает пустую базу данных e.fdb. Причем, создает ее в том формате баз данных, который является для него "родным". Пустая база данных будет содержать все таблицы rdb$ (пока пустые), и будет иметь ряд параметров, например такие как размер страницы, forced write и т.д., которые или взяты из резервной копии, или установлены в командной строке gbak.
  2. сервер считывает метаданные (описания таблиц и индексов, процедур) из резервной копии и переносит их в базу данных.
  3. сервер считывает данные из резервной копии и переносит их в базу данных
  4. сервер считывает остальные метаданные (триггеры, гранты, check constraints и т.п.) из резервной копии и переносит их в базу данных
  5. сервер создает (активирует) все индексы таблиц (которые были активны в момент создания резервной копии)

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

Помните, что если вы делаете восстановление на новой версии сервера, например, резервную копию делали на Firebird 1.5 (формат БД ODS 10.1), а восстанавливаете на Firebird 2.1 (формат БД ODS 11.1), то база будет создана в формате, поддерживаемом по умолчанию Firebird 2.1, и Firebird 1.5 с этой базой работать не сможет.

Резервные копии, кстати, тоже имеют свой формат, и резервная копия БД, сделанная например в Firebird 2.1 утилитой gbak этой же версии, не может быть восстановлена утилитой gbak от Firebird 1.5. Подробнее варианты переноса резервных копий и баз между версиями серверов описаны в документе.

примечание: если вас интересует точная последовательность действий gbak при backup и restore, например, порядок сохранения и восстановления объектов метаданных, то вы можете обратиться к исходным текстам - backup.epp и restore.epp соответственно. По мере развития IB/FB и исправления ошибок порядок сохранения-восстановления некоторых объектов изменялся (например, udf стали идти в бэкапе "раньше" некоторых других объектов).

примечание: существует возможность при восстановлении создать многофайловую базу данных. Однако, такая функциональность была нужна когда были распространены файловые системы, не поддерживавшие файлы более 2-4 гигабайт, а также когда InterBase не поддерживал как базы так и бэкапы более 4-х гигабайт. В настоящее время нет никакого смысла создавать как многофайловые бэкапы, так и многофайловые базы данных, поэтому подобная функциональность в данной статье не описана.

English  Русский 
Валюта:
(пусто)
 
Блог / Новости
Flag Counter
Империалъ, Ооо