Nbackup, воспросы и ответы

Gallemar
Дата: 06.06.2012 12:11:06
Добрый день
Собираюсь реализовать инкрементный бэкап с помощью nbackup для уменьшения времени простоя рабочего процесса в случае выхода из строя сервера/базы/т.п. Раз в сутки делается бэкап с помощью gbak, но т.к. база достаточно велика по объему (>150Гб) restore длиться 8 часов,что нам не подходит. Схема инкрементального бэкапа такая: раз в сутки запускается nbackup с ключом -B 0 для снятия полной копии базы, файл *.nbk скидывается на другой ресурс для сохранности,раз в 2 часа запускается с ключом -B 1 для снятия данных за прошедшее время с последнего полного бэкапа. Такой момент: т.к. при бэкапе с помощью nbackup файл базы временно блокируется и все изменения пишутся в delta, чем будет грозить выключение сервера/отключение сети во время бэкапа и как исправлять последствия? Как я понял простейший выход - разблокировать файл базы ключом -F и продолжить работу удалив delta. Для того чтобы *.nbk не валились в одну кучу как их можно разделить по дате-времени создания и уровню (0-1-2)?
Таблоид
Дата: 06.06.2012 12:30:49
Gallemar,

на таком размере базы (150 гигабайт) давно пора смотреть в сторону shadow-копии (синхронное обновление всех страниц базы-копии сервером) и репликации.
shadow всем хороша: время восстановления минимально (при аварии снять с .shd признак "тень" и переключить юзеров на тот сервер, где она лежит). Но если в основной базе какие-то страницы повреждены, они также будут поломаны в shadow. Заблаговременно узнать об этом вы сможете, только проводя валидацию и реагируя на её лог. Механизм shadow - встроенный в ФБ.
Репликация - не синхронная, т.е. данные переносятся с задержкой (от 10 сек до нескольких минут). Кроме того, изменения в метаданных, а также значения генераторов, автоматически не переносятся, требуются некоторые действия. Но зато репликатор пишет в базу-приёмник в гордом одиночестве и просто никак не сможет её поломать. Встроенного механизма репликации в ФБ нет, но есть качественный продукт, который по силам купить любой конторе (я не рекламирую его; просто мы его юзаем во всю дурь, а его разработчик обеспечивает адекватную поддержку :))

Что касается nbackup'a, то на сегодняшний день создание копии любого уровня требует просмотра ВСЕЙ базы, а не только лишь изменённых страниц. Сами понимаете, что это лишняя нагрузка на сервер и трата просто времени. Вы не будете иметь нужной актуальности данных при таком размере базы. С другой стороны, nbackup полезен для валидации базы без отключки юзеров: залочили (nbackup -L) -> скопировали базу командой cp (copy) -> разлочили (nbackup -N) -> проверили полученную копию через gfix.

ЗЫ. Вопросы использования shadow и репликации можно найти тут, на форуме.
Gallemar
Дата: 06.06.2012 12:42:58
Таблоид, мы уже рассматривали вариант с IBReplicator, он нам не подходит по ряду причин. Так что тема с nbackup для нас очень актуальна.
Dimitry Sibiryakov
Дата: 06.06.2012 12:54:12

Gallemar
он нам не подходит по ряду причин

"Огласите весь список, пжлста!" (с)

Posted via ActualForum NNTP Server 1.5

Таблоид
Дата: 06.06.2012 13:05:04
Gallemar
чем будет грозить выключение сервера/отключение сети во время бэкапа<...> ?
При FW = ON не должно быть последствий. Но - не верьте на слово, проверяйте! ставьте эксперименты (как в начале, так и в середине .nbk отправьте машину в рестарт).
Gallemar
Для того чтобы *.nbk не валились в одну кучу как их можно разделить по дате-времени создания и уровню (0-1-2)?
<...>
тема с nbackup для нас очень актуальна.
Время к файлу .nbk прилепить ?
Вот, возьмите за основу, подрихтуйте под себя:
-- file: fbkstamp.bat
@echo off
if .%1.==.. goto syntax
for /f "TOKENS=2-4 DELIMS=. " %%I IN ("%date%") DO SET cdate=%%K%%J%%I
for /f "TOKENS=1-3 DELIMS=:. " %%I IN ("%time%") DO SET ctime=%%I%%J%%K
gbak -b %1 %~n1_%cdate%_%ctime%.fbk -user sysdba -pas masterke
goto end
:syntax
echo.
echo Usage: %0 db_to_backup.fdb
echo.
echo file db_to_backup_YYYYMMDD_hhmiss.fbk will be created.
pause
exit
:end


Sample:
fbkstamp.bat t1.fdb ==> получаем t1_20120425_182116.fbk
(взято отсюда, там еще есть варианты).
И вот еще интересный топик, почитайте.
hvlad
Дата: 06.06.2012 13:16:12
Gallemar
Такой момент: т.к. при бэкапе с помощью nbackup файл базы временно блокируется и все изменения пишутся в delta, чем будет грозить выключение сервера/отключение сети во время бэкапа
Тем же самым как и не во время бекапа. Причём тут отключение сети - я вообще не понял.

После запуска нового экземпляра сервера состояние БД будет тем же, что и во время его выключения:
- если было stalled (т.е. бекап не завершился и команды ALTER DATABASE END BACKUP не было), то останется stalled.

- если было merge (т.е. бекап завершился и ALTER DATABASE END BACKUP была выполнена), то первый подключившийся процесс продолжит merge вплоть до его завершения.

Gallemar
и как исправлять последствия ?
Если состояние stalled, то nbackup -N (или, что тоже самое, вручную выполнить ALTER DATABASE END BACKUP).
Если merge - ничего делать не нужно.

Gallemar
Как я понял простейший выход - разблокировать файл базы ключом -F и продолжить работу удалив delta
Это способ убить все изменения с момента начала бекапа. Читай документацию внимательно

Gallemar
Для того чтобы *.nbk не валились в одну кучу как их можно разделить по дате-времени создания и уровню (0-1-2)?
Я не понял - это вопрос о том, как задать имена файлам ?

PS nbackup лучше использовать с Firebird 2.5
Gallemar
Дата: 07.06.2012 05:33:56
hvlad,
Gallemar
Для того чтобы *.nbk не валились в одну кучу как их можно разделить по дате-времени создания и уровню (0-1-2)?
Я не понял - это вопрос о том, как задать имена файлам ?

Да,мне нужно разделение по дате/времени и уровню бэкапа.
Gallemar
Дата: 07.06.2012 06:59:46
hvlad,вопрос с отключением сети - я планирую сбрасывать *.тил сразу на сетевой ресурс для страховки от физической смерти сервера БД. Поэтому интересно что будет если во время бэкапа ресурсна который идет запись *.nbk станет недоступен?
Dimitry Sibiryakov
Дата: 07.06.2012 11:56:52

Судя по тому, что мой вопрос проигнорирован, "ряд причин" традиционно содержит ровно одну
строчку: "не смогли найти кейген". Ню-ню...

Posted via ActualForum NNTP Server 1.5

Alexey Kovyazin
Дата: 07.06.2012 14:45:58
>shadow всем хороша: время восстановления минимально (при аварии снять с .shd признак "тень" и переключить юзеров на тот сервер, где она лежит).

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

>Но если в основной базе какие-то страницы повреждены, они также будут поломаны в shadow.

Топикстартеру - всяческих удач в изобретении велосипеда.
В конце концов, потерять 150Гб данных в условиях кризиса не так страшно - одной компанией меньше, никто не обратит внимания :)

C уважением,
Алексей Ковязин
http://ibase.ru/techsupp.htm