Microsoft Exchange: 12 мифов об аварийном восстановлении

“Потому что почта никогда не останавливается. Она все прибывает и прибывает. Тонны ее, и становится все больше и больше! А ты должен “выдавать” ее, и чем больше ты ее выдаешь, тем больше ее прибывает!”
Newman (Seinfeld)

Все то время, которое существует Microsoft Exchange Server, существуют также и инструменты, предназначенные гарантировано предотвращать аварийные ситуации, подобные внеплановой недоступности служб. Но многие продукты не могут обеспечить эту гаранитию, а бывает и сами являются причиной проблем, будучи внедренными в сложные, комплексные почтовые конструкции. Так что же делать администраторам Exchange?

Архивация была, есть и будет частью процесса обеспечения защиты от катастроф, но она не предотвратит выход сервиса из строя, и не является панацеей от потери данных. С ростом значимости систем почтового документооборота для бизнеса, в частности систем Microsoft Exchange, — не сюрприз, что появляются и плодятся ложные представления о программах и процедурах аварийного восстановления. Различные приложения “выросли” из области архивирования, и предлагают множество “вкусных” фич… Но работает ли это в действительности?

Возможно, в и вашей компании тоже, от Microsoft Exchange зависит течение бизнеса, взаимодействие с заказчиками, связь сотрудников между собой и тому подобное. И если Exchange выйдет из строя, даже на несколько минут – рабочие процессы впадут в ступор. И хелпдеск будет завален звонками от пользователей, жалующихся на то что “почта в коммуникаторе зависла”, а сотрудники вдалеке от офиса могут остаться вообще “за бортом”.

Избежать выходов Exchange из строя можно только тщательно продумав план аварийного восстановления (DRP, Disaster Recovery Plan). План этот во-первых призван обойти аварии, а во-вторых снизить их разрушительность (в терминах длительности и потерь данных).

И вот, вашему вниманию представлены 12 мифов об аварийном восстановлении Microsoft Exchange, и способы их преодоления, с помощью тщательного планирования и правильного набора инструментов.

I. «Да ладно, всегда можно восстановить из архива!»
Реальность: Не обязательно, как показывают собственные исследования Microsoft.

План архивации никак не заменяет план аварийного восстановления. Согласно исследованиям, проведенным Microsoft, 42% всех восстановлений Exchange Server со стриммерных лент оканчиваются неудачно. Каждый год, компании всех размеров тратят тысячи долларов на решения новейшего и самого лучшего аппаратного и программного обеспечения для архивации. Все эти новые технологии дают нам фальшивую уверенность в безопасности, обеспечивая всего процесс передачи данных Exchange из точки А (Exchange Server) в точку Б (архивный носитель).

Но Exchange является динамичным и комплексным приложением. Особое внимание должно быть уделено защите всех ключевых компонентов, а не только данным. .Edb и .Log файлы, ключи реестра, конфигурации AD и серверной операционной системы — все это играет важнейшую роль в поддержании работоспособности инфраструктуры Exchange. И если ваш Exchange Server в ненормальном состоянии во время архивации — все ваши усилия тщетны, поскольку вы архивируете информацию, не обеспечивающую успешного восстановления.

Основной причиной неудачных попыток восстановления Exchange Servers из архивных копий являются поврежденные файлы журналов транзакций, а то и хуже, поврежденные EDB базы. Малейшая ошибка может повредить базу данных или журнал транзакций таким образом, что при восстановлении с ленты, EDB просто не подмонтируется. В таких случаях вы обращаетесь в центр поддержки Microsoft, или запускаете ESEUTIL, чтобы попытаться починить свои базы и наконец подмонтировать их, и все это ценной дорогостоящего рабочего времени и потенциальной потери данных.

Для преодоления этой проблемы важно удостоверяться, что ваш процесс архивации проверяет архивируемые данные. Подобная проверка поможет выявить проблему раньше, чем уже будет поздно. Архивация данных вслепую – это не противоаварийная защита, и ничего не гарантирует в случае длительного выхода служб из строя или аварийной потери данных. Чтобы достич пользы, необходимо архивировать и конфигурации приложения, не только данные. И в добавок, проверять, монтируются ли ваши копии EDBs баз.

II. «Архивация отдельных ящиков – лучшее средство восстановления отдельных писем»
Реальность: Brick-level backup — это вчерашний день, медленный и необязательный компонент плана восстановления.

Большинство из решений архивации требуют отдельного копирования на уровне MAPI, известного как «brick-level backup», для обеспечения возможности восстановлений отдельных писем. И как часть плана аварийного восстановления, вы хотели бы иметь возможность быстрого восстановления писем и почтовых ящиков, случайно удаленных пользователем. И не смотря на то, что подобные проишествия и достигают корпоративных масштабов, они все же могут значительно и негативно сказаться на бизнесе и продуктивности служащих. Врядли у Exchange администраторов найдется достаточно времени восттанавливать каждому пользователю его “ой,-случайно-удалившиеся” письма. Так что подобные инциденты могут оставаться незакрытыми, зияя прорехой в вашем плане аварийного восстановления.

Применение опции сохранения удаленных писем и почтовых ящиков, в свойствах баз данных Exchange, позволит справится с данной проблемой. Тем более что опции включены по умолчанию. А имея достаточно дискового пространства для баз, можно увеличивать сроки хранения удаленных писем. Отдельные запущенные случаи можно держать в отдельной почтовой базе, ну и в конце-концов, можно обзавестись инструментом, с помощью которого можно было бы открыть архивную копию EDB и достать искомое письмо. Время, сэкономленное таким образом в первые несколько недель окупит компании стоимость инструмента.

III. «Нельзя заранее определить поврежденную базу в архиве»
Реальность: Можно!

Традиционно, единственным способом тестирования архивных баз данных на предмет поврежденности, был полный тестовый процесс восстановления (восстановление на альтернативный изолированный Exchange сервер), например через группу аварийного восстановления (Recovery Storage Group). У администраторов Exchange может просто не хватить времени на проведение этого замысловатого действа, особенно на регулярной основе. А что если базы сбойные? Будете дублировать процесс или попробуете еще раз, надеясь что сработает?

Восстановить, перегрузить и скрестить пальцы — не вариант тестирования плана аварийного восстановления. Вместо этого, стремитесь не допускать поврежденные данные в архив. Используйте инструмент архивации, содержащий встроенную проверку целостности и проактивного оповещения администраторов если что-нибудь пойдет не так.

IV. «Восстановление Exchange после сбоя = ночевать в серверной»
Реальность: Нет, гораздо быстрее!

Сложность конструкций Exchange, при восстановлении архивов часто отнимает времени больше, чем хотелось бы. И тогда “Red Bull” и “Power Bars” становятся реальными инструментами Exchange администраторов. Стародавние процедуры аварийного восстановления действительно могут заставить вас проводит бессонные ночи восстановления Exchange, и то, если вам удасться победить все “jet errors”.

Инкорпорированные инструменты, призванные помочь ускорить восстановление в случаях аварийных сбоев смогут приносить пользу еще долгое время. Большинство из планов аварийного восстановления расчитаны только на данные Exchange, оставляя за рамками внимания окружающую инфраструктуру – операционные системы, патчи, антиспам и антивирусные инструменты, настройки доменов и прочие, относящиеся к теме конфигурации. В некоторых аварийных ситуациях вам понадобится восстанавливать всю инфраструктуру, а не только Exchange, так что в процессах восстановления полезно учесть и автоматизацию восстановления “с чистого листа”, “bare metal restore”.

V. «У нас нет времени/технических возможностей для тщательного тестирования планов восстановления»
Реальность: Технологии виртуализации уже давно позволяют забыть об аппаратных ограничениях для подобных тестов.

Большинство из администраторов будут жаловаться на отсутствие ресурсов (времени, денег, оборудования) для действительно качественного тестрования процедур восстановления. С появлением виртуализации, подобные стоны больше не заслуживают внимания.

С виртуализацией, вы можете создать полную уменьшенную копию своей рабочей инфраструктуры в пределах одного-двух компьютеров. А затем просто проводить тестирование планов обновления программного обеспечения, накатов патчей, модификаций различных настроек, все это в изолированной вируальной среде, чтобы наблюдать влияние этих изменений на копию вашей среды. Если все идет отлично — можно повторять все действия на “боевых” серверах. Вдобавок, можно вызвать сбой в виртуальной среде (незапланированное выключение, падение дисков, удаление критических файлов) и протестировать процесс восстановления, в обстановке, приближенной к реальной. Это даст вам уверенность в оперировании восстановлением и возможно выявит недостатки вашего плана восстановления.

VI. «Инструменты восстановления Exchange обычно нацелены только на данные Exchange»
Реальность: Ни разу! Новые продукты позволяют архивировать и состояние приложений.

Cуществующие решения для восстановления Exchange прилагают все усилия к защите данных Exchange, архивируя, резервируя и реплицируя их в удаленные локации. Но когда ваша почта “падает”, вам же не нужны только базы данных, правда?! Вам нужны и целые данные и работающие приложения в рабочей среде, которые предоставят пользователям полный спектр услуг документооборота и электронной почты. Игнорирование остальной инфраструктуры, в вопросах обеспечения отказоустойчивости, обернутся задержками восстановления, оставляя пользователей без рабочих инструментов дольше чем можно. Применяйте планы восстановления, учитывающие не только защиту данных, но и приложений.

VII. «Нельзя восстановить почту, если журналы транзакций повреждены»
Реальность: Новые инструменты вовсю развивают эту область, сводя потери к минимуму.

Ошибка “JET -501 JET_errLogFileCorrupt” может убить вам весь день. Инструкции, обычно, указывают, что пора запускать ESEUTIL/K, что вероятно поможет в восстановлении, с учетом возможных потерь писем пользователей. А это не вариант для тех компаний, чей бизнес серьезно связан с целостностью почты Exchange.

Имея инструменты репликации всех рабочих данных, включая журналы транзакций, вы сможете справляться с подобными проблемами легко и непринужденно. Это должно стать важным аспектом вашего DRP.

VIII. «Чтобы делать снимки Exchange Server – нужно иметь SAN»
Реальность: Не обязательно. SAN дает прирост производительности, но ничего и знать не знает о ваших приложениях (и это все еще стоит серьезных денег).

Да, SAN обеспечивает огромную производительность дисковых I/O операций, но остается абсолютно безразличен к типам серверных приложений. Если сюда учесть еще и то, что администраторы СХД далеко не всегда являются гуру Exchange, SQL Server, Oracle, итд – ошибки и шаблонный подход к конфигурации – делают свое черное дело. В результате, иногда мы видим очень быстрое хранилище но с минимальным количеством реализованных преимуществ, когда дело доходит до реального аварийного отказа. И вам все еще понадобится восстанавливать не только данные, но и сервера.

Как уже говорилось ранее, действительно качественный план восстановления должен включать в себя снимки состояния приложений. Вы не можете просто архивировать сырые данные. Разница между снимками может составлять разные рабочие часы, с разным размером угрозы потерь данных в случае аварийного отказа. И совершенно необязательно вырывать из бюджета компании средства на дорогостоящий SAN. Современные решения позволяют, и даже акцентируют свое внимание на более доступных носителях, не снижая, вместе с тем, возможности отказоустойчивости ни на йоту. Отличный пример – Microsoft, где 99.999 отказоустойчивости инфраструктуры Exchange, реализованы на DAS, CCR и DPM.

IX. «Полный архив баз может занимать до трех дней, включая выходные»
Реальность: Нет, если у вас хороший план архивации в DRP.

Архивация и план аварийного восстановления идут рука об руку друг с другом. Нельзя иметь хороший DRP, не имея системы архивации, оптимизированной под ваши нужды. И наоборот, самый лучший план архивации не стоит ничего, если ваша стратегия DRP не использует его подобающим образом. Почты за выходные может и станет меньше, но с каждым днем у вас будет появляться все больше и больше работы. По сути, для каждой организации, не только в терминах почтового документооборота, но и планирования и управления задачами и ресурсами, нужды в объемах систем хранения данных растут экспоненциально. Тщательное архивирование ваших систем является обязательным условием, а большинство полагает, что такая архивация будет длиться чересчур долго. Несмотря на то, что архивация может уменьшать размер баз данных, она никак не влияет на конечное количество сообщений в почтовом ящике пользователя. И в результате, мы нередко можем наблюдать, как традиционный “full backup” может длиться более суток, особенно, когда одним из расходных факторов времени является проверка целостности баз.

Таким образом, важно усилить акцентирование на инкрементном копировании/репликации, как это например проводит Data Protection Manager. По сути, инкрементная архивация проводится значительно быстрее и занимает меньше дискового пространства. А это значит что вы сможете делать больше снимков, и более часто. Результатом будет снижение RPO (recovery point objective) и RTO (recovery time objective).

Exchange имеет преимущества над многими известными конкурентами, типа Lotus Notes, Scalix или Zimbra, например в плане дедубликации, в следствии своей архитектуры оптимизированной передачи и хранения данных. Представьте себе пользователя, пересылающего 10MB аттачмент в письме, десятку своих коллег. В базе Exchange будет храниться только 10MB этого вложения, а не 100, как у вышеуказанных конкурентов. Это называется Exchange SIS, “Single Instance Store”. Дедубликация расчитана на подобные примеры. А ведь она значительно снижает размеры хранилищ Exchange (обычно порядка 70%).

X. «Ленточные стримеры – проверены временем, а все эти ваши новомодные штучки – от лукавого.»
Реальность: Фу! Ленточные стримеры – старая проплешина современных IT. Никаких преимуществ, только недостатки.

Множество прогрессивных компаний и гос.учреждений в мире уже пришли к такому выводу. BMW, МВД Австрии, ICON, Total Wine & More, Inovative, Convergent Computing и многие другие отказались доверять в XXI веке свой бизнес каменным топорам (aka стримерам). Показателен пример и самого флагманского вендора. Microsoft IT сумел сохранить $5 млн. избавившись от ленточных накопителей для архивирования. До этого, Microsoft приходилось иметь 7 групп хранения Exchange и делать full backup каждой из них лишь одну ночь в неделю.

Конечно же, никто не призывает вас срочно выбрасывать стримеры на мусорку. Инженеры и архитекторы с многолетним опытом, смогли снизить зависимость времени и успешности архивации от ленточных накопителей до абсолютного минимума. Т.е. те, кто не исключает ленточные накопители из системы архивации насовсем, просто оставляют их для “off-site backup”, т.е. выносных архивов, хранящихся отдельно от серверной. У лент осталась одна единственная извиняющая положительная характеристика – переносимость, с минимальными рисками.

“On-site backup”, основной, делается на жесткие диски, SAN, DAS. Это быстрая архивация, надежная и долговечная. HDD не изнашиваются также быстро как ленты, имеют лучшую производительность поиска, чтения и записи, I/O операций, меньшую стоимость на GB и более простую доступность. Но их не рекомендуется “носить”, если вы конечно хотите использовать их долго. А ленточные кассеты переносятся легко. Вот им и осталась второстепенная роль, где не так важны скорость и качество.

Но все это до поры до времени, пока SSD или аналогичные технологии не достигнут большего прогресса и распространения.

XI. «Непрерывная защита стоит больших денег»
Реальность: Ничуть! Сегодня непрерывная протекция стоит буквально копейки.

Надлежащее сопровождение инфраструктуры Exchange требует несколько большего чем просто Exchange сервер и лицензия. Необходимы также специально подобранное хранилище, процессорные мощности, пропускная способность сети и конечно же программное обеспечение аварийного восстановления. Все эти условия могут вылиться в значительную стоимость, превышающую бюджеты многих. Но в реальности оказывается что компании, в большинстве случаев, уже инвестировали в эти компоненты. Так что внедрение качественного DRP, плана аварийного восстановления, во все эти системы может значительно повысить стоимость вашей компании, с минимальными, на этом фоне, затратами. Лидирующие инструменты на сегодняшнем рынке могут обойтись вам даже в два цента за почтовый ящик в день. Это сделка!
В конце-концов, у вас просто есть два варинта – быстро и качественно восстановить Exchange, в случае аварийного сбоя, или мучиться с устаревшими приложениями, долго восстанавливающими, еще дольше архивирующими, бороться со старыми недугами, и с новыми тоже, и неприятно бывать “на ковре”.

XII. «Приложения, специализирующиеся на защите Exchange, требуют много времени на изучение нового»
Реальность: Да не так уж и много.

Хороший инструмент защиты и восстановления всегда будет основан на логике Exchange, на тех же самых принципах управления данными, хранилищами и политиками сохранения, известным вам в текущей работе. Ну, конечно придется ознакомиться с новыми инструментами, но это же не тоже самое, что начать изучать китайский, правда? Не “rocket science” в общем. Это всего лишь новый интерфейс, так что расслабьтесь и получайте удовольствие, от того, что умеете обращаться с новым инструментом.

7 thoughts on “Microsoft Exchange: 12 мифов об аварийном восстановлении”

  1. Меня задело это:
    второстепенная роль, где не так важны скорость и качество

    ни за что на свете не променяю свою ленточную библиотеку Ultrium 4 ! 🙂

    …разве что на новенький VTL 🙂 🙂

    1. Хе-хе,
      это же не директивы. Все вольны выбирать себе советы на вкус и на цвет.

  2. Резервная копия и восстановление данных – вечная эпопея.
    Обычно люди начинают о ней задумываться только после серьёзных последствий.
    В практике был случай (2004 год):
    Знакомый делал резервные копии баз Exchange 2003 (50 ГБ) на ленты раз в неделю (full)
    Естественно архивы не проверялись.
    В итоге:
    Трёхдневный простой электронной почты стоил организации больших денег (к слову сказать среди клиентов Intel, Связной, Эльдорадо)
    Системного администратора не наказали.
    Резервные копии до сих пор не проверяются -)
    Халатность IT отдела в данной компании принесла много убытков.

    1. О-о! интересные истории.
      А я думал администратору проведут ускоренный экспресс-курс обучения полетам с 15го этажа 🙂
      На моей памяти администраторов наказывали и за меньшие проступки.

      Т.е. руководству компании в принципе наплевать, что они могут еще не раз так просесть на деньги?!
      Или словоблуд-администратор убедил их что в “глючном виндовс и ексчанге всегда так – что-нибудь да ломается, типа неизбежно как смерть и налоги”?

      Думаю, что в моем IT отделе такой администратор ответил бы рублем, в размере потерь, как лицо ответственное и причинившее убытки по халатности, после незамедлительного увольнения с соответствующей записью в трудняке.

  3. .. и как всегда, администратору достаётся) доставаться в той же мере должно и IT-директору.
    да и ошибки бывают разные. К примеру, у меня однажды грохнулась база exchange, а резервная копия не восстанавливалась, проверка не делалась при копировании, так как резервное копирование длится почти сутки + проверка ещё больше, что было вообще неприменимо никак. На инфраструктуру деньги были потрачены, а про бекапирование забыли,в результате стоял постоянно дающий сбоя простой PC с набором дисков и ленточной библиотекой под unix, так как покупать никто ничего не собирался.
    Да, админ виновен 🙂
    у всех было включено кеширование ящиков на клиенте, поэтому восстановление было с выгрузкой в pst и загрузкой обратно. База была 250 гигов, а жестких дисков для проведения isinteg восстановления, дефрагментаций и тп занимало где-то 3 суток на одну операцию, и жестких дисков 500+ гигов не оказалось под руками.
    Вот такой вот печальный опыт 🙂
    Статья полезная, но только с учётом, что IT-бюджет правильно подсчитан и в нём внесены все необходимые пункты про траты на резервное копирование, иначе что собрано на коленке и будет работать через пень колоду.

  4. Согласен, ленточный накопитель – рудиментарный элемент, который и выбрасить жалко и вроди бы работает, но проигрывает по характеристикам дисковым накопителям.
    Такова природа IT-человека, как в анекдоте:
    -Проверял?
    -Да.
    -Работает?
    -Да.
    -ТОГДА НИЧЕГО НЕ ТРОГАЙ!
    Потрачены деньги, а самое главное эти затраты были обоснованы со всех сторон и бухгалтерия скрепя сердце выложила “свои кровные” за непонятные железяки. Учитывая прямолинейность большей части бухгалтерии аля “мы же уже покупали устройства для резервного копирования, зачем вам еще?” очень сложно убеждать руководство в том, что объемы информации растут, нужны модернизации и всё такое.
    Примерно год назад (бывает же такое) одной из фирм, не буду афишировать название, пришлось списать ZIP накопитель в связи с моральным устареванием.
    Вроди бы бред, что можно сохранить на 100 Мегабайтной дискете? А с другой стороны: “Но ведь оно же работает, из строя не вышло…”.
    Хорошо что не всё руководство мыслит в просоветском ключе, есть люди осознающие риски связанные с IT и в этих случаях своих админов обучают, закупают именно то, что нужно бизнесу (а не требуют от админа изобретения бесплатного велосипеда) и самое интересное – многие отдают свою контору на растерзание аутсорсерам, которые принимают часть рисков на себя.

Leave a Reply

Your email address will not be published.