Comments 15
Спасибо. Пишите побольше таких интересных историй.
Первый случай — скорее все-таки совсем не о программном баге. RTO в систему при проектировании закладывали? Если да и оно меньше 13 часов — проектировщики и эксплуатанты сами себе злобные буратины, что не оттестировали "плохие" сценарии восстановления, если нет или оно больше — тогда о чем вообще разговор. :)
Оба описанных случая из серии “всё делали правильно, но не оценили возможные риски”. Вероятность программного повреждения данных не рассматривалась заказчиком как риск, ведь решение было массовым, стабильно работало длительное время и таких случаев ранее не было.
По нашему мнению, инфраструктура критичных бизнес-систем должна строиться так, чтобы использование системы резервного копирования в случае повреждения или потери данных было именно резервным средством, а не основным механизмом восстановления доступности бизнес-систем.
Такой подход обусловлен двумя недостатками систем резервного копирования:
По нашему мнению, инфраструктура критичных бизнес-систем должна строиться так, чтобы использование системы резервного копирования в случае повреждения или потери данных было именно резервным средством, а не основным механизмом восстановления доступности бизнес-систем.
Такой подход обусловлен двумя недостатками систем резервного копирования:
- Сложность прогнозирования длительности восстановления данных. Безусловно, система резервного копирования может быть спроектирована под заданные параметры SLA и обеспечивать их в момент своего старта. Однако, как показывает практика, ИТ-инфраструктура любой компании — постоянно изменяющаяся среда, содержащая постоянно растущие объёмы данных. Поэтому спрогнозировать длительность восстановления какой-либо бизнес-системы спустя некоторый промежуток времени достаточно сложно, а в случае массового сбоя, заставляющего восстанавливать множество бизнес-систем (например, при отказе дискового массива) — практически невозможно.
- Недостаточная степень гранулярности восстановления данных. Система резервного копирования, как правило, работает с данными бизнес-приложений на достаточно низком уровне. Это приводит к тому, что при повреждении или потере небольшого набора данных, к примеру, при удалении строки в таблице СУБД Oracle, приходится восстанавливать значительный объём данных — в данном случае целиком табличное пространство СУБД. То есть объём данных, который необходимо восстановить из СРК, часто не соответствует объёму данных, которые были потеряны или повреждены при сбое. Как в данном случае.
Вероятность программного повреждения данных не рассматривалась заказчиком как риск, ведь решение было массовым, стабильно работало длительное время и таких случаев ранее не было.
Ну и что? RTO ведь не про риски, а про восстановление системы, в которой УЖЕ произошел сбой. Бэкап на ленты ведь в принципе делался? Делался. Значит, на какие-то сценарии, в которых потребуется восстановление с них, все же закладывались. И, если эти сценарии не оттестировали, это все-таки недоработка при проектирования системы восстановления (что, собственно, и подтвердилось тем, что заказчик решил ее оптимизировать).
Так может стоит сменить СРК на ту, которая умеет?
А можно подробнее про вот это:
… внедрили программные комплексы дедупликации…
я думал что для админа резервного копирования дедупликация как для быка красная тряпка.
… внедрили программные комплексы дедупликации…
я думал что для админа резервного копирования дедупликация как для быка красная тряпка.
Это, скорее, к вопросу о поставленных задачах, ожиданиях и реальности. В контексте оптимизации СРК программно-аппаратные комплексы с дедупликацией позволяют сократить объем передаваемых данных — в случае с БД, в среднем 5:1, — и тем самым ускорить прохождение бэкапов. Как следствие, позволяет чаще запускать бэкапы и сократить RPO. На длительности восстановления это никак не сказывается.
На длительности восстановления это никак не сказывается.
Это понятно, но как с надежностью хранения? Если какая-то ошибка попадет условно говоря в первую полную копию, то все остальные Incremental и Differential копии будут бесполезны. Видимо там для надежности пристроены еще несколько велосипедов и педалей.
С железными «СРД» общался пока не так уж многосторонне, да и то самоучкой, поэтому интересуюсь.
Если ошибка затесалась, то дедуп или нет — не имеет значения. Восстанавливаться придется с предыдущего бэкапа в любом случае.
Если мы говорим об ошибке записи и битом блоке во время создания полной копии (или любой другой) и система резервного копирования это пропустила, то следующий бэкап при прохождении листинга файлов увидит несоответствие хранимого блока и того, что на системе. Как следствие получим резервирование данного блока. Противоречия нет:)
Если мы говорим об ошибке записи и битом блоке во время создания полной копии (или любой другой) и система резервного копирования это пропустила, то следующий бэкап при прохождении листинга файлов увидит несоответствие хранимого блока и того, что на системе. Как следствие получим резервирование данного блока. Противоречия нет:)
«И на старуху бывает порнуха» — извиняюсь, но два раза прочитал вот так вот в первой строчке. Я даже подумал, что эта фраза более точно описывает невероятное стечение обстоятельств приведших к утере данных.
Бессмыслица какая-то. В пословице речь о том, что даже у старухи может случиться менструация (старорусское слово: проруха).
Ни в одном толковом словаре нет такого объяснения этому слову. Этимология не установлена. Что вы упоминаете, есть только в постах обычных пользователей на форумах.
Да, бессмыслица, но такое событие может произойти и со старухой. Это придает изменённой фразе определенную окраску. Есть ненулевая вероятность участия старухи в порнухе, то же самое и с утерей данных. Проще говоря: вероятность утери данных никогда не равна нулю.
Да, бессмыслица, но такое событие может произойти и со старухой. Это придает изменённой фразе определенную окраску. Есть ненулевая вероятность участия старухи в порнухе, то же самое и с утерей данных. Проще говоря: вероятность утери данных никогда не равна нулю.
У нас в конторе на этот случай вывешивали баннер: «И про старуху снимают порнуху» (тогда мы занимались интеграцией продавцов с Amazon, eBay, Buy.com, shop.com и другими площадками).
Если один оранг… человек смог так сильно все уронить, то налицо ошибка проектирования.
Думать и тестировать все пришедшие в голову сценарии аварий.
Для этого надо принять в команду алармиста-параноика.
Думать и тестировать все пришедшие в голову сценарии аварий.
Для этого надо принять в команду алармиста-параноика.
Sign up to leave a comment.
Черная пятница айтишника, или Сказ о потере данных