По сути мы тут и не можем знать, что там было с бэкапом. Нас же позвали уже, когда все случилось (клиент в тот момент не был у нас на поддержке). И мы разгребали последствия.
Последний полный бекап БД был повреждён, предпоследний встал нормально, но он был сделан за полгода до событий, поэтому там части информации по словарям КЦ не было.
Итак, у нас на руках — железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базой Informix от IBM + пакет CMS от вендора.
Не совсем понятно — если это «оракловский сервер», то что там делает база Informix?
Она там стоит. А что смущает? Сейчас актуальные версии CMS уже на rhel с тем же самым IDS, система была изначально с ним спроектирована.
Но я на самом деле другое хотел обсудить. В нескольких местах Вы упоминаете «битый бекап», «плохой бекап», «бекап выглядит вообще как из /dev/random» — а можно чуть подробнее?
Во-первых — размер бекапа — «похож на правду», т.е. в сравнении с размером базы (с размером датафайлов) — коррелирует? (с учётом возможной компрессии размер может отличаться в меньшую сторону в несколько раз,
также возможны варианты в зависимости от стратегии бекапа — т.е. полный бекап будет «большой», если используются инкременты — они маленькие, если внутри бекапа (бекапсета) включены архивлоги — размер тоже может плавать. Ну и тд.
Но в целом — если база 1 ТБ, а бекап — пара мегабайт, то обсуждать конечно нечего. К тому же, если внутри Вы говорите на глаз каша «как из /dev/random».
Потому что как «выглядит» бекап внутри — известно, достаточно сделать бекап любой базы Oracle, открыть получившийся файл и посмотреть на него глазами — и сравнить с тем что есть у Вас. Там бинарный формат (если речь про RMAN), но структура похожа между базами — на первых нескольких экранах между «кракозябрами» будут видны строки с именем базы, DBID, именами тейблспейсов, схем, потом таблиц и т.д.
Мы нашли два фулбэкапа базы, которые руками сделали когда-то, так как шедулер был пустой. Да, там система, кстати, при входе в консоль ругается, если нет бекапа более 30 дней и в шедулере нет, но не суть.
Про размер — не вспомню, там точно было не пара МБ, в целом мы сравнивали «хороший» и «плохой» бекап, порядок был плюс-минус тот же с учётом разницы в несколько месяцев.
Сказать какой был изначально размер базы я не могу, поскольку этой информации ни у кого не было.
Ну и последнее — каким образом бекап делался? Если Вы говорите, там у Вас был Solaris — в нем есть такой же обычный cron как и в любом Linux / Unix.
Т.е. Вы же видите, что cron вызывает, какие скрипты, и что внутри. Там вызов rman? А можно «осмотреть наружно», какой вызов команд RMAN использовался?
Там будет нечето вроде блока run { allocate channel… backup as… delete… и_возможно_много_чего_еще… }.
Я к тому что скорее всего у Вас остались образы VM, в которых Вы и ваши коллеги боролись с этой всей аварией.
Вдруг размер бекапа таки не пара мегабайт и более-менее похож на правду — может если с ним поработать, получится таки что-то восстановить.
Бекапов два — один отдельно на IDS, он действительно должен ставиться в cron (но в этом кейсе руками делали).
Про RMAN вижу, что это оракловая штука, здесь о ней речи не идёт, там в скрипте делается через informix ON-Bar.
А второй бекап собственно самого соляриса, он делается руками, там с точки зрения заказчика хранятся настройки пользователей, коннекторов и кастомных скриптов.
Сейчас система бэкапируется на уровне виртуальной среды, а бэкапы БД проверяются автоматически — сначала поиск ошибок по логу, а затем развёртыванием на стенд и запросом в БД к основным таблицам. Также регламентные работы на системе раз в квартал, чтобы глазами убедиться, что восстановленные данные выглядят хорошо.
Нет, т.к. задачи обеспечивать радиопокрытием грядки не стояло
Она там стоит. А что смущает? Сейчас актуальные версии CMS уже на rhel с тем же самым IDS, система была изначально с ним спроектирована.
Мы нашли два фулбэкапа базы, которые руками сделали когда-то, так как шедулер был пустой. Да, там система, кстати, при входе в консоль ругается, если нет бекапа более 30 дней и в шедулере нет, но не суть.
Про размер — не вспомню, там точно было не пара МБ, в целом мы сравнивали «хороший» и «плохой» бекап, порядок был плюс-минус тот же с учётом разницы в несколько месяцев.
Сказать какой был изначально размер базы я не могу, поскольку этой информации ни у кого не было.
Бекапов два — один отдельно на IDS, он действительно должен ставиться в cron (но в этом кейсе руками делали).
Про RMAN вижу, что это оракловая штука, здесь о ней речи не идёт, там в скрипте делается через informix ON-Bar.
А второй бекап собственно самого соляриса, он делается руками, там с точки зрения заказчика хранятся настройки пользователей, коннекторов и кастомных скриптов.
Образов виртуалки на руках нет, истории N лет.