Квалифицированное проведение операций резервного копирования и восстановления системы WNAM особенно важно при её эксплуатации в ответственных задачах: корпоративная авторизация, нагруженный гостевой доступ.

Работающая система WNAM состоит из следующих компонентов:

Данные ОС, самой системы WNAM меняются сравнительно редко. Лог-файлы критически важных данных не содержат; система будет работать и без них.

Основные настройки системы находятся в базе данных: конфигурация, списки пользователей, статистика. Поэтому основным направлением резервного копирование должно быть копирование базы данных.

Внимание! Здесь приводятся только общие рекомендации по резервному копированию и восстановлению системы WNAM.

Конкретный способ, который вы будете применять, определяется форматов развертывания вашей системы, наличием средств и ресурсов резервного копирования, политикой предприятия, и другими факторами. 

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

Веб-интерфейс WNAM целенаправленно не содержит каких-либо кнопок и пунктов меню, касающихся копирования и восстановления. Дело в том, что при возникновении каких-либо системных проблем, этот интерфейс скорее всего будет недоступен администратору. Предполагается, что и резервирование, и восстановление из резервной копии, квалифицированный администратор будет делать из командной строки сервера WNAM, путём ручного запуска команд и скриптов.

Для конфигураций WNAM, не содержащих в своём составе кластерной установки MongoDB, рекомендуется выполнять резервное копирование средствами системы виртуализации (снапшоты, Veeam Backup и т.п.) раз в сутки. Резервируется вся виртуальная машина целиком, включая СУБД. Этот сценарий подходит и для кластеров WNAM, сделанных на основе Kafka (с отдельными экземплярами MongoDB на узел WNAM).

Для конфигураций WNAM, содержащих в своём составе кластерную установку MongoDB, резервное копирование средствами системы виртуализации делать можно, за исключением СУБД. Если в резервную копию попал снапшот узла кластера MongoDB, вы обязаны при восстановлении такой резервной копии удалить базу (включить сервер без сети), и только потом заново вводить удел в кластер MongoDB. В противном случае база MongoDB гарантированно развалится, так как будет нарушена синхронизация её узлов (нод) во времени. 

Делать резервную копию WNAM, и восстанавливать сервер со старой резервной копии, для самого приложения WNAM безопасно. 

При использовании ADCTool, некоторые каталоги содержать kerberos-тикеты, которые истекают со временем. Весьма вероятно, что при восстановлении сервера, который был долго отключен, тикеты истекут, и вам понадобится заново подключить сервера в домен. 

Рекомендуется, помимо резервирования средствами виртуализации, делать периодические резервные копии базы данных, установив в cron ночной запуск шелл-скрипта следующего содержания:

rm -rf /backup/wnam_db
mongodump -d wnam_db -o /backup
mv /backup/wnam_db /backup/wnam_db_`date +"%d-%m-%Y"`

Крайне желательно, чтобы раздел /backup/ находился на физически другом жёстком диске.

По завершении операции создания дампа базы данных рекомендуется утилитами scp, rsync провести копирование этого дампа (в архиве или без) на другой Linux-сервер, находящийся на другой площадке (в другом ЦОД). Это может быть и второй сервер распределенного кластера WNAM.

Обязательно настройте мониторинг ваших серверов WNAM, по загрузке процессора и диска, и настройте отправку уведомлений ответственным администраторам системы.