Firebird восстановление базы из бэкапа

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

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

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

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

Параметр -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 сделает это за Вас в нужное время.

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

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

Вам не нужно указывать уровень при восстановлении.

При восстановлении параметр -R должен быть указан последним по причинам, которые будут описаны позже.

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

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

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

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

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

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

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

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

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

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

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

Замечание

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

Внимание

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

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

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

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

Перенос на новую строку сделан здесь исключительно из эстетических соображений — Вам необходимо вводить команду в командной строке полностью, и нажать 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 !

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Бэкап и восстановление базы Interbase/Firebird

О том, что периодическая процедура резервирования и последующего восстановления данных положительно сказывается на размере и производительности базы данных Interbase/Firebird написано во многих FAQ. Совершенно с этим согласен. Попробую рассказать, как этот процесс организован у меня.

В данное время я являюсь администратором небольшой базы (примерно 300Mb), которая довольно активно используется (примерно 1 миллион транзакций в день). При этом цикл backup/restore производятся ежедневно. Последние пару лет серьезных сбоев и поломок базы не наблюдалось.

Для автоматического резервирования и восстановления написан bat-файл. Используется утилита командной строки gbak и пару программок собственной разработки.

Обычно при backup/restore базы требуется выполнить следующие действия:

  1. Отключить всех пользователей от базы;
  2. Если все отключены запустить процедуру бэкапа в файл BACKUP.GBK;
  3. Если бэкап прошел, то запустить процедуру восстановления BACKUP.GBK в новый файл базы NEW.GDB;
  4. Если восстановление успешно, переименовать файл рабочей базы WORK.GDB в OLD.GDB;
  5. Если переименование успешно, то переименовать новый файл NEW.GDB в WORK.GDB;
  6. Скопировать BACKUP.GBK на другой диск, а лучше на другой компьютер, добавив в имя файла дату и время бэкапа.

Теперь подробнее по шагам.

Шаг 1. Выгнать пользователей из базы можно по хорошему, закрыв все программы работающие с базой. Чтобы узнать есть ли подключенные пользователи и кто они, я написал утилиту IbCheck.exe. Пример вызова:

if errorlevel 1 goto exit1

  • WORK.GDB — полный путь к рабочей базе данных;
  • USER_IB — имя пользователя Interbase/Firebird, обычно это SYSDBA или создатель базы;
  • PASSWORD_IB — пароль пользователя.

Или по плохому, отрубив оставшиеся соединения командой

if errorlevel 1 goto exit1

  • -shut -force — форсированный режим отключения;
  • 10 — ждем 10 секунд отключения пользователей, потом отрубаем.

Шаг 2. Бэкапим базу WORK.GDB в файл BACKUP.GBK

-v -g
if errorlevel 1 goto exit2

  • -b — делать бэкап;
  • -g — не собирать мусор, очень полезный ключ может значительно сократить время бэкапа;
  • -v — выводить лог операций, ну просто приятно когда надписи бегут по экрану .

Шаг 3. Восстанавливаем базу в файл NEW.GDB

-v
if errorlevel 1 goto exit3

Шаг 4. Переименовываем рабочую WORK.GDB базу в OLD.GDB. Не забываем сначала удалить OLD.GDB, этот файл остался с прошлого бэкапа!

Шаг 5. Переименовываем только что восстановленную базу NEW.GDB в WORK.GDB

Шаг 6. Основная работа сделана, теперь надо скопировать бэкап файл на другой физический диск, а лучше на другой компьютер. Еще, хорошо бы хранить не только последнюю копию базы, а все копии за последнюю неделю, месяц, год… сколько позволяет размер винчестера. Но для этого, как минимум, названия бэкап файлов должны содержать дату и возможно время создания. Для этих целей я использую утилиту InsDatew.exe. В качестве параметра ей требуется передать имя пакетного bat-файла. Это файл будет выполнен, а в окружении будут созданы переменные с номером года, месяца, дня и т. д. Внутри самого скрипта это можно использовать так:

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

Как видите все достаточно просто.

А в заключение предлагаю желающим bat-файл и утилиты с исходными текстами:

br.bat — bat-файл для автоматического backup/restore. Все названия баз, пути, пароли и т. д. настраиваются. Скрипт нужно запускать на той же машине, где находится база данных. Утилиты IbCheck и InsDatew лучше положить рядом с bat-файлом.
IbCheck — консольная утилита проверки подключенных пользователей (163K; с исходным кодом на Delphi).
InsDateW — консольная утилита вставки даты и времени в переменные окружения (28.2K; с исходным кодом на Delphi).

Copyright© 2005 Сергей Тулаев Специально для Delphi Plus

Беда пришла откуда не ждали… У клиента завис процесс “Касса”, так что не смог снять процесс через Диспетчер задач. Рабочее место “Касса” — одновременно сервер всей системы.

Клиент принял решение ресетнуть через кнопку.

В итоге умерла DB. FireBird 2.5

Backup’ы настроены не были, так что последняя версия БД, которая случайно лежала у меня на винте, была минус 8 дней. Подняли по-быстрому с неё. Но суть дальше.

Как делать бекапы для FireBird.

Я написал скрипт, который, когда его запускают, делает резервное копирование базы данных с именем БазаДаннах_30_05_2017_23_07_51.fbk

Это означает взять из результата date (это системная функция Windows), 2 символа, начиная с 3 позиции в строке. Обычный %date% = 31.05.2017

Означает брать время, учитывая 0, когда часы меньше 10, то есть без этой команды, мы при выполнении команд:

получили бы, что now=2017_05_31_ 0_44_33, а имя файла выглядело бы так: BackupPARKDB_2017_05_31_ 0_44_33.fbk. Пробел не сильно виден, но он неприемлем в названии файла для nbackup дата и время берутся из текущего времени системы. Это вроде рассказал 🙂 Далее, чтобы скрипт выполнялся постоянно, я добавил задачу в планировщик задач виндовс, он каждые 4 часа запускает мой скрипт и создается новая БД, далее я научился создавать задачи в планировщике задач через командную строку:

Детали параметров можете посмотреть в хелпе. SCHTASKS /Create /?

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

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

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

В итоге у нас каждые 4 часа есть бекап, и если мы делаем UnInstall, то всё чисто 🙂


[an error occurred while processing the directive]
Карта сайта