Про Disaster Recovery вспоминают не часто, но запоминается надолго..
Сбой телефонии сам по себе чувствителен для организации, а потеря всех настроек настоящая катастрофа.
В системе Cisco CUCM настроить автоматическую архивацию очень не сложно - уделите 30 минут своего времени. Вы даже можете не пробовать тестовое восстановление - благо сам процесс не так заморочен как например у Microsoft. Вы всегда можете воспользоваться статьёй по восстановлению или сходив на cisco.com наконец, но ежедневные и месячные бэкапы иметь под рукой надо, а также регулярно проверять их статус.

Выполните рекомендации данной статьи, и можете чувствовать себя защищённым.

Для архивации в CUCM используется Disaster Recovery System (DRS), - компонент, который настраивается и запускается непосредственно из админки.
DRS позволяет производить автоматические и ручные бэкапы.
DRS производит бэкапы cluster-level, что означает что в бэкапе будет находиться вся информация со всех серверов кластера.

DRS включает в себя два основных компонента:
- Master Agent (MA). Обеспечивает централизованные функции, например запуск scheduled tasks. Запущен как сервис на всех нодах, но реально функционирует только на Publisher.
- Local Agent (LA). Непосредственно осуществляет архивацию и восстановление. Запущен и функционирует на всех нодах.

Настройка архивирования через freesshd.exe

В качестве сервера для архивирования используем Windows2003

Создаем на сервере директории:

Устанавливаем на Backup-сервер приложение freesshd.exe
- выставляем директорию в SFTP
- выставляем локального пользователя в Users: Если это standalone server, можно выбрать тип юзера "password stored in sha1" или "NT auth". В случае контроллера, проходит "password stored in sha1".

Для apply перезапускаем сервис

Настройка архивирования на SCP Server от Solarwinds

Исходный файл: SftpServerInstaller.msi

После установки при первом запуске мы увидим следующее окно:

Выставляем рабочую директорию:
File > Configure > General > SFTP_Root
Вообще при установке такая папка уже должна была создаться, либо можно выбрать какую-то свою.

Создаём пользователя для работы с SCP:
File > Configure > General > Users > New user
Нужно задать лишь имя и пароль.

Запускаем сервис:

Настройка архивирования на CUCM

Далее идем в «Система восстановления после сбоев»
Backup -> Bakup Device
Создаем для двух типов бэкапа:

Создаем два Scheduler для ежедневных и ежемесячных копирований

И, конечно, мы всегда можем сделать ручное архивирование, выбрав:
Backup -> Manual Backup

Проверка статуса архива

Откройте файл *_drfComponent.xml:

Ннас интересует раздел Status. Если мы видим SUCCESS, то с данным архивом всё в порядке.

Рекомендация

При восстановлении нужно чтобы совпадал ряд параметров:
- hostname
- IP address
- Product version (имеется в виду Windows или Linux)
- deployment type (publisher/subsriber)

Также нужно будет вводить и другие. Чтобы было меньше вопросов в стрессовой ситуации, рекомендуется снять эти параметрыс живой системы и сохранить скриншотом:
Чтобы узнать все нам нужные параметры, на каждом ноде достаточно дать следующие команды:
show status
show network eth0
show timezone config
utils ntp config

Восстановление

В данной статье восстановление рассматривает лишь вскользь.
Подробный материал смотрите Настройка Cisco Unified Comunications с нуля. Практика07: Полное восстановление кластера CUCM 8.6 из архива
Для восстановления нужно знать cluster security password (или System security password), см. Пошаговая начальная установка CUCM 8.x на ESXi 5.1

Для успешного восстановления у CUCM и бэкапа должно совпадать:

- hostname
- IP address
- Product version (имеется в виду Windows или Linux)
- deployment type (publisher/subsriber)

Сверка версий бэкапа и CUCM

Бэкап выглядит следующим образом:

Для определения версии бэкапа
Откройте файл *_drfComponent.xml, там есть строчка 7.1.5.33900-10

Для определения версии CUCM
идем на первую страницу, или выбрав:
CUCM Administration > Help > About

Для определения hostname CUCM, IP address, deployment type

Зайти на:
Cisco unified OS administration > Show > Cluster

Здесь только нужно иметь в виду что hostname - это Alias, т.е. в нашем случае hostname - cucm861, а ciscomaster.ru - DNS домен

В документации восстановление описывается по следующим сценариям:
- Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild)
- Restoring the First Node only (Rebuilding the Publisher Alone)
- Restoring the Entire Cluster
- Restoring Subsequent Cluster Nodes (With or Without Rebuild)

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

Откат кластера

Это в доументации называется Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild)
Данное восстановление практикуется в случаях, когда "наконфигурячили" в настройках и нужно откатиться назад, т.е. сами сервера "живые" но система в целом работает неудовлетворительно из-за ошибок в конфигурировании, а вспомнить "а что ты делал час назад" или "верни все как было" не получается.

- Идем в Disaster Recovery System > Restore > Restore Wizard
Для логина следует использовать учетку Operating System Administrator
- Выбираем Backup device (после нажатия next система полезет в папку за бэкапами)
- Выбираем один из доступных архивов.
- Выбираем integrity check, а также Publisher node
- Жмем Restore

При этом надо понимать, что выбор Publisher node влечет за собой восстановление всего кластера.

В ходе восстановления можно следить за его статусом через:
Disaster Recovery System > Restore > Status

После восстановления следует перезагрузить весь кластер, причем сначала следует перегрузить Subscribers, и только после Publisher
Cisco Unified OS Administration > Settings > Version > Restart

После перезагрузки кластера проверьте статус репликации:
Определение статуса Call Manager CUCM