Pull to refresh

Comments 15

Складируйте бэкапы не на сам сервер, который надо бэкапить.

А еще неплохо бы складировать их в другое георгафическое местоположение.

Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:
  1. ТРИ резервные копии,
  2. которые должны быть сохранены в ДВУХ различных физических форматах хранения,
  3. причем ОДНА из копий, должна быть передана на внеофисное хранение

надо будет запомнить

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

Как это технически у вас реализовано? Есть автоматический мониторинг, который следит, что бэкап прошел? Есть человек, который периодически по регламенту пробует разворачивать систему из бэкапа? Учитывая аутсорс и что у вас много клиентов, интересно, как это устроено.
Сейчас система бэкапируется на уровне виртуальной среды, а бэкапы БД проверяются автоматически — сначала поиск ошибок по логу, а затем развёртыванием на стенд и запросом в БД к основным таблицам. Также регламентные работы на системе раз в квартал, чтобы глазами убедиться, что восстановленные данные выглядят хорошо.
Выводы:
Если вы используете вендорлокнутую аваевую помойку, готовьтесь страдать.

Скажите пожалуйста, вот Вы пишете:

Итак, у нас на руках — железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базой Informix от IBM + пакет CMS от вендора.

Не совсем понятно - если это "оракловский сервер", то что там делает база Informix?

Но я на самом деле другое хотел обсудить. В нескольких местах Вы упоминаете "битый бекап", "плохой бекап", "бекап выглядит вообще как из /dev/random" - а можно чуть подробнее? Во-первых - размер бекапа - "похож на правду", т.е. в сравнении с размером базы (с размером датафайлов) - коррелирует? (с учётом возможной компрессии размер может отличаться в меньшую сторону в несколько раз, также возможны варианты в зависимости от стратегии бекапа - т.е. полный бекап будет "большой", если используются инкременты - они маленькие, если внутри бекапа (бекапсета) включены архивлоги - размер тоже может плавать. Ну и тд. Но в целом - если база 1 ТБ, а бекап - пара мегабайт, то обсуждать конечно нечего. К тому же, если внутри Вы говорите на глаз каша "как из /dev/random". Потому что как "выглядит" бекап внутри - известно, достаточно сделать бекап любой базы Oracle, открыть получившийся файл и посмотреть на него глазами - и сравнить с тем что есть у Вас. Там бинарный формат (если речь про RMAN), но структура похожа между базами - на первых нескольких экранах между "кракозябрами" будут видны строки с именем базы, DBID, именами тейблспейсов, схем, потом таблиц и т.д.

Ну и последнее - каким образом бекап делался? Если Вы говорите, там у Вас был Solaris - в нем есть такой же обычный cron как и в любом Linux / Unix. Т.е. Вы же видите, что cron вызывает, какие скрипты, и что внутри. Там вызов rman? А можно "осмотреть наружно", какой вызов команд RMAN использовался? Там будет нечето вроде блока run { allocate channel... backup as... delete.... и_возможно_много_чего_еще... }. Я к тому что скорее всего у Вас остались образы VM, в которых Вы и ваши коллеги боролись с этой всей аварией. Вдруг размер бекапа таки не пара мегабайт и более-менее похож на правду - может если с ним поработать, получится таки что-то восстановить. А то людей жалко, потерять пол-года критических для бизнеса данных - эх..

Скажите пожалуйста, вот Вы пишете:
Итак, у нас на руках — железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём 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.

А второй бекап собственно самого соляриса, он делается руками, там с точки зрения заказчика хранятся настройки пользователей, коннекторов и кастомных скриптов.

Образов виртуалки на руках нет, истории N лет.
Так и непонятно что произошло с бекапами. С чего это они вдруг на исправном железе стали плохими.
Последний полный бекап БД был повреждён, предпоследний встал нормально, но он был сделан за полгода до событий, поэтому там части информации по словарям КЦ не было.
Это какая то шутка? Вы об этом в статье писали.

С чего бы это бэкапу взять и повредиться? Как эти повреждения выглядели? Как они возникли? Это не праздные вопросы, это вопросы доверия к вендору. Потому как, ситуация крайне странная.
По сути мы тут и не можем знать, что там было с бэкапом. Нас же позвали уже, когда все случилось (клиент в тот момент не был у нас на поддержке). И мы разгребали последствия.
В первые слышу, что бы сервер на Иксах нужно бы было так часто перезагружать. Если потеоретизировать, что могло привести к поломке, это переполнение памяти и swap-а, что в свою очередь пагубно повлияло на бэкап, странно, неужели в отчетах о бэкапах не было ошибок. В любом случае тут вопросы больше к вендору который из-за криво написанного ПО, заставляет дергать ручку раз в 90 дней, это же смешно.
З.Ы. Можно было зачистить журналы, и всучить это творение в руки создателя (вендора). Пусть сами разбираются со своими костылями, и не портят людям жизнь.

Спасибо интересная статья.
Only those users with full accounts are able to leave comments. Log in, please.