После катастрофы. Теория и практика восстановления Exchnage Server

 МИХАИЛ ДАНЬШИН, эксперт в области ИТ. Специализируется на Exchange и смежных технологиях. Ведет блог (http://danshin.ms), выступает на конференциях и в MCP-клубе.Награжден премией Microsoft MVP

После катастрофы
Теория и практика восстановления Exchnage Server

Почта в организации является одним из основных рабочих инструментов. Что будет, если вы его лишитесь? Готовы ли вы к такому повороту событий?

Данной публикацией я хочу начать цикл статей, посвященных восстановлению Exchange Server. Вы узнаете о том, что нужно сделать, чтобы сбой сервера не застал вас врасплох, как правильно разработать план аварийного восстановления Microsoft Exchange Server и о чем следует позаботиться задолго до того, как произойдет авария. Я расскажу о «подводных камнях», которые встретятся у вас на пути. Вы также узнаете, какие действия нужно предпринять после восстановления, и сможете ответить на следующие вопросы:

• Какое оборудование и ПО нужно использовать, чтобы иметь возможность восстановления почтовой системы после сбоя?
• Сколько времени займет восстановление почтовой системы после отказа почтового сервера?
• Смогут ли пользователи продолжить работу с почтой после отказа почтовой системы?
• Что произойдет с почтой, которая была отправлена на ваш адрес, в то время когда ваша почтовая система находится в нерабочем состоянии?
• Что нужно будет предпринять пользователям после восстановления почтовой системы?
• Сохранятся ли правила обработки почтовых сообщений на сервере и клиенте после восстановления?
• Стоит ли использовать отказоустойчивые серверы и серверы «горячей» замены или можно обойтись восстановлением после аварии?

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

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

Как вы думаете, где большинство менеджеров хранит важные документы, которые когда-то получили в виде вложений, по электронной почте? Конечно же, в своем почтовом ящике! А вам никогда не приходилось искать старое сообщение, чтобы скопировать оттуда часть информации? Думаю, приходилось. Несложно представить, что будет, если мы вдруг лишимся всего этого.

Сценарий

За основу для статьи возьмем следующую схему. Назовем нашу вымышленную организацию CONTOSO. В ее главном офисе два сервера – CON-HQ-DC-01 и CON-HQ-EX-01. На первом сервере установлены следующие роли: контроллер домена, DNS, DHCP, подключено лентозаписывающее устройство для хранения резервных копий, а на втором – почтовый сервер Exchange. Все наши серверы выпущены известными фирмами-производителями, правильно настроены и не имеют проблем с оборудованием. Везде используется операционная система Windows Server 2003 SP2. Резервное копирование всех почтовых хранилищ осуществляется ежедневно при помощи программы NTBackup. За правильностью создания резервных копий ведется постоянное наблюдение (см. рисунок).

Схема нашей вымышленной организации

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

Описанная схема организации не является оптимальной, но для простоты изложения и понимания материала я решил опустить тонкости планирования ИТ-инфраструктуры предприятия. В будущих статьях я надеюсь уделить внимание проблеме правильной организации ИТ-инфраструктуры с использованием Exchange Server.

План восстановления

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

Прежде всего нужно позаботиться о резервном копировании наших данных, чтобы было что восстанавливать. Также нам понадобится резервное оборудование, которое мы будем использовать взамен вышедшего из строя. И конечно же, нужен чёткий план действий. Но это не все… Давайте опишем все подробно.

Существует такое понятие, как Disaster Recovery (восстановление после катастрофы). Под катастрофой понимается ситуация, при которой часть или все серверы нашей организации полностью выведены из строя или уничтожены. Например, серверную затопило, сломался кондиционер и возник пожар, ураган, землетрясение – все что угодно. В наших широтах ураган и землетрясение – явления нечастые, а вот «затопило» или «пожар» случаются каждый день.

Но катастрофой могут быть не только масштабные разрушения. Иногда это потеря важного документа или письма. На подобные случаи есть резервное копирование, VSS и другие подобные механизмы. Раз уж мы рассуждаем категориями «сервер», «база», то данное упоминание здесь, попросту говоря, лишнее.

Хорошо иметь план восстановления после катастрофы или Disaster Recovery Plan (DRP). В описываемом мною сценарии, а именно потери почтового сервера, катастрофа по своим масштабам выглядит не так ужасно, но по значимости она равна потере всех серверов компании, т.к. в некоторых случаях способна полностью парализовать ее деятельность. Посудите сами, зачем вам нужны будут остальные сервисы, такие как AD, DNS, DHCP, если почтовая система вышла из строя? Конечно, возможно, будут доступны такие ресурсы, как файловый сервер и веб-сервер, но для нас они не столь критичны, как почта.

Подробный план восстановления поможет сократить время, которое мы затратим на «оживление» нашей почтовой системы после сбоя. А время, как известно, деньги. Кроме того, имея на руках подробный план восстановления и детальное описание тех действий, которые необходимо предпринять, вы сможете сэкономить не только время, но и нервы. Попробуйте заняться чем-то важным, когда телефон разрывается от звонков, гневные пользователи требуют восстановить работу, а начальник стоит над душой. Особенно, если вы точно не знаете, что делать.

Как же должен выглядеть план восстановления?

Что включить в план восстановления?

План восстановления обязательно должен включать в себя следующее:

1. Подробное описание всех серверов, которые планируется восстанавливать. Частой ошибкой системных администраторов является недостаточное документирование серверов. В самый критический момент они не могут вспомнить, как были размечены диски, какой фирмы использовались жесткие диски, какие обновления были установлены, какой IP, шлюз и DNS были в сетевых настройках сервера и т.д. В нашем случае отсутствие этих данных может стоить нам очень дорого, так как без этой информации восстановить Exchange Server невозможно! Поэтому позаботьтесь о том, чтобы в плане восстановления была следующая информация:

• конфигурация RAID-контроллера;
• конфигурация логических дисков и разметка разделов;
• сведения обо всем оборудовании – его модель и наименование производителя;
• конфигурация всех сетевых интерфейсов, включая таблицы маршрутизации;
• информация обо всем установленном ПО и обновлениях;
• пути хранения и названия файлов резервных копий.

Примечание: план восстановления может не содержать подробного описания всей ИТ-инфраструктуры компании, но при наличии такого документа лучше упомянуть о том, что он есть и где его взять.

Говоря об описании серверов, хочется упомянуть о хорошей практике составления так называемых паспортов устройств. Паспорта устройств составляются не только на серверы, но и на все конфигурационные элементы вашей ИТ-инфраструктуры, такие как пользовательские рабочие станции, принтеры. Паспорта устройств могут включать в себя не только информацию о конфигурации, как описано выше, но и все, что вы сами захотите включить в него. Например, вы можете указать, в какой комнате расположено устройство, кто является ответственным за контент и кого необходимо оповестить в случае возникновения проблем.

2. Подробные инструкции по восстановлению. Снабдите ваш план подробными инструкциями, описывающими весь процесс восстановления по шагам. Лучше, если план будет содержать снимки экранов. Имея такой план восстановления, новый сотрудник, который только начинает знакомиться с вашей ИТ-инфраструктурой, гораздо быстрее сможет войти в работу. А подробные действия, описанные в плане, минимизируют риск ошибки.

3. Пароли. Если вам знакома ситуация, когда в самый неподходящий момент оказывается, что пароль от сервисной учетной записи потерян, то вы меня поймете. Проверьте себя – помните ли вы пароль восстановления Active Directory? Если нет, то, возможно, предыдущий системный администратор уволился, не оставив пароль, или вы просто его забыли или не знали. Мне кажется, что вам не помешает следующая информация.

Со временем ИТ-инфраструктура обрастает так называемыми служебными учетными записями. Например, учетная запись, от имени которой делается резервное копирование. Или учетка для запуска какой-то службы. Пароли от таких записей обычно не держат в голове, а хранят в «паролехранилке». Это может быть зашифрованный файл или, на худой конец, простая электронная таблица. Каждый для себя решает сам. Лишним будет объяснять, что пароли необходимо хранить в безопасном месте.

Но чем безопаснее место, тем оно более труднодоступно. Необходим компромисс. Я рекомендую поступать следующим образом. Храните ваши пароли на бумажке! Бумажку с паролем запечатайте в конверт, а конверт снабдите печатями и подписями. Запечатанный конверт можно прикрепить к серверу, а копию хранить в сейфе руководителя, чтобы пароли при пожаре не сгорели вместе с сервером.

Такой способ хранения паролей удобен еще в нескольких ситуациях. Например, когда вас нет в офисе. Ну какие там пароли, когда вы занимаетесь сёрфингом где-то на Карибах, а вашему заместителю он вдруг понадобился? Это удобно еще и в случае, когда вам нужно сообщить пароль лицу, временно допущенному к администрированию. Например, для обновления такого ПО, как «Консультант+» или «1С». После того как конверт будет вскрыт и пароль станет известен кому-то, кроме вас, вы сможете сменить его, заново распечатать бумажку и опять сохранить в надёжном месте.

4. Изменения. Помните, что как бы ни была хороша ваша ИТ-инфраструктура, рано или поздно вы сделаете какие-нибудь изменения. Установите новое оборудование или программное обеспечение. Измените имя сервера или установите новый. Очень важно отслеживать подобные изменения и своевременно вносить их в план восстановления. Когда у вас будет правильно составленный план восстановления, чтобы не распечатывать его каждый раз при внесении изменений, вы можете использовать так называемый лист изменений. В нем можно отражать, кто, когда и какое именно изменение проделал. А подшить один листок гораздо проще, чем заново напечатать весь план.

5. Список лиц для оповещения. Также обязательно нужно включить список ответственных лиц и их телефонов, по которым необходимо звонить в случае ЧП. Это особенно актуально, когда в организации работает больше одного администратора и функции по обслуживанию оборудования, сети и ПО распределены.

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

6. Сценарии. Я рекомендую включать в план восстановления сценарии, которые могут произойти во время эксплуатации системы. Например, у вас могут быть заранее заготовлены планы на следующие случаи:

• потеря почтового сообщения;
• потеря почтовой базы данных;
• потеря группы хранения;
• потеря хранилища логов;
• потеря почтового сервера;
• выход из строя кластера;
• потеря контроллера домена Active Directory и/или сервера – обладателя роли глобального каталога;
• выход из строя всех почтовых серверов;
• выход из строя всех серверов компании в каком-либо филиале.

Список можно продолжать долго. Польза от подобных сценариев очевидна. Продумывая сценарии заранее, составляя план восстановления, вы прорабатываете в деталях каждую мелочь. Кроме того, чем масштабнее разрушения, тем дороже обойдутся меры по восстановлению. Рассмотрев заранее различные сценарии, вы сможете предметно объяснить руководству, сколько будет стоить восстановление в том или ином случае. А уж оно пусть само решает, насколько высока вероятность возникновения подобной ситуации и насколько это критично для бизнеса. Но не забудьте попросить ваших руководителей рассчитать, сколько стоит час простоя вашей организации. Иногда цифры говорят сами за себя.

И еще... Мало однажды определить все возможные сценарии. Мало разработать и составить детальное описание. Необходимо регулярно эти сценарии проигрывать. Например, можно на постоянной основе моделировать ситуацию с выходом почтового сервера из строя. Это позволит быть уверенным в том, что вы:

• все предусмотрели;
• ваших навыков достаточно для быстрого восстановления;
• изменения, происходящие в вашей ИТ-инфраструктуре, не привели к тому, что ваш план стал непригоден.

Однажды мне рассказывали, как одна крупная организация отрабатывала сценарий «Выход из строя всех серверов компании в филиале». Трудно поверить, но сотрудники компании выезжали в новый офис, разворачивали резервные серверы, проводили необходимые настройки и тестировали удалённое подключение сотрудников компании к серверам. Здорово, правда?

Тем более, с развитием виртуальных технологий вам совсем не обязательно рушить «боевые» серверы. Вы вполне можете иметь у себя виртуальную лабораторию, в которой смоделируете вашу реальную инфраструктуру, и делайте все, что захотите. Останавливайте серверы, разрушайте хранилища – и пробуйте все вернуть обратно.

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

Что же касается устройств чтения, то я часто оказывался в ситуации, когда устройства чтения, будь то CD-ROM или FDD, были забиты пылью и не только не читали информацию с носителей, но еще и портили их.

8. Буфферный склад. Готовясь к восстановлению, позаботьтесь о том, чтобы у вас был запасной, подменный фонд. Например, это могут быть отдельные запчасти или сервер целиком. Главное, чтобы в критический момент не оказалось, что вам необходимо заказывать вышедшее из строя оборудование со склада производителя.

С кем согласовать?

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

Обязательно нужно согласовать план с администраторами сети и операторами архивов.

Как и где хранить?

План восстановления обязательно нужно хранить в печатном виде, т.к. в критический момент вы можете не вспомнить, куда же запихнули этот файл или, что еще хуже, сам файл может оказаться на том самом сервере, который вышел из строя.

Распечатайте, подпишите у всех, с кем необходимо согласовать план, и поместите его в несгораемый шкаф. Главное, чтобы это было доступное для всего ИТ-персонала место.

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

На этом теоретическая часть окончена. Я надеюсь, что статья заставила вас задуматься над тем, насколько хорошо документирована ваша ИТ-инфраструктура. Насколько вы готовы к неприятным неожиданностям в виде выхода серверов из строя.

***

В следующих статьях мы поговорим о практике восстановления Microsoft Exchange Server. Я наглядно продемонстрирую процесс восстановления различных версий – от 2003 до 2010. Также я планирую подробно описать те сценарии восстановления, о которых упоминал в данной статье. От восстановления письма до восстановления кластера серверов. И обязательно уделю особое внимание восстановлению и обслуживанию базы данных. Именно база данных, в которой хранится вся почта организации (а зачастую не только почта, но и важные документы), доставляет больше всего хлопот системным администраторам. Поэтому очень важно знать, как проводить ремонт базы данных. Как делать дефрагментацию. Какие утилиты для этого использовать и т.д.

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