Аптайм 500 дней/перезагрузка/падение/собираем бэкап по частям

[v1000]

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

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

[AlexGluck]

Правило 3-2-1)

[v1000]

Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:

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

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

[talekseenok]

Спасибо, схоронил)

[rtzra]

Уже есть правило 3-2-1-1-0
community.veeam.com/blogs-and-podcasts-57/3-2-1-1-0-golden-backup-rule-569

[Jsty]

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

Как это технически у вас реализовано? Есть автоматический мониторинг, который следит, что бэкап прошел? Есть человек, который периодически по регламенту пробует разворачивать систему из бэкапа? Учитывая аутсорс и что у вас много клиентов, интересно, как это устроено.

[talekseenok]

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

[DarkHost]

Выводы:
Если вы используете вендорлокнутую аваевую помойку, готовьтесь страдать.

[shane54]

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

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

[talekseenok]

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

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

[ktod]

Так и непонятно что произошло с бекапами. С чего это они вдруг на исправном железе стали плохими.

[talekseenok]

Последний полный бекап БД был повреждён, предпоследний встал нормально, но он был сделан за полгода до событий, поэтому там части информации по словарям КЦ не было.

[ktod]

Это какая то шутка? Вы об этом в статье писали.

С чего бы это бэкапу взять и повредиться? Как эти повреждения выглядели? Как они возникли? Это не праздные вопросы, это вопросы доверия к вендору. Потому как, ситуация крайне странная.

[talekseenok]

По сути мы тут и не можем знать, что там было с бэкапом. Нас же позвали уже, когда все случилось (клиент в тот момент не был у нас на поддержке). И мы разгребали последствия.

[Z7D]

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

Спасибо интересная статья.