Comments 15
Складируйте бэкапы не на сам сервер, который надо бэкапить.
А еще неплохо бы складировать их в другое георгафическое местоположение.
Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:
- ТРИ резервные копии,
- которые должны быть сохранены в ДВУХ различных физических форматах хранения,
- причем ОДНА из копий, должна быть передана на внеофисное хранение
community.veeam.com/blogs-and-podcasts-57/3-2-1-1-0-golden-backup-rule-569
Мы поддерживаем и эту систему, поэтому бэкапы сейчас делаются правильно.
Как это технически у вас реализовано? Есть автоматический мониторинг, который следит, что бэкап прошел? Есть человек, который периодически по регламенту пробует разворачивать систему из бэкапа? Учитывая аутсорс и что у вас много клиентов, интересно, как это устроено.
Если вы используете вендорлокнутую аваевую помойку, готовьтесь страдать.
Скажите пожалуйста, вот Вы пишете:
Итак, у нас на руках — железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём 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 лет.
С чего бы это бэкапу взять и повредиться? Как эти повреждения выглядели? Как они возникли? Это не праздные вопросы, это вопросы доверия к вендору. Потому как, ситуация крайне странная.
З.Ы. Можно было зачистить журналы, и всучить это творение в руки создателя (вендора). Пусть сами разбираются со своими костылями, и не портят людям жизнь.
Спасибо интересная статья.
Аптайм 500 дней/перезагрузка/падение/собираем бэкап по частям