Hello, Vlad!
Vlad Horsun wrote:
читаю документацию по nbackup, и вижу именно это.
Цитату, плс
какую цитату, если там НЕТ такого? :-)
nbackup -f упоминается только в одном месте -
там где вызывается nbackup -l.
Да и вообще, собственно. Откуда в копии базы берется
это флаг, locked? А очень просто!!!
Nbackup БЛОКИРУЕТ базу, затем копирует ее,
а потом разблокирует. Вот поэтому nbackup 0-го уровня
и получается с флагом lock!
Я угадал? Понятно что это как-бы следует из механизма
работы nbackup. Но это же надо в доке написать.
Хочеш цитирования? пожалуйста:
"2. После этого создается резервная копия. Это не обычная копия файла
базы данных - восстановление из полученной копии необходимо производить
также при помощи nbackup."
и дальше
"Резервная копия всей базы данных восстанавливается следующим образом
(перенос на следующую строку сделан исключительно из эстетических
соображений):
Например:
C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk
"
вот сюда как раз можно было бы добавить, что если это копия
nbk, то нет никакой нужды производить такую операцию.
Достаточно переименовать файл и сделать nbackup -f.
unlock. Если я открою nbackup.nbk,
он ведь изменится. Это ж не readonly DB, так?
Что мешает сделать её ридонли ?
ничто. она и должна быть такая.
т.е. см. выше. nbackup после создания уровня
0 должен
1. убрать lock с дампа
2. поставить флаг readonly.
под "должен" я имею в виду, что так было бы
логично. и можно было бы к этому дампу коннектиться.
И можно эту базу использовать как готовую базу.
А не морочить людям голову :-)
Кстати. В IB 2007 делают более корректно:
добавляют в дампе в header page дату создания дампа.
для nbk дату его создания можно потерять.
т.е. nbackup-у все равно, лоченый "дамп" используется 1-го уровня, или
нет? А если я открою его, поменяю - и что тогда получится?
по идее, битая база.
Схожу не скажу, ибо не помню. Проверишь ?
да даже проверять не буду. Если nbackup при ресторе
сначала копирует страницы из одного файла в другой, а потом
накатывает инкременты, то так оно и будет - или все
изменения затрутся инкрементами, или незатертые изменения
сделают базу битой.
собственно, идея была не делать вот эту операцию, а "накатить"
nbackup.nb1 прямо на nbackup.nbk.
Это у кого была такая идея ? И кто сказал, что она единственно верная ?
Влад. ты разработчик сервера. Ты его не пользуешь. Ты не понимаешь,
как люди работают с 20-30-100 гиговыми базами, и чего им надо.
Я хоть и с трудом, но понимаю. И пытаюсь вам, разработчикам,
транслировать то, что хотят люди.
Потому что я не понимаю, зачем читать весь бэкап уровня 0, создавать
новую базу, а потом на новую базу накатывать инкремент,
вместо того чтобы просто накатить инкремент на бэкап уровня 0.
И потерять этот бекап навсегда ? Сейчас ты скажешь, что ты его
заранее скопировал ? Так какая разница кто и когда его будет копировать -
ты сам (можешь и забыть) или nbackup ?
Да блин, вот тебе пример! :-)
есть 2 сервера. На одном постоянно делается инкрементный бэкап,
0 1 и 2 уровня.
Задача. Обеспечить максимально быстрое и эффективное восстановление
базы из последнего инкремента НА ДРУГОМ СЕРВЕРЕ.
Сейчас мы имеем что. Мы не можем сначала закинуть на 2-ой сервер
бэкап 0-го уровня, а потом передавать туда
ТОЛЬКО инкременты. И соответственно накатывать только инкременты,
если база read_only.
Причем, делать это надо регулярно. Например, база имеет размер 30 гиг.
Инкремент 1-го уровня 5 гиг. И что получается? А получается, что имея
на 2-ом серваке уже бэкап 0-го уровня, мы не можем на него накатить 5
гиг изменений. Мы должны прочитать 30+5 гиг и создать из них 30гиговую
базу. Каждый раз когда получаем новый инкремент с 1-го сервера.
И откуда возникает такая идея - попробуй скопировать 30 гиг
с диска на диск. Сколько это займет времени?
А передать 30 гиг с сервера на другой сервер?
Кстати, я не случайно дал здесь запрос по реальным объемам
бэкапов разных уровней. Это тоже интересный вопрос,
на тему "до каких пор имеет смысл использовать инкременты,
или проще копировать бэкап 0-го уровня?"
Как минимум сейчас ясно, что документацию по nbackup
надо исправить и дополнить.
Вот эту ?
http://www.firebirdsql.org/manual/ru/nbackup-ru.html
ну да.
Никогда не поздно, было бы желание
спроси лучше ДЕ на эту тему.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
