IT-блог компании "ЛанКей"

Недавно к нам обратилась одна компания с просьбой восстановить Exchange Server. В компании работает около 500 человек. Занимается компания бизнесом в Интернете. Можно себе представить насколько критичным для данной компании является сервис электронной почты, куда приходят все заказы от клиентов, и происходит общение между сотрудниками.

В тот момент, когда компания обратилась за помощью к нам, почта уже не работала 2 дня, руководство было в панике. Самое плохое, что всё это время системные администраторы пытались восстановить работоспособность почтового сервиса самостоятельно, и как всегда это бывает, лучше бы они ничего не делали! И почему за помощью к специалистам обращаются не начальном этапе, а когда уже всё находится в полной {nslookup 83.102.180.3}?)

В компании был только один Exchange Server 2007 Standard Edition, на котором располагались все ящики пользователей. Ящики большего числа пользователей были распределены по 2-м базам данных, каждая по 250 ГБ. Было также ещё 2 MailBox Store для руководства и 1 Public Folder Store. Резервное копирование выполнялось при помощи Acronis True Image Echo Enterprise Server, который выполнял снимок всего диска.

Пролог

Итак, что же случилось? Хронология событий такая: В одну прекрасную ночь в офисе компании выключили свет, UPS продержал сервера 1 час, затем PowerChute начал завершать работу операционных систем, но Exchange Server завершить работу не успел, и UPS выключился. На утро системные администраторы включили сервера, и обнаружили, что Exchange Server не подмонтировал 2 самые большие базы данных, в которых находились ящики 250 пользователей. Попытки смонтировать БД вручную не увенчались успехом, ввиду их физического повреждения, несмотря на то, что БД размещались на массиве RAID 10 (плохо, что вместе с логами транзакций). Далее системные администраторы решили вытащить базы данных из резервных копий Acronis-а. Который сказал, что процесс восстановления будет завершён через 10 часов. Руководство сказало, что это слишком долго и нужно сделать так, чтобы пользователи смогли получать хотя бы новые письма, пока идёт процесс восстановления. Этот метод называется Dial-tone Recovery.

Но то ли системные администраторы не очень внимательно читали документацию, толи не так её поняли, но сделали они всё примерно так: Они решили создать новую БД, чтобы переместить в неё всех пользователей. Запустили Exchange Management Console перешли в раздел Server Configuration\Mailbox, создали новую БД и попытались её смонтировать, на что получили ошибку. Они долго разбирались в природе этой ошибки и затем поняли, что ошибка была вызвана тем, что они пытались смонтировать 6-ю БД в Exchange Server Standard, который поддерживает только 5! Следующим их действием стала попытка удалить повреждённую БД, которая тоже не увенчалась успехом, потому что в этой базе были ящики пользователей и её нельзя удалять (точнее Exchange не даёт этого сделать)! Эта ситуация вогнала системный администраторов в небольшой ступор (и лучше бы они в нём и оставались), так нет же, среди них нашёлся один знаток Active Directory, который вызвался помочь. Он взял и удалил базы данных сервера Exchange через ADSIedit.msc. Радостные и благодарные ему системные администраторы Exchange, создали 2 новые БД, и смонтировали их. Этот процесс естественно прошёл успешно.

Но их радость очень быстро закончилась! Когда администраторы попытались переместить пользователей в новые пустые БД, то столкнулись с новой «проблемкой». При открытии консоли Exchange Management Console > Recipient Configuration > Mailbox, при открытии любого ящика стала выдаваться ошибка The properties on User have invalid data. А командлеты Get-MailBox и Move-Mailbox выдавали ошибку Object Domain/OU/User has been corrupted and it is in an inconsistent state. Database is mandatory on user MailBox.

В этот момент системные администраторы поняли, что дела совсем плохи, надежд больше нет и лучше приложить все усилия к написанию нового резюме! В конце концов, руководство решило обратиться за помощью к сертифицированному партнёру Microsoft, в компанию «ЛанКей».

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

Восстановление.

Часов через 10 восстановились базы данных недельной давности, из Acronis-овского бэкапа. Но ни одна из них не стала монтироваться. Ещё раз убеждаемся в том, что Acronis не умеет резервировать Exchange Server и все БД были в состоянии Dirty Shutdown. Хотя базы данных были зарезервированы вместе с логами, но чтобы выполнить софт-рековери, логов в архиве не хватало. Пришлось восстанавливать базы данных при помощи eseutil /p. На каждую базу данных потребовалось ещё 5 часов восстановления. После этого базы смонтировались. На всякий случай, мы также запустили проверку логической структуры при помощи isinteg.

Теперь мы должны были разобраться с тем, что ящики пользователей нельзя было ни переместить, ни восстановить. Проанализировав ситуацию, мы выяснили, что у всех пользователей был удалён атрибут homeMDB, точнее был удалён не сам атрибут, а его значение. В тестовых целях, мы восстановили данный атрибут у одного из пользователей вручную через ADSIedit.msc. И теперь мы могли перемещать и восстанавливать ящик данного пользователя. Но восстанавливать значения этого атрибута у 500 пользователей было бы довольно трудоёмкой задачей. Поэтому мы решили как-то автоматизировать данный процесс. Первым в голову конечно же пришло использовать Power Shell. Но командлеты для управления Active Diretory появились только в Windows Server 2008 R2, здесь же вся инфраструктура была построена на Windows Server 2003. Но выход был найден, мы решили использовать PowerShell Commands for Active Directory от Quest Software http://www.quest.com/powershell/activeroles-server.aspx (спасибо Ярославу за подсказку).

Для задания атрибута homeMDB, использовался командлет:
Set-QADUser user_name -ObjectAttributes @{HomeMDB=’FQDN_базы’}

Теперь оставалось задать соответствующий атрибут каждому пользователю. Но не всё оказалось так просто. Ведь у нас было 2 базы данных и 250 пользователей, и нет никакой информации о том, какой пользователь в какой БД размещался. И соответственно непонятно какой атрибут, какому пользователю присваивать. Мы задались вопросом: как выяснить, какой пользователь, в какой базе находился? Ведь в Active Directory эта информация была стёрта. Единственное место, где эта информация осталась – это сами базы данных. И вытащить её оттуда можно было при помощи командлета Get-MailboxStatistics.

Поскольку Get-MailboxStatistics – является командлетом Exchange, а Set-QADUser – является командлетом Quest. Нужно было подгрузить обе оснастки в один сеанс PowerShell, для чего использовали командлет Add-PSSnapin. Итак, для задания атрибута homeMDB для пользователей из db1 использовали следующий скрипт:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\First Storage Group\db1 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db1,CN=First Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

Аналогичный скрипт для задания атрибута homeMDB для пользователей из второй БД:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\Second Storage Group\db2 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db2,CN=Second Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

После перезапуска службы Information Store пользователи успешно подключились к своим ящикам, но ни получение ни отправка почты не работала. Мы обратили внимание на то, что служба HUB Transport не работает. После запуска её вручную, она сразу же останавливалась. Как мы выяснили, была повреждена база данных почтовой очереди, которая располагается здесь: C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que.
Чтобы не потерять почту, которая успела попасть в очередь, мы решили восстановить эту БД при помощи eseutil:

eseutil /p c:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que

После восстановления этой БД, служба HUB Transport запустилась и заработала. Пользователи начали получать новую почту.

PS1:

На самом деле процесс восстановления был немного сложнее, чем описано выше. Просто лень много писать, да и про метод Dial-tone Recovery подробно написано на technet. В кратце:

На время восстановления мы переместили всех пользователей во временные пустые БД, потом восстановили БД из резервных копий, заменили ими новые БД. Затем новые БД смонтировали в Recovery Storage Group и слили всю почту, полученную во время восстановления, с восстановленными из архива ящиками.

PS2:

Немножко размышлений:

• Как нам потом доложили, сбой почтовой системы вылился компании в 2 млн. рублей убытков. Интересно учитывал ли кто-нибудь эти деньги при проектировании почтовой системы и разработке политики резервного копирования? Было ли это прописано в SLA?
• Ведь спасти от такого сбоя могла простая SCR репликация, которая обошлась бы примерно в дополнительные 150 000 р. И восстановление заняло бы максимум пол часа. Хотя можно было бы подумать и о внедрении CCR кластера, который всё равно бы обошёлся раза в 2 дешевле, понесённых убытков.
• Резервировать Exchange Server 2007 нужно поддерживаемыми средствами резервного копирования, такими как Symantec BackUp Exec, Microsoft Data Protection Manager, ну или на худой конец ntbackup. Даже Windows  Backup из состава Windows Server 2008 уже поддерживает резервное копирование Exchange Server 2007 (sp2). Эти средства резервного копирования правильно подготавливают базу данных Exchange к процедуре резервирования, закрывают базу на запись, и после завершения резервного копирования, удаляют логи. Используемое в данном случае средство резервного копирования, неправильно резервировало БД Exchange, что привело к дополнительным 10 часам простоя.
• Также в данном случае большой ошибкой стало то, что логи транзакций размещались на одном и том же диске с базами данных, и поэтому было потеряно всё разом.
• Кроме того,  помимо еженедельного полного резервного копирования, было бы неплохо выполнять ежедневное добавочное. В данном случае произошла бы потеря почты только за один день, а не за неделю.

PS3:

История полностью вымышленная, любые сходства с реальным миром, простые совпадения!