Мой вопрос прост, и я думаю, что знаю свой ответ - мне действительно нужно подтверждение от других.
Очевидно, что если мой сервер WSUS выйдет из строя, мне нужно будет сделать несколько огромных загрузок после его резервного копирования, и это не проблема. Я больше думал о базе данных, стоящей за WSUS - нужно ли делать резервную копию?
Я думаю, что это будет похоже на настройку WSUS в первый раз - измените групповую политику, и сервер WSUS создаст свою базу данных компьютеров и установленных на них обновлений с нуля.
Прав ли я в своих предположениях, или это сделает что-то неожиданное?
Не лучше ли в конечном итоге просто создать резервную копию базы данных, скажем, раз в месяц, и покончить с этим?
Это как бы зависит от того, насколько сложен макет вашей группы, и было ли сделано много настраиваемых утверждений / отказов для определенных групп. Это также зависит от того, заботитесь ли вы об истории и текущем состоянии компьютеров в базе данных.
Если у вас очень простая настройка, при которой вы просто утверждаете все обновления и вам не важна история каких-либо компьютеров, нет необходимости делать резервную копию базы данных или обновлений. Вероятно, потребуется меньше времени, чтобы просто перестроить службу с нуля (в зависимости от скорости вашего сетевого подключения к Microsoft), чем восстановление из резервной копии. Все ваши существующие машины просто подключатся к новому серверу, как только он будет запущен.
Это довольно простой анализ рисков для любого сервиса. Если у вас есть данные, которые было бы дорого (время или деньги) или невозможно было бы воссоздать с нуля, вы должны сделать их резервную копию. В противном случае не беспокойтесь.
Резервное копирование базы данных - небольшая задача, и резервное копирование обновлений на самом деле не имеет смысла, поскольку вы просто повторно загрузите их снова, если вам нужно перестроить свой сервер WSUS. Большинство обновлений в любом случае уже применены.
Я создаю резервную копию своей базы данных WSUS, чтобы мне не приходилось записывать (или запоминать), какие обновления следует отклонять (например, у нас есть настраиваемый плагин Word, который вылетает из-за определенного КБ).
Я изучал это в предыдущей работе, когда резервные копии приближались к емкости ленты. Вместо того, чтобы продолжать резервное копирование WSUS, я установил его на другом сервере и настроил как подчиненный сервер, хотя он фактически не обслуживал клиентов. Я решил, что при необходимости я могу просто отредактировать параметр GPO, указывающий на сервер, и заняться более неотложными делами, такими как восстановление остальной части отказавшей системы. Используемое пространство на диске не представляло интереса, но освобождает ценное место на лентах.
Я бы все равно поддержал его, просто для дополнительного комфорта. Мне кажется, что WSUS - это не то, что абсолютно необходимо включать в ваши обычные ночные задания резервного копирования, и вместо этого их можно запускать в течение дня, что может упростить задачу, если ваше временное окно и / или хранилище ограничены. Хотите ли вы сделать резервную копию обновлений, а также базы данных и другой конфигурации, зависит от вас; если просто загрузить их снова, то, вероятно, в этом нет необходимости.
Если вы все же решите не создавать резервную копию, убедитесь, что вы ТЩАТЕЛЬНО задокументировать конфигурацию. Восстановление ОС, приложения и программного обеспечения базы данных может быть тривиальным делом, но, если у вас нет правильной конфигурации, вы действительно не восстановились.
То, что вы говорите о восстановлении сервера WSUS, является правильным (хотя, если URL-адрес обновления для заменяющего сервера WSUS такой же, как и для отказавшего сервера WSUS, никаких изменений в конфигурации клиента в отношении групповой политики, параметров реестра и т. Д. Не будет. нужно).
Резервное копирование базы данных WSUS или нет - это просто компромисс между временем загрузки и использованием ваших ресурсов резервного копирования (пространство, время в окне резервного копирования). Обычно он довольно маленький, так что я бы часто брал его с головой.
Сколько работы потребуется, чтобы настроить его снова?
Сколько усилий / затрат требуется для его поддержки?
Если работа по его настройке будет стоить меньше, чем стоимость резервного копирования, у вас есть ответ.
Я просто делаю наш призрачный снимок раз в квартал ... несколько месяцев исправлений - это мелочь в схеме вещей ... но я все равно заставляю его использовать прокси, так что в случае его смерти я все равно могу загрузить большинство из них локально через это .. (наш прокси имеет БОЛЬШОЙ кеш, 100 ГБ)
Приветствую, что напомнили мне, я добавляю запланированное задание, чтобы не забыть следующий квартал, и создаю резервную копию сейчас!
Всегда полезно иметь резервную копию любого сервера.
Боль от необходимости заново настраивать wsus, а затем объединять в него все машины, намного больше, чем 30 секунд, которые требуются для настройки какого-либо резервного копирования на машине.
Выполняйте ежедневный дамп БД / системы либо только на простой внешний том, либо, если у вас есть внутренняя инфраструктура резервного копирования, сделайте дамп его туда.
ИМО нет, время / хлопоты для восстановления сервера WSUS ничтожны, и это не критичный по времени элемент, который убивает вас, когда он не работает.
Если вы хотите максимально уменьшить неприятности, настройте таргетинг на стороне клиента с помощью групповой политики для своих рабочих станций / серверов. Это снизит общие накладные расходы на управление WSUS, а также сделает перестройку безболезненной.
Когда вы учитываете стоимость клиентской лицензии на резервное копирование SQL или настраиваете / обслуживаете ее вручную, я действительно не могу найти веских аргументов для ее резервного копирования.