Симптомы:
Предположим, у вас есть Exchange 2010 с одной или несколькими Database Availability Groups и несколькими серверами в каждой из DAG. Вы настраиваете резервное копирование этих DAG при помощи DPM 2010 и выше (до 2012 R2 UR2 включительно). Через некоторое время, вы изменяете статус защищаемой копии почтовой базы с активного на пассивный или наоборот (например, переключаете активную копию базы на другой сервер в DAG). После этого, на странице Review disk allocation мастера создания/изменения групп защиты и в окне Modify Disk Allocation для баз, статус которых был изменён, вы будете получать ошибку:
"The operation failed because the data source VSS component {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7} is missing.
Check to see that the protected data source is installed properly and the VSS writer service is running.
ID: 915
Details: The operation completed successfully (0x0)”
If you’ll try to add such DB to secondary DPM server, you’ll receive same error at a disk size calculation step.
Если вы попробуете в этот момент добавить такую базу на вторичный сервер SCDPM, вы не сможете этого сделать из-за такой же ошибки в момент рассчёта дискового пространства.
Это известная Microsoft проблема, которая не будет исправлена в обозримом будущем.
Почему это происходит?
Информация о защищаемых ресурсах хранится в таблицах tbl_IM_DataSource и tbl_IM_ProtectedObject базы DPM. В столбцах ApplicationPath, LogicalPath и PhysicalPath содержится XML-документ, описывающий защищаемый ресурс. В случае с Exchange 2010 DAG он будет выглядеть примерно так:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<?xml version="1.0" encoding="utf-16"?> <ArrayOfInquiryPathEntryType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <InquiryPathEntryType Type="Domain" Value="example.com" /> <InquiryPathEntryType Type="Server" Value="DAGNODE2.example.com" /> <InquiryPathEntryType Type="ResourceGroup" Value="DAGNODE2.example.com" /> <InquiryPathEntryType Type="ApplicationNamespace" Value="Microsoft Exchange Replica Writer"> <Attribute AttributeName="Id" AttributeValue="{DDD34536-63D2-4F6C-98C1-2A4AD30D1EE4}" xmlns="http://schemas.microsoft.com/2003/dls/CmteCommonTypes.xsd" /> </InquiryPathEntryType> <InquiryPathEntryType Type="ApplicationComponent" Value="MAILDB01"> <Attribute AttributeName="LogicalPath" AttributeValue="Microsoft Exchange Server\Microsoft Information Store\Replica\DAGNODE2" xmlns="http://schemas.microsoft.com/2003/dls/CmteCommonTypes.xsd" /> </InquiryPathEntryType> </ArrayOfInquiryPathEntryType> |
Здесь мы видим:
DAGNODE2.example.com – имя узла DAG, с которого создаётся резервная копия почтовой базы
MAILDB01 – имя почтовой базы
Microsoft Exchange Server\Microsoft Information Store\Replica\DAGNODE2 – путь до копии базы на защищаемом сервере. Обратите внимание на слово “Replica”. Оно означает, что данная копия базы – пассивная. Если вы настроили резервное копирование для активной копии базы, эта часть пути просто будет отсутствовать.
При изменении статуса копии базы с активного на пассивный и наоборот, логический путь до почтовой базы на сервере меняется, но в DPM информация об этом не передаётся и в базе DPM остаются неконсистентные данные.
Решение:
Существуют 2 обходных пути (выбирайте любой, который больше вам подходит):
На стороне DPM:
- Остановить защиту проблемной базы, с сохранением данных.
- Добавить базу обратно в группу защиты. При этом DPM обновит данные в таблицах tbl_IM_DataSource и tbl_IM_ProtectedObject.
- После прохождения consistency check вы сможете свободно управлять выделенным для неё местом и добавить на вторичный DPM-сервер.
На стороне Exchange:
- Восстановить активный/пассивный статус базы в то же состояние, в котором она была при добавлении её в SCDPM:
- Если защищаемая копия базы была пассивной – сделайте её пассивной.
- Если же она была активной, то сделайте её активной опять.
Если необходимо, после изменения выделенного дискового пространства/добавления на вторичный сервер, вы можете опять изменить статус базы – на создание резервных копий это никак не влияет, только мешает изменению дисковых разделов.