Может быть кому-то пригодить

Проверяли очредной штатный бэкап (onbar) путём тестового поднятия HDR
Сюрпрайз - "бэкап не содержит rootdbs"
Несколько офигели - по логам, виду, размеру и времени делания всё нормально.
При этом процедура жутко затратна по времени - при поднятии HDR из onbar-бэкапа есть этап сканирования его файлов, что на 400G несколько не быстро (часов 6-8) и "сюрпрайз" вылезает в самом конце.

Решили пойти новым путём - сервер-то можно поднять и из external-backup, но его изготовление по описаной IBM методике требует onmode -c block на всё время копирования - сервер в таком виде разумеется можно вычёркивать из списка живых.

Обошлись минимальной блокировкой системы - сделали консистентную копию с помощью lvm snapshot (используем lvm raw device , в случае использования файлов в бубен бить по другому)

Основные шаги

1) Оценить сколько времени все ваши чанки будут копироваться на другой сервер. Мы копировали без затей: на одном dd if=чанк bs=10M | nc x.x.x y.y, на другом nc -l y.y >чанк

2) Прикинуть изменяемость данный по чанкам за, скажем, двойное время из п1 и написать протенький скрипт создающий snapshot-ы подходящего размера для КАЖДОГО чанка (кроме чанков временных dbspace)

3) Создать shapshot-ы и собрать статистику за, опять скажем, двойное время копирования:

- на сколько угадали с размером (так как цели получить "правильную" копию на этом этапе нет, то блокировка не нужна).

Это требуется из-за того что переполненый snapshot отключается и если вы его к тому времени не скопировали то придётся начать сначала

- сколько логов было в системе использовано.

Это требуется для минимизации плясок в бубном после начала восстановления - если все прошедшие за время копирования логи ещё доступны на примари то всё в стопятьсот раз проще и быстрее

4) Снести тестовые snapshot-ы

5) По данным пункта 3 подкрутить размеры snapshot-ов и, самое главное, обеспечить что бы логов в системеме могло храниться в ПОЛТОРА-ДВА раза больше чем намеряли.

Зачем ? За тем. После старта восстановления оно начнёт высасывать с примари пропущенные логи и применять их. Однако в это время примари будет не в потолок плевать а работать и генерировать новые логи.

В нашем случае, время копирования 400G по гигабитной сетке составило 4 часа и за это время успели появиться 500 новых логов. После чего процесс восстановления начал играть в догонялки с примари и в итоге ему пришлось применить уже 900 логов (ночь закончилась, нагрузка стала расти и логи побежали быстрее). Чем он и занимался часа два.

6) Все готово.

- onmode -c block

- make snapshots

- onmode -c unblock

время создания snapshot-ов - несколько секунд. ночью такая короткая блокировка безболезнена (для нас)

7) Копируем snapshot-ы "куда надо" (snapshot-ы ! а не сами чанки!), удаляем snapshot-ы (в теории они тормозят запись на lvm (и так оно и есть) и удалить надо побыстрее, но для informix тормоза не заметны благодаря его архитектуре)

8) "Где надо" запускаем восстановление.


Прошло прекрасно и в итоге гораздо быстрее и прозрачнее чем танцы с onbar

Думаем забить на бэкап базы onbar-ом и перейти на snapshot-ы.
Onbar-y останутся только текущие логи (или даже их отдадим ontape)

Вопросы ?

zaiets HDR, RSS как по мне должна преследоваться цель - быстрое создание архива.
В принципе для этих целей и есть платные опции снапшота дисковых массивов, но мы до них еще не доросли.
У вас копирование заняло около 4 часов.
Но, создание того же архива с помощью onbar|ontape заняло бы не более
2 часов (без параллельности) если никто ему не мешал бы.
Ну несколько категоричное утверждение - вы же не знаете наших характеристик железа
Так же оно предполагает идеально-фантастические условия - ни кто не мешает - всех от базы отключать что ли :)

В нашей реальности в наших условиях при нашей нагрузке бэкап нулевого уровня в два потока на примерно такой же дисковый массив по той же гигабитной сети сегодня ночью занял 6.5 часов.

Против 4х часов в один поток с lvm snapshot-ов

zaietsну и непонятно, почему у вас были проблемы с onbar.
Порядок восстановления там довольно простой:
1. зарезервированные страницы
2. rootdbs
3. ....
т.е. ошибка если и имела место, должна была возникнуть на начальном этапе восстановления.
Ага, восстановления. А до него ход не успел у onbar-a дойти - он несколько часов "изучал" бэкап и в итоге отказался (это описано в посте). Возможно вы про просто восстановление, а мы делали HDR

Журавлев Денисвы бы лучше показали копипасты как бекап делали, что вывелось при восстановлении.

ЗЫЖ Современные дисковые массивы делают такие зеркальные "копии", за туже секунду, кликом мышки, и можно продолжать работать и с копией и с оригиналом. И как заставить информикс заставить накатывать журналы на такую копию?
Дениc, спасибо за участие, но целью поста было описать реально сработавший альтернативный способ запуска HDR, а проблема с бэкапом которая стала причной всего мероприятия описано как причина, а не запрос на помощь :)

AndronВозможно автор темы использует ISM, в нем действительно при восстановлении из бэкапа происходит сканирование всего архива перед восстановлением.
Бинго :)
Это ISM

zaietsЯковлев Павел
В нашей реальности в наших условиях при нашей нагрузке бэкап нулевого уровня в два потока на примерно такой же дисковый массив по той же гигабитной сети сегодня ночью занял 6.5 часов.

Против 4х часов в один поток с lvm snapshot-ов


Что-то тут не так.
У меня около 2х часов делается архив с помощью ontape при размере файла архива около 540 Гб на дисковый массив подключенный либо как SAN либо как NFS либо как на НФС на интеловый сервер со встроенными дисками.

Я не знаю что у вас за конфигурация, поэтому и сомнения, так как для меня ваша скорость создания архива кажется малой.

Именно в этот раз да - долговато. Обычно быстрее.
Но в предыдущий раз вы писали что у вас "ни кто ему не мешал" и я уже отвечал, что это идеальные условия которых у меня не бывает.

И проблема с бэкапом была именно с этим. Предыдущие проверки других бэкапов проходили нормально

zaietsЯковлев Павел
Ага, восстановления. А до него ход не успел у onbar-a дойти - он несколько часов "изучал" бэкап и в итоге отказался (это описано в посте). Возможно вы про просто восстановление, а мы делали HDR
Поверьте, с помощью onbar и TSM не раз восстанавливал с архива как просто так и для HDR - подобной проблемы ни разу не возникло. при чем на разных Unix платформах (Solaris,AIX,Linux (32 & 64))

И вам спасибо, но целью поста была не жалоба на бэкап, а описание достаточно простого альтернативного метода - может кому и сгодиться.

И, что не мало важно, метода бесплатного по стравнению с дисковыми массивами со встроеным snapshot-ом :)

Журавлев Денисне знаю в какой операционке вы делали, но у этого способа есть недостатки, например в линуксе производительность просаживается, мне приходится использовать ограничитель cstream.

CentOS 5.3

Да, производительность дисковой системы явно уменьшалась на запись - запись на диск приводила к перезаписи исходого вида данных в snapshot, но именно уменьшалась а не падала в 3-4 раза как описано в данной вами ссылке - наверно всё же разница в дисках и контроллерах. А чтение с оригинального тома вообще не страдало.

И всё это не привело к уменьшение производительности базы на время снятия копии.

AndronЯ когда раньше использовал ISM, чтобы повысить скорость восстановления выкладывал архив на отдельные диски. Также использовал диски примонтированные по NFS, при 100 Мбит сетке 200 Gb архив восстанавливался очень даже шустро. Тут ведь значительную роль играют именно диски.
Нам пришлось в итоге ограничить паралельность ISM-бэкапа до двух - дисковый массив на отдачу просто клал нафик принимающий NFS-сервер - проблемы именно в NFS, c дисками там порядок.