Создание резервных копий и восстановление из них

Резервная копия всей базы данных
Инкрементные резервные копии
Практическое применение
Читать ли дальше?

Для начала, nbackup.exe находится в подпапке bin папки, куда установлена СУБД Firebird. Например, типичным расположением является C:\Program Files\Firebird\Firebird_2_0\bin (Windows) или /opt/firebird/bin (Linux). Как и у большинства утилит, распространяемых с СУБД Firebird, у nbackup нет графического интерфейса; Вы запускаете программу из командной строки (или из командного файла, или из другой программы).

Резервная копия всей базы данных

Содание резервной копии всей базы данных

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

nbackup [-U <пользователь> -P <пароль>]
        -B 0 <база_данных> [<резервный_файл>]

Например:

C:\Databases> nbackup -B 0 inventory.fdb inventory_1-Mar-2006.nbk

Примечания:

Параметр -B означает создание резервной копии. Уровень резервной копии 0 означает создание резервной копии всей базы данных. Уровни резервных копий больше 0 используются для создания инкрементных резервных копий; это будет рассмотрено далее.
Вместо имени файла базы данных Вы можете указать псевдоним (alias, из файла aliases.conf).
Вместо имени файла резервной копии Вы также можете указать stdout. Это перенаправит резервную копию в стандартный поток вывода, откуда Вы сможете перенаправить ее, например, на ленточный накопитель или на вход утилиты для сжатия получаемой резервной копии.
Параметры -U (user, имя пользователя) и -P (password, пароль) могут быть опущены (не указываться):
- если Вы зарегистрированы в системе как администратор (root, Administrator...), или
- если установлены переменные окружения ISC_USER и ISC_PASSWORD.
Для понятности и краткости эти параметры не указаны в приводимых примерах.
Все параметры (-B, -U и -P) можно указывать в произвольном порядке. Естественно, за каждым параметром должен(ны) следовать его аргумент(ы). В случае с параметром -B есть три аргумента: уровень резервной копии, база данных и файл резервной копии - в этом порядке!
Если параметр -B указан последним, Вы можете не указывать имя файла резервной копии. В этом случае, nbackup построит имя файла на основе имени базы данных, уровне резервной копии и текущем дате и времени. Это может привести к коллизии имен файлов (и неудавшемуся резервному копированию), если две команды резервирования одного уровня вызываются в одну и ту же минуту.

Внимание

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

Несколько слов о внутренних механизмах

На заметку: то, что здесь будет описано, не является необходимыми знаниями для использования nbackup. Это описание дает грубое представление о том, что происходит при работе программы nbackup с параметром -B:

Прежде всего, основной файл базы данных блокируется установкой внутреннего флага состояния. С этого момента абсолютно все изменения в базе данных записываются во временный файл, называемый файлом разницы (difference file) или файлом дельты.
После этого создается резервная копия. Это не обычная копия файла базы данных - восстановление из полученной копии необходимо производить также при помощи nbackup.
По завершении резервирования содержимое файла дельты объединяется с основным файлом базы данных. После этого база данных разблокируется (флаг возвращается в «нормальное» состояние) и файл дельты удаляется.

Функциональность шагов 1 и 3 достигается введением двух новых операторов SQL: ALTER DATABASE BEGIN BACKUP и ALTER DATABASE END BACKUP. Вразрез с указанным в операторах, они не ведут к созданию резервной копии, они лишь создают условия, с которыми можно безопасно создать резервную копию основного файла базы данных. Чтобы прояснить: Вам не нужно употреблять указанные операторы самостоятельно и явно; nbackup сделает это за Вас в нужное время.

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

Резервная копия всей базы данных восстанавливается следующим образом (перенос на следующую строку сделан исключительно из эстетических соображений):

nbackup [-U <пользователь> -P <пароль>]
        -R <база_данных> [<резервный_файл>]

Например:

C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk

Примечания:

Вам не нужно указывать уровень при восстановлении.
При восстановлении параметр -R должен быть указан последним по причинам, которые будут описаны позже.
Если указанная база данных уже существует и нет активных соединений, она будет перезаписана без предупреждения! Если есть активные соединения, восстановление не состоится и Вы получите сообщение об ошибке.
Здесь также Вы можете не указывать имя файла резервной копии. Если Вы его опустите, nbackup спросит Вас об этом позже. Однако на текущий момент разработки СУБД Firebird 2 (стадия alpha 3) это приведет к ошибке (по крайней мере под Windows) и неудавшемуся восстановлению.

Инкрементные резервные копии

Создание инкрементных резервных копий

Для создания инкрементной («дифференциальной») резервной копии необходимо указать уровень резервной копии больше 0. Инкрементная резервная копия уровня N содержит изменения базы данных с момента создания последней резервной копии уровня N-1.

Примеры:

Через день после создания резервной копии всей базы данных (уровня 0) Вы создаете резервную копию уровня 1:

C:\Databases> nbackup -B 1 inventory.fdb inventory_2-Mar-2006.nbk

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

Через день Вы вновь решили сделать резервную копию уровня 1:

C:\Databases> nbackup -B 1 inventory.fdb inventory_3-Mar-2006.nbk

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

Через пару часов Вы создаете резервную копию уровня 2:

C:\Databases> nbackup -B 2 inventory.fdb inventory_3-Mar-2006_2.nbk

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

Замечание

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

Внимание

Еще раз: не используйте nbackup для многофайловых баз данных.

Восстановление из инкрементных резервных копий

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

Формальный синтаксис:

nbackup [-U <пользователь> -P <пароль>]
        -R <база_данных> [<резервная_копия0>
        [<резервная_копия1> [...] ] ]

Таким образом, восстановление для предыдущего примера до уровня 2 будет выглядеть так:

C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk
                inventory_3-Mar-2006.nbk inventory_3-Mar-2006_2.nbk

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

Примечания (дополнительно к примечаниям по восстановлению из резервной копии всей базы данных):

Так как программа не может знать заранее количество указанных после параметра -R имен файлов (уровень при восстановлении не указывается), nbackup считает все аргументы после параметра -R именами файлов с резервными копиями. По этой причине никакие другие параметры (-U или -P) не могут следовать за списком файлов параметра -R.
Не существует формального ограничения на уровень резервной копии, однако на практике редко имеет смысл создавать копии уровней больше 3 или 4.

Несвязанные ссылки

Что произойдет, если Вы нечаяно пропустите файл с инкрементной резервной копией в цепочке восстановления, или укажете набор файлов, которые не являются одной цепочкой? Представьте, что Вы по ошибке указали inventory_2-Mar-2006.nbk вместо inventory_3-Mar-2006.nbk в вышеприведенном примере. Обе резервные копии являются копиями уровня 1, поэтому в обоих случаях у Вас получится замечательная последовательность уровней «0, 1, 2». Но файл уровня 2 является инкрементной резервной копией для инкрементной резервной копии уровня 1 от 3 марта, а не от 2 марта.

К счастью, такие ошибки никогда не приведут к неверно восстановленной базе данных. Каждый файл с резервной копией имеет уникальный идентификатор. Более того, каждый резервный файл уровня 1 и выше содержит идентификатор того файла, на котором он основан. При восстановлении nbackup проверяет эти идентификаторы; если где-то в указаной цепочке обнаруживается неверная ссылка, операция восстановления не производится и Вы получите сообщение об ошибке.

Практическое применение

Основанная на nbackup инкрементная схема резервирования может выглядеть следующим образом:

Каждый месяц создается резервная копия всей базы данных (уровня 0);
Каждую неделю делается инкрементная резервная копия уровня 1;
Каждые сутки создается инкрементная резервная копия уровня 2;
Каждый час создается инкрементная резервная копия уровня 3.

Поскольку все резервные копии сохраняются, Вы сможете восстановить базу данных в любое состояние с точностью до часа. При каждом восстановлении используется максиум до четырех резервных файлов. Разумеется, Вам необходимо так планировать процесс создания резервных копий, что наибольшие из них (требующие больше времени) создаются во время наименьшей нагрузки на СУБД со стороны пользователей. В указанной схеме уровни 0 и 1 могут создаваться по выходным, а уровень 2 - в ночное время.

Если Вы не хотите хранить все созданные резервные копии, Вы можете спланировать схему удаления ненужных копий:

Резервный копии уровня 3 удаляются после 8 дней хранения с момента создания;
Резервные копии уровня 2 - после месяца;
Резервные копии уровня 1 - после полугода;
Резервные копии уровня 0 (всей базы данных) - после двух лет, но первую резервную копию всей базы данных каждого года нужно сохранить.

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

Читать ли дальше?

Сейчас Вы знаете все, что нужно, для того, чтобы создавать резервные копии базы данных и производить восстановление базы данных из резервных копий с помощью nbackup. Если Вы хотите использовать другие утилиты для создания резервных копий баз данных Firebird, то читайте следующие разделы.

Если у Вас нет желания вникать в тонкости, удачи Вам в обычной работе с nbackup!