Бекап интербейс
не помню где нарыл инфу но расписано толково (гугл рулит).
О том, что периодическая процедура резервирования и последующего восстановления данных положительно сказывается на размере и производительности базы данных Interbase/Firebird написано во многих FAQ. Совершенно с этим согласен. Попробую рассказать, как этот процесс организован у меня.
В данное время я являюсь администратором небольшой базы (примерно 300Mb), которая довольно активно используется (примерно 1 миллион транзакций в день). При этом цикл backup/restore производятся ежедневно. Последние пару лет серьезных сбоев и поломок базы не наблюдалось.
Для автоматического резервирования и восстановления написан bat-файл. Используется утилита командной строки gbak и пару программок собственной разработки.
Обычно при backup/restore базы требуется выполнить следующие действия:
- Отключить всех пользователей от базы;
- Если все отключены запустить процедуру бэкапа в файл BACKUP.GBK;
- Если бэкап прошел, то запустить процедуру восстановления BACKUP.GBK в новый файл базы NEW.GDB;
- Если восстановление успешно, переименовать файл рабочей базы WORK.GDB в OLD.GDB;
- Если переименование успешно, то переименовать новый файл NEW.GDB в WORK.GDB;
- Скопировать BACKUP.GBK на другой диск, а лучше на другой компьютер, добавив в имя файла дату и время бэкапа.
Теперь подробнее по шагам.
Шаг 1. Выгнать пользователей из базы можно по хорошему, закрыв все программы работающие с базой. Чтобы узнать есть ли подключенные пользователи и кто они, я написал утилиту IbCheck.exe. Пример вызова:
IbCheck <WORK.GDB> <USER_IB> <PASSWORD_IB>
if errorlevel 1 goto exit1
параметры:
- WORK.GDB - полный путь к рабочей базе данных;
- USER_IB - имя пользователя Interbase/Firebird, обычно это SYSDBA или создатель базы;
- PASSWORD_IB - пароль пользователя.
Утилита возвращает код 0 при отсутствии соединений к базе, или код 2 и список подключенных пользователей.
Или по плохому, отрубив оставшиеся соединения командой
gfix -shut –force 10 -user <USER_IB> -pass <PASSWORD_IB> <WORK.GDB>
if errorlevel 1 goto exit1
ключи:
- -shut -force - форсированный режим отключения;
- 10 - ждем 10 секунд отключения пользователей, потом отрубаем.
При этом я сталкивался с такой проблемой. Иногда при принудительном отрубании пользователей Windows не давала возможность переименовать файл рабочей базы на шаге 4. Приходилось останавливать и перезапускать Interbase, чтобы "освободить" файл.
Шаг 2. Бэкапим базу WORK.GDB в файл BACKUP.GBK
gbak -b -user <USER_IB> -pass <PASSWORD_IB> -v -g <WORK.GDB> <BACKUP.GBK>
if errorlevel 1 goto exit2
ключи:
- -b - делать бэкап;
- -g - не собирать мусор, очень полезный ключ может значительно сократить время бэкапа;
- -v - выводить лог операций, ну просто приятно когда надписи бегут по экрану
.
Шаг 3. Восстанавливаем базу в файл NEW.GDB
gbak -r -user <USER_IB> -pass <PASSWORD_IB> -v <BACKUP.GBK> <NEW.GDB>
if errorlevel 1 goto exit3
ключи:
- -r - восстанавливаем базу;
- -v - выводить лог операций.
Шаг 4. Переименовываем рабочую WORK.GDB базу в OLD.GDB. Не забываем сначала удалить OLD.GDB, этот файл остался с прошлого бэкапа!
del <OLD.GDB>
ren <WORK.GDB> <OLD.GDB>
if errorlevel 1 goto exit4
Шаг 5. Переименовываем только что восстановленную базу NEW.GDB в WORK.GDB
ren <NEW.GDB> <WORK.GDB>
if errorlevel 1 goto exit5
Шаг 6. Основная работа сделана, теперь надо скопировать бэкап файл на другой физический диск, а лучше на другой компьютер. Еще, хорошо бы хранить не только последнюю копию базы, а все копии за последнюю неделю, месяц, год… сколько позволяет размер винчестера. Но для этого, как минимум, названия бэкап файлов должны содержать дату и возможно время создания. Для этих целей я использую утилиту InsDatew.exe. В качестве параметра ей требуется передать имя пакетного bat-файла. Это файл будет выполнен, а в окружении будут созданы переменные с номером года, месяца, дня и т. д. Внутри самого скрипта это можно использовать так:
Copy <BACKUP.GBK> <COPY_PATH>%_YEAR%_%_MONTH%_%_DAY%.GBK
Создаст копию файла под именем YYYY_MM_DD.GBK в каталоге <COPY_PATH>