Случилось неприятное: при замене одного из вышедших дисков в 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.
Все файлы – в корень выбранной папки.
Восстанавливаем целостность базы:
|
1 |
ESEUTIL /P C:\EXCHANGE\Mailbox_DB_33.edb |
Параметр /P спорный. Но в принципе можно было обойтись и более мягким способом.
Eseutil на базе примерно 150Гб работает 30-50 минут.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
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. После создания базу не монтируем.
Проверяем.
база может быть перезаписана при восстановлении:
база находится в корне определенной папки, туда же при создании базы было указано хранить логи:
Проверьте, пуста ли эта папка. Если база была только что была создана и еще не была подмонтирована, то эта папка будет пуста.
Теперь перемещаем базу. которая была обработана ESEUTIL вместе со всеми файлами в эту пустую папку.
Указываем имя EDB файла такое же, которое было при создании базы.
Монтируем базу.
Перенацеливаем ящики со старой. неисправной базы, на новую базу:
Старая база пусть имела имя Mailbox_DB_02, новая Mailbox_DB_02_02
|
1 |
Get-Mailbox -Database Mailbox_DB_02 | where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Set-Mailbox -Database Mailbox_DB_02_2 |
Все, ящики доступны
Запускаем команду обслуживания над нашей базой (база может быть в онлайн режиме):
|
1 |
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%, после чего акронис выдавал ошибку:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Не удалось восстановить контейнер документов. Дополнительные сведения: -------------------- Код ошибки: 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 Сообщение: Словарь не содержит значение с указанным ключом. -------------------- |
Ясно, что что то там не так.
Учитывая то что часть баз из этого бэкапа восстановилась без проблем, то считать бэкап “битым” я не мог.
Были попытки восстановить базу за другие периоды времени – безрезультатно.
Мой хороший друг и коллега подсказал сделать следующее: поставить галочку в дополнительных параметрах задания восстановление “проверять проверку резервных копий перед восстановлением”
Проверка заняла примерно 12 часов над 140Гб базой. после чего база восстановилась.
далее по описанной выше схеме база была восстановлена на одном из серверов и подключена.
Еще один момент.
Возможно что вы как системный администратор попытаетесь зайти на восстановленный почтовый ящик через OWA и у вас будет ошибка:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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 параметров безопасности пользователя:
Так же в конце рекомендую перестроить индекс с помощью командлета ResetSearchIndex.ps1
Скрипты находятся в папке
|
1 |
PROGRAMFILES%\Microsoft\Exchange Server\V14\Scripts |
запускаются через Power Shell так:
|
1 |
.\ResetSearchIndex.ps1 -force -all |
Процедура довольно тяжелая в плане нагрузки на сервера. Лучше делать ночью, когда сервера простаивают.
Как работает командлет можно прочитать в google по запросу ResetSearchIndex.ps1
или тут http://technet.microsoft.com/ru-ru/library/aa995966(v=exchg.80).aspx
Вроде все.
Удачи!
Товарищ, вы отличный боец)) А почему Acronis Backup с модулем Acronis for Exchange Server не помог? Не малых денег стоит между прочим))
На будущее совет организовать DAG и уже на Hyper-V.
Hyper-V хорошо конечно, но на нем частенько подвисают тяжелонагруженные виртуалки.
на голом железе таких проблем практически нет.
Спасибо
просто большое человеческое СПАСИБО за статью.
Спасибо большое автору этой статья, очень сильно выручил. При переносе Hyper-v закончилась база, сделал все как Вы описали и через 4 часа все поднялось. Удачи!