Механизм обеспечения восстановления после катастрофичных сбоев или попросту катастрофоустойчивости (Disaster Recovery) в DPM 2010 реализован путём развертывания вторичного сервера DPM, являющегося хранителем реплики защищаемых данных первичного сервера DPM. Применение катастрофоустойчивой конфигурации необходимо для того чтобы застраховаться от следующих сценариев:
- Полная потеря первичного сервера DPM со всеми репликами защищаемых данных и всех его защищаемых клиентов.
- Потеря только первичного DPM сервера со всеми репликами защищаемых данных.
В первом случае вторичный DPM сервер будет выступать в качестве источника восстановления данных всех потерянных клиентов и при необходимости самого первичного DPM сервера. Во втором случае на время восстановления первичного DPM сервера, чтобы не прерывать цикл защиты данных, необходимо будет присоединить всех агентов DPM к вторичному серверу.
Настройка Disaster Recovery
Для того чтобы задействовать механизм катасторофоустойчивости существующего DPM сервера необходимо развернуть вторичный DPM сервер, имеющий дисковую конфигурацию, соответствующую по своему объему размеру той части данных первичного DPM сервера, которые мы хотим надёжно защитить.
Вообще стоит отметить тот факт, что нижеописанная процедура несколько отличается от в старой версии - DPM 2007.
В DPM 2010 процесс подключения вторичного DPM сервера упрощён до безобразия J
Итак, рассмотрим пример, когда мы уже имеем развернутый и работающий DPM сервер с именем KOM-AD01-BCP01. Для защиты этого сервера и всех его данных мы развернули вторую инсталляцию SC DPM 2010 на сервере с именем KOM-AD01-FS01, при этом мы физически расположили вторичный DPM сервер в другом здании, расположенном на другом конце города.
Открываем консоль администратора DPM 2010 на вторичном DPM сервере и запускаем мастер установки агента и выбираем для установки первичный DPM сервер.
После успешного завершения установки агента в консоли на вторичном DPM сервере на закладке Management – Agents появится наш первичный DPM сервер.
Теперь на закладке Protection вызываем мастер создания новой Protection Group (меню Action – Create protection group…)
На шаге Select Group Members развернём в дереве навигации первичный сервер DPM и выберем в области Protected Servers те сервера, данные которых мы хотим реплицировать с первичного сервера на вторичный. Также есть настоятельная рекомендация включить в Protection Group базу данных самого первичного DPM сервера – DPMDB. Об этом мы получим соответствующее уведомление при переходе на следующий шаг мастера создания Protection Group.
Если в перспективе потребуется восстановление первичного DPM сервера с помощью базы DPMDB, то это можно будет выполнить с помощью утилиты командной строки DpmSync. Порядок восстановления описан в статье Using DPMSync
Далее, в случае если мы используем для защиты группы хранения Exchange Server, нам потребуется выбрать запуск Eseutil а также определить порядок использования нод в кластере. Мы выбираем вариант защиты пассивной ноды, а случае её недоступности – активной ноды.
Далее, нам необходимо определиться с интервалом синхронизации с данными первичного DPM сервера, а также со сроком хранения этих данных. На первичном сервере DPM все оперативные резервные копии хранятся у нас в течение 30 дней, поэтому на вторичном сервере мы выберем это же значение. В силу того, что в нашу Storage Group входят базы данных SQL Server, нам будет предложено время создания полной резервной копии баз данных SQL (Express Full Backup). На самом деле в данном случае эта настройка является условностью, так как для создания Express Full Backup будет использоваться расписание заданное на первичном сервере DPM, и она может стать результативной только тогда когда первичный сервер DPM станет недоступен, а агенты будут перенацелены на работу с вторичным сервером.
На следующем шаге мы должны определиться с размерами создаваемых разделов . DPM самостоятельно рассчитывает их в зависимости от объема защищаемых данных, но из собственной практики использования вторичного сервера на DPM 2007 могу посоветовать сделать эти разделы такого же размера, как они сделаны на самом первичном сервере DPM.
После того как мастер завершит свою работу будет запущена первоначальная синхронизация защищаемых данных между первичным и вторичным сервером DPM.
Вообще в нашем примере, для простоты изложения, мы рассматриваем создание единой Disaster Recovery Protection Group, что само по себе не лучший вариант для применения на практике. Всё таки, я полагаю, что правильнее будет создавать Protection Group на вторичном сервере сообразно тому, как они сделаны на первичном сервере со сдвигом по времени таким образом, чтобы чрезмерно не нагружать первичный DPM сервер в одно и тоже время. То есть можно запланировать синхронизацию на то время, когда первичный сервер менее всего нагружен и не занимается выполнением большого количества заданий резервного копирования непосредственно с агентов.
Проверка работы Disaster Recovery
После успешного завершения синхронизации между DPM серверами, разумеется, мы должны выполнить проверку работы механизма катастрофоустойчивости. Для этого выключаем первичный DPM сервер, имитируя таким образом его недоступность при возможном сбое. Откроем консоль администратора на вторичном DPM сервере, перейдем на закладку Recovery и попытаемся вызвать процедуру восстановления данных на клиенте, который обслуживался агентом первичного DPM сервера. Если процедура восстановления при недоступном первичном DPM сервере пройдёт успешно, значит механизм Disaster Recovery работает как нужно. Вообще нужно понимать, что периодические манипуляции по тестированию работоспособности механизмов восстановления очень важны и должны являться обязательной составляющей любой системы резервного копирования.
Переключение защиты между серверами DPM
Как отмечалось ранее, в случае потери первичного DPM сервера можно выполнить перенацеливание резервного копирования на вторичный DPM сервер по каждому из объектов защищаемых данных. Сделать это можно, как показано на скриншоте, вызвав контекстное меню на соответствующем объекте защищаемых данных и выбрав пункт Switch disaster protection.
Если после краха первичного DPM сервера мы через какое-то время его восстановим, то таким же образом можно будет переключить защиту с вторичного сервера обратно на восстановленный первичный.
RSS - Записи
При удаленном расположении DPM1,DPM2 и источника данных т.е. когда у каждого из их свой внешний ip-адрес и связь только через WAN, по какой схеме нужно организовать vpn-туннели:полный треугольник или треугольник без одного катета? Из статьи логически следует вторая схема: треугольник без одного катета. Но тогода куда должен быть подключен DPM2? К DPM1 его нельзя подключать, потому что если DPM1 падает, то связь DPM2 с источником данных пропадает. Как же тогда правильно?
Схема подключения следующая: Источник данных -> Primary DPM -> Secondary DPM. То есть при штатном режиме работы задания резервного копирования с Источника данных выполняет непосредственно Primary DPM. Переключение Источника данных на Secondary DPM через описанную опцию "Switch disaster protection" потребуется лишь в случае недоступности Primary DPM. При этом как вы понимаете вам потребуется туннель Источник данных -> Secondary DPM. То есть если речь идет о том как лучше сделать на перспективу, то я бы конечно сделал "треугольник", чтобы в случае краха Primary DPM можно было без особых излишних манипуляций оперативно выполнить "Switch disaster protection".
Спасибо за хорошую статью!
А альтернативные методы защитить дпм есть? При отсутствии 2 сервера.
Если речь идёт о защите БД самого сервера DPM, то вполне можно посредствам встроенных механизмов SQL Server делать резевную копию базы данных DPM в отдельное месторасположение. И в случае, если например сам сервер DPM упадёт, а хранилище реплик при этом останется живым, для восстановления распотоспособности сервера DPM с подключением всех сохраненных реплик, можно будет воспользоваться статьёй Repairing DPM 2010 http://technet.microsoft.com/en-us/library/ff399388.aspx
Спасибо за статью! А в чем преимущество использования Disaster Recovery перед DPM Chaining?
Насколько я понимаю, DPM Chaining полезен в случае когда нужно организовать цепочку хранения разных данных на разных DPM серверах, с возможностью использования Disaster Recovery между двумя соседними серверами DPM в цепочке. Механизм Disaster Recovery служит для быстрого переключения владением копией между двумя конкретными DPM серверами, не входящими в большую цепочку. То есть сравнивать эти технологии не совсем правильно, так как они по своей сути являются сущностями разных категорий.
Дополнительно можно почитать по ссылкам:
System Center TechCenter Library - Setting up DPM Chaining - http://technet.microsoft.com/en-us/library/gg410636.aspx
System Center TechCenter Forum - Chaining DPM Servers - http://social.technet.microsoft.com/Forums/en/dataprotectionmanager/thread/f5aa64dd-0400-4a9b-bb12-130a0ef44416
System Center TechCenter Forum - Backing up DPM 2010 to another DPM 2010 server - http://social.technet.microsoft.com/Forums/en-US/dataprotectionmanager/thread/df80faa5-bf65-405e-bee2-47be8a41206d
Благодарю за ответ!
Здравствуйте!
Disaster Recovery это конечно хорошо. А возможно ли поднять вторичный сервер DPM, который будет использовать общее хранилище с оcновным DPM ? Использовать дополнительное дисковое пространство ради бэкапа бэкапа...это довольно накладно при больших объемах.
Использовать одно хранилище - нет. Этого никто и не декларировал. Вторичный DPM сервер можно рассматривать не только как "бэкап бэкапа" но и как самостоятельную систему резервного копирования. И если вероятность потери единственной резервной копии для Вас важный момент, то надо использовать именно Disaster Recovery в таком виде в котором он предполагается к использованию.
Ясно, спасибо!
Здравствуйте, Алексей.
Начал реализовывать описанную вами схему в ответе на мое первое послание, но все же остановился на варианте тереугольник без одного катета. Т.е. VPN-туннели соединены так: Главный DPM--Источник--Вторичный DPM. Под источником у меня целая локальная сеть с пограничным фаерволом, за ним контроллер домена и собственно SQL-сервер с которого резервируются данные. Так вот, все получилось! Вторичный DPM теперь у меня резервирует как базу первичного, так и базы самого SQL-сервера. Правда мне показалось, то что базы SQL-сервера резервируются на вторичный DPM напрямую, а не с первичного DPM, как я предполагал. Такое ощущение у меня создалось от того, что при создании группы защиты на вторичном DPM,на этапе подсчета дискового пространства у меня вначале выдавалась ошибка RPC о том, что DPM не видит агента на SQL-сервере, что было странно т.к. первичный DPM его видел в этот момент. Ошиба исчезла, когда я поправил правила на фаерволе.
Спасибо за ваши рекомендации.
Алексей, после реализации мной Disaster Recovery я заметил одну особенность при создании группы защиты на вторичном DPM. При раскрытии каталога защищаемых серверов нижним уровнем защиты файлов являются тома. Дерево тома нет возможности раскрыть, чтобы защитить конкретные папки тома как это сделано на главном DPM. Нет таже уровня общих папок. Почему? Получается,что глубина защиты у главного и вторичного DPM разные?
Дело не в глубине защиты а в том, что на вторичном DPM вы фактически защищаете не сам источник а его копию с первичного DPM. И поэтому вы сможете видеть только те диски с которых делается резервное копирование на первичный DPM. Например если на защищаемом сервере есть тома C,D,E и на первичном DPM включена защита только тома D, то на вторичном DPM вы сможете отмечать для защиты только том D. Полагаю что возможность включения защиты всех ресурсов на вторичном DPM может возникунть только при переключении (Switch Disaster Protection), то есть когда для этого конкретного сервера-агента вторичный DPM по сути станет первичным. Немного сумбурно, но смысл я думаю ясен.
Спасибо.
Т.е. я правильно вас понял, что даже если я на вторичном DPM отмечу галочкой том С защищаемого первичным DPM сервера, то бэкапироваться будут только те папки тома С, которые бэкапируются первичным DNS, а не весь том занимающий несколько сотен гигабайт?
Да.
Обратная ссылка: Отделяем трафик резервного копирования System Center 2012 DPM | ИТ Блог Алексея Максимова /