Процедура, название которой вынесено в заголовок, выполнена. А теперь подробнее.
Текущая установка DPM включает в себя:
- сервер DPM 2012 SP1 (назовем его dpm)
- сервер баз данных, на котором крутится база самого DPM 2012 SP1 (назовем его sql).
Задача - обновить сервер DPM 2012 SP1 до DPM 2012 R2 с одновременным переносом базы данных с сервера sql на сервер dpm. Перенос базы данных необходим для того, чтобы не потерять информацию о бекапах на дисках DPM (disk-based backup), все остальное восстановимо с лент, которые можно импортировать. Версия SQL значения не имеет, но для облегчения процесса будет установлен SQL 2012 SP1.
В процессе сбора и активации граблей (а их примерно дофига) очень сильно помогла статья Обновляем System Center 2012 SP1 Data Protection Manager до уровня System Center 2012 R2 и перебираемся на Windows Server 2012 R2 и SQL Server 2012 SP1, и за нее авторам оной мои почет и уважение. Но даже там были расписаны не все грабли, на которые можно наступить. Для более полного понимания процесса настоятельно рекомендую ознакомиться с ней, потому что кейс, описанный в статье, еще более объемный, чем моя задача.
Итак, что пришлось выяснить мне.что пришлось выяснить мне.
0. First and Foremost. Бекап. Бекап базы данных DPM - наше все. Если его не сделать, или сделать неправильно, задача будет провалена уже на старте. И лучше, если этих бекапов будет несколько, чуть ли не после каждой стадии обновления, чтобы можно было откатиться на шаг назад, а не потерять всю рабочую нагрузку. Аналогично для бекапов самой рабочей нагрузки - на всякий случай они должны быть и на лентах, а не только на дисках (вы же используете D2D2T бекапы, правда?)
1. Простой настройки в DPM вида "Искать базу вот тут" не существует. Единственный поддерживаемый способ смены расположения базы данных - полная переустановка всего DPM.
2. При переустановке DPM в любом случае создает новую базу данных. Так что сначала создать базу из резервной копии, а потом на нее "натянуть" установку DPM нельзя. Сначала ставим DPM, он создает новую базу со всей необходимой структурой, затем туда загружаем данные из резервной копии.
3. Наверное, самое важное. Версия DPM на момент снятия бекапа его базы данных, и версия DPM на момент попытки восстановления базы данных должны совпадать. Самый простой способ это сделать - до снятия бекапа базы обновить текущую установку DPM до самого последнего доступного Update Rollup, после чего записать Build Number, и только потом сносить DPM и ставить начисто.
Ну а теперь - то, что пришлось сделать, и на оттачивание чего ушла неделя (слава виртуализации и снапшотам).
0. Как и говорил - бекап. Их много не бывает. Создание резервной копии базы данных DPM до начала работ не занимает много времени, а нервов может сберечь очень много.
1. База данных в DPM 2012 SP1 имеет структуру, отличную от базы DPM 2012 R2. Следовательно, сначала нам нужно обновить саму базу до состояния R2. А сделать это можно, обновив сервер dpm прямо поверх имеющейся установки. Этот процесс не слишком сложен. Нужно лишь для начала запустить на сервере sql инструменты подготовки удаленного SQL-сервера, находящиеся в дистрибутиве DPM 2012 R2. На стартовом экране установщика DPM они называются Remote SQL Prep. Установка занимает считанные секунды и не требует перезагрузки SQL-сервера. А после подготовки сервера sql запускаем мастер установки DPM 2012 R2 на сервере dpm и следуем его указаниям.
После завершения работы установщика текущая конфигурация примет следующий вид:
dpm - сервер DPM 2012 R2
sql - сервер SQL c обновленной базой
2. Обновляем DPM 2012 R2 до самого последнего Update Rollup. На текущий момент, да и наверное, уже навсегда, это UR 14. После завершения установки проверяем Build Number самого DPM. Он должен быть таким: 4.2.1603.0
3. После обновления самого сервера DPM необходимо обновить агенты на защищаемых серверах. Как именно это делать - путем запуска обновления из консоли DPM или сначала снести агентов вручную, а затем начисто поставить заново - на усмотрение конкретного администратора. Обновление может потребовать перезагрузку, в моем случае требовало. Ручной снос на стадии тестирования - не требовал, но гарантировать, что так будет всегда я не могу.
4. Резервное копирование. На стадии подготовки (а все вышеуказанное - именно подготовка) - это самый важный этап. Именно сейчас мы замораживаем нашу базу данных, и именно это ее состояние будет восстановлено на новом сервере. Здесь (и на стадии восстановления) особо.
Для резервного копирования базы данных Microsoft рекомендует использовать утилиту dpmbackup, входящую в состав самого DPM. В версии DPM 2012 SP1 с ней можно было работать, хотя интернет в свое время, похоже, был завален вопросами о ее ошибке, относящейся к ключу -db. Указание этого ключа и еще нескольких других инструктирует утилиту создать резервную копию базы данных DPM. Проблемы с утилитой возникли после ее обновления в DPM 2012 R2. И выражаются они в следующем:
Я НЕ СМОГ ЗАСТАВИТЬ ЕЕ РАБОТАТЬ НИ ПОД КАКИМ ВИДОМ.
Ни одна комбинация ключей этой утилиты не смогла создать резервную копию базы данных, а ответом всегда было одно и то же: неверно указан ключ -db
Позволю себе немного негатива. Я бы очень хотел посмотреть в глаза тому человеку, который ее написал. Пристально так посмотреть. А то, что проносилось бы у меня в этот момент в голове, я предпочту опустить.
Поэтому утилиту dpmbackup лично я отставил в сторону, и обратился к старой доброй SQL Management Studio. Там все просто - выделить нужную базу данных, выбрать пункт Backup, указать, в какой файл сохранить резервную копию, нажать ОК, дождаться окончания процесса.
5. Установка сервера dpm начисто. Достаточно тривиальная последовательность шагов - установка и обновление ОС, установка и настройка на этом же сервере СУБД (обязательно спросить у DBA, какие правила сопоставления - Collation - использует сервер sql, так как нужно указать их же), установка самого DPM 2012 R2. Особо расписывать здесь нечего, инструкций в сети немало.
6. Обновление DPM 2012 R2 до того самого Update Rollup 14. Абсолютно необходимый этап, потому что, как и было ранее указано, нам нужна точно такая же версия DPM, какой она была на момент снятия резервной копии базы данных. После обновления убеждаемся, что Build Number принял вид: 4.2.1603.0
7. Подключаем серверу dpm те диски, что раньше использовались для disk-based backup, импортируем их. И больше с ними ничего не делаем.
8. Восстановление базы данных. Ровно так же, как это было с этапом резервного копирования базы данных, с этапом восстановления у меня было свзяано максимальное количество граблей. А суть их ровно так же, что и с резервным копированием: для восстановления базы данных Microsoft предлагает использовать другую утилиту, на этот раз это DPMSync со своим набором ключей. И в лучших традициях использования таких утилит при малейшей попытке ее использования я получал ошибку выполнения и неработоспособный DPM.
Что делать? Снова воспользоваться SQL Management Studio и выполнить восстановление именно там. Для этого открываем SQL MS, выбираем там базу данных DPM, выбираем восстановление базы данных (именно базы данных, а не файловой группы этой базы данных) и в окне выбора параметров восстановления выполняем следующие действия именно в описанном порядке:
- Options - Restore Options: отмечаем галкой Overwrite existing database (With Replace)
- Options - Server Connections - отмечаем галку Close existing Connections to destination database
- General - выбираем файл с резервной копией базы данных DPM, выбираем цель восстановления - базу данных DPM, расположенную на этом сервере
И затем подтверждаем восстановление кнопкой ОК.
9. Синхронизация DPM 2012 R2 с восстановленной базой данных. Для этого на сервере dpm в открытой от Администратора командной строке вводим следующее:
В процессе выполнения среди прочего DPM обнаружит ранее импортированные динамические диски, на которых располагаются все disk-based резервные копии рабочей нагрузки и проведет сопоставление их идентификаторов.
После выполнения этого шага DPM 2012 R2 будет работать с базой данных, в которой есть все те сведения, что были в базе данных еще на сервере sql. Основная часть работы на этом выполнена. Дальше остается мелочь (по сравнению с тем, что уже было сделано).
10. Повторная привязка агентов на защищаемых серверах. Поскольку текущая версия DPM совпадает с той, что у нас была до сноса и переустановки сервера dpm, обновление агентов, оставшихся на защищаемых серверах не требуется, нужно лишь связать их с текущей установкой DPM. Для этого на защищаемом сервере открываем от Администратора командную строку и вводим следующее:
где dpm - имя нашего текущего DPM-сервера
После этого необходимо уже на сервере dpm подтвердить привязку агента. Для этого в DPM Management Shell вводим:
Этот скрипт поочередно запросит имя текущего DPM-сервера (нужно указывать FQDN), имя защищаемого сервера (так же FQDN), имя учетной записи с полномочиями администратора (только имя, без домена), сам домен (памятуя об ошибке на стадии установки DPM я вводил NetBIOS-имя). Собрав все эти сведения скрипт привяжет агент на защищаемом сервере к указанному серверу DPM 2012 R2.
11. Последним этапом станет работа с группами защиты, дисковыми репликами и ленточной библиотекой или библиотеками, если их много. Потребуется проверка параметров групп защиты в части работы с ленточными накопителями, синхронизация дисковых реплик с источниками данных. Возможно, одновременно с этим захочется пересмотреть что-то в плане резервного копирования рабочей нагрузки. По сравнению с проделанной ранее работой - это уже отдых.
На этом все.