Exchange 2010: практика восстановление базы почтовых ящиков

restore-05Случилось неприятное: при замене одного из вышедших дисков в RAID массиве спустя непродолжительное время массив взамен файловой системы NTFS превратился в формат RAW. Немного почитав в интернете понял что массив скорее всего потерян вместе с данными.

Попытался перезагрузить сервер — масив все равно оставался в формате RAW.

На этот день у нас имелся бэкап базы почтовых ящиков выполненный с помощью программы «Acronis Backup 11.5» с модулем «Acronis for Exchange Server».

Далее все что происходило по времени.

Время — глубокая ночь.

Попытки восстановится с помощью Acronis сразу на другую, рабочую базу, ни к чему не привели.

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

Время — утро.

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

Запустил повторное восстановление баз которые смогли восстановиться, но в другое место.

Приехав на работу обнаружил что процесс восстановления завершился успешно.

Копирую файлы на Exchange сервер.

Копируем базу из бэкапа вместе с логами !!!
То есть, к примеру. в папку C:\EXCHANGE\ помещается и Mailbox_DB_33.edb и все файлы которые восстановил вместе с ним Acronis.
Все файлы — в корень выбранной папки.

Восстанавливаем целостность базы:

ESEUTIL /P C:\EXCHANGE\Mailbox_DB_33.edb

Параметр /P спорный. Но в принципе можно было обойтись и более мягким способом.

Eseutil на базе примерно 150Гб работает 30-50 минут.

 

C:\Windows\system32>ESEUTIL /P H:\Mailbox_DB_02_2\Mailbox_DB_02.edb

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.03
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating REPAIR mode...
Database: H:\Mailbox_DB_02_2\Mailbox_DB_02.edb
Temp. Database: TEMPREPAIR8332.EDB

Checking database integrity.

The database is not up-to-date. This operation may find that
this database is corrupt because data from the log files has
yet to be placed in the database.

To ensure the database is up-to-date please use the 'Recovery' operation.
Scanning Status (% complete)

0    10   20   30   40   50   60   70   80   90  100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Scanning the database.

Scanning Status (% complete)

0    10   20   30   40   50   60   70   80   90  100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Repairing damaged tables.

Scanning Status (% complete)

0    10   20   30   40   50   60   70   80   90  100
|----|----|----|----|----|----|----|----|----|----|

Deleting unicode fixup table.

Deleting MSObjids.

Deleting MSysLocales.
...................................................
Repair completed. Database corruption has been repaired!

Note:
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
repair, the database will be rolled back to the state
it was in at the time of that backup.

Operation completed successfully with 595 (JET_wrnDatabaseRepaired, Database cor
ruption has been repaired) after 1821.47 seconds.
C:\Windows\system32>

В принципе .если что потеряется — можно потом вытянуть из бэкапа, из исходного файла edb что нам восстановил Acronis.
Создаем новую базу, на сервере Exchange с определленными условиями:

1. Сам файл базы и логи нацеливаем в определенную папку

2.  обязательно указываем «база может быть перезаписана при восстановлении»

3. После создания базу не монтируем.

Проверяем.

база может быть перезаписана при восстановлении:

restore-01

база находится в корне определенной папки, туда же при создании базы было указано хранить логи:
restore-02

 

Проверьте, пуста ли эта папка. Если база была только что была создана и еще не была подмонтирована, то эта папка будет пуста.

Теперь перемещаем базу. которая была обработана ESEUTIL вместе со всеми файлами в эту пустую папку.

Указываем имя EDB файла такое же, которое было при создании базы.

Монтируем базу.

Перенацеливаем ящики со старой. неисправной базы, на новую базу:

Старая база пусть имела имя Mailbox_DB_02, новая Mailbox_DB_02_02

Get-Mailbox -Database Mailbox_DB_02 | where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Set-Mailbox -Database Mailbox_DB_02_2

Все, ящики доступны

Запускаем команду обслуживания над нашей базой (база может быть в онлайн режиме):

New-MailboxRepairRequest -Database "Mailbox_DB_02_2" -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview

Команда не выводит никакой информации о своей работе. Обычно занимает не более 0,1-1 го часа. о результатах работы создается событие в журнале Windows (EventID )

The output of New-MailboxRepairRequest will be a number of Event IDs with a source of “MSExchangeIS Mailbox Store” and you will need to watch for the following events related to a repair request“0044,10045,01146,10047,10048,10049,10050,10051,10059,10062”

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

Теперь возвращаемся к нашему Acronis и к тем базам которые не смогли восстановиться.

При попытке восстановления база восстанавливалась примерно на 20%, после чего акронис выдавал ошибку:

Не удалось восстановить контейнер документов.
Дополнительные сведения:
--------------------
Код ошибки: 20
Модуль: 91
LineInfo: 7edade4ed07d5220
Поля:  IsReturnCode : 1, $module : arx_agent_vs_38573
Сообщение: Не удалось восстановить контейнер документов.
--------------------
Код ошибки: 20
Модуль: 91
LineInfo: 7edade4ed07d5307
Поля:  IsReturnCode : 1, $module : arx_agent_fork_vs_38573
Сообщение: Не удалось восстановить контейнер документов.
--------------------
Код ошибки: 11
Модуль: 349
LineInfo: 1abf4823a4c53dd1
Поля:  $module : arx_agent_fork_vs_38573
Сообщение: Словарь не содержит значение с указанным ключом.
--------------------

Ясно, что что то там не так.
Учитывая то что часть баз из этого бэкапа восстановилась без проблем, то считать бэкап «битым» я не мог.
Были попытки восстановить базу за другие периоды времени — безрезультатно.

Мой хороший друг и коллега подсказал сделать следующее: поставить галочку в дополнительных параметрах задания восстановление «проверять проверку резервных копий перед восстановлением»

restore-03

Проверка заняла примерно 12 часов над 140Гб базой. после чего база восстановилась.
далее по описанной выше схеме база была восстановлена на одном из серверов и подключена.

Еще один момент.

Возможно что вы как системный администратор попытаетесь зайти на восстановленный почтовый ящик через OWA и у вас будет ошибка:

Request
Url: https://exch-cas:443/owa/forms/premium/StartPage.aspx
User: Иванова Мария
EX Address: /o=HOUSE/ou=First Administrative Group/cn=Recipients/cn=ivanova
SMTP Address: ivanova@myfirma.ru
OWA version: 14.3.123.3
Mailbox server: EXCH-MBX
Exception
Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException
Exception message: Cannot get row count.

Call stack

в Microsoft.Exchange.Data.Storage.QueryResult.get_EstimatedRowCount() в Microsoft.Exchange.Clients.Owa.Premium.Controls.FolderListViewDataSource.GetView(QueryResult queryResult, Int32 itemCount, Int32 currentRow) в Microsoft.Exchange.Clients.Owa.Premium.Controls.FolderListViewDataSource.Load(Int32 startRange, Int32 itemCount) в Microsoft.Exchange.Clients.Owa.Premium.Controls.VirtualListView2.LoadData(Int32 startRange, Int32 rowCount) в Microsoft.Exchange.Clients.Owa.Premium.MessageView2.CreateListView(ColumnId sortedColumn, SortOrder sortOrder) в Microsoft.Exchange.Clients.Owa.Premium.ListViewSubPage.OnLoad(EventArgs e) в Microsoft.Exchange.Clients.Owa.Premium.MessageView2.OnLoad(EventArgs e) в System.Web.UI.Control.LoadRecursive() в System.Web.UI.Control.LoadRecursive() в System.Web.UI.Control.LoadRecursive() в System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Inner Exception
Exception type: Microsoft.Mapi.MapiExceptionConversationNotFound
Exception message: MapiExceptionConversationNotFound: Unable to get table row count.

Call stack

в Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, SafeExInterfaceHandle iUnknown, Exception innerException) в Microsoft.Mapi.MapiTable.GetRowCount() в Microsoft.Exchange.Data.Storage.QueryResult.get_EstimatedRowCount()

Лечится это перемещением ящика в другую, «нормальную базу», командой New-MailboxRepairRequest или сбросом в AD параметров безопасности пользователя:

restore-04

Так же в конце рекомендую перестроить индекс с помощью командлета ResetSearchIndex.ps1
Скрипты находятся в папке

PROGRAMFILES%\Microsoft\Exchange Server\V14\Scripts

запускаются через Power Shell так:

.\ResetSearchIndex.ps1 -force -all

Процедура довольно тяжелая в плане нагрузки на сервера. Лучше делать ночью, когда сервера простаивают.

Как работает командлет можно прочитать в google по запросу ResetSearchIndex.ps1
или тут http://technet.microsoft.com/ru-ru/library/aa995966(v=exchg.80).aspx

Вроде все.

 

Удачи!

3 комментария

  1. Товарищ, вы отличный боец)) А почему Acronis Backup с модулем Acronis for Exchange Server не помог? Не малых денег стоит между прочим))
    На будущее совет организовать DAG и уже на Hyper-V.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *