"Маленькие" проблемы больших систем или когда бэкап ломается

Рассмотрим процесс повышения надежности бэкапа на больших системах. Сам процесс бэкапа может быть длительным. И неприятно когда этот достаточно долгий процесс может завершится с ошибками. Что значит отсутсвие бэкапа или старый бэкап думаю понятно. Причины по которым бэкап может не пройти до конца могут быть различными, и в таком случае надо предпринять действия для того чтобы спасти хотя бы его часть. Здесь и далее речь идет про бэкап выполненный с помощью onbar, и дальше вы поймете почему. Рассмотрим бэкап запущенный на выполнение с помощью простой команды "onbar -b -L 0".




Такой бэкап выполняется как некий единый процесс и в случае если произойдет ошибка и процесс завершится (например прервется соединение с storage manager), то что onbar успел сохранить в TSM будет потеряно, информация об уже сохраненных объектах будет недоступна информиксу, в файле ixbar не будет записано никаких сведений об сохраненных объектах. Как быть в таком случае? На помощь приходит т.н. раздельный бэкап по dbspace. При запуске в onbar указываются dbspace которые должны быть архивированы. Т.е. скажем если в системе есть несколько dbspace c именами rootdbs, phylog, data, test, bigdata то можно процесс бэкапа запустить последовательно:



Т.о. небольшие dbspace rootdbs, phylog, data, test будут архивированы быстро и вероятность отказа при малом промежутке времени достаточно мала, затем будет запущена архивация большого dbspace bigdata, и даже если во время этого процесса произойдет сбой, информация о предыдущих dbspace не будет потеряна. Поэтому придется заново запустить бэкап только для dbspace bigdata.
Восстановление из такого бэкапа выполняется как обычно. Такой бэкап также можно использовать для физического восстановления при инициализации репликации HADR.
Единственный минус этого способа - надо быть внимательным при перечислении всех имеющихся в системе dbspace.