Должен ли я сделать резервную копию моего сервера WSUS?

Мой вопрос прост, и я думаю, что знаю свой ответ - я действительно после подтверждения от других.

Очевидно, что если мой WSUS-сервер умрет, у меня будут большие загрузки, когда он будет создан, и это не проблема. Я больше думал о базе данных, стоящей за WSUS - это должно быть подкреплено?

Я думаю, что произойдет то, что это будет похоже на настройку WSUS в первый раз - измените групповую политику, и сервер WSUS затем создаст свою базу данных компьютеров и их установленных обновлений с нуля.

Я прав в своих предположениях, или это сделает что-то неожиданное?
Лучше ли в конечном итоге просто создать резервную копию базы данных, скажем, раз в месяц и покончить с этим?

Это зависит от того, насколько сложен макет вашей группы и много ли вы сделали пользовательских утверждений / отклонений для определенных групп. Это также зависит от того, заботитесь ли вы об истории и текущем состоянии компьютеров в базе данных.

Если у вас очень простая настройка, в которой вы только одобряете все обновления, и вас не волнует история любого из компьютеров, вам не нужно делать резервную копию базы данных или обновлений. Вероятно, потребуется меньше времени, чтобы просто перестроить службу с нуля (в зависимости от того, насколько быстро ваше сетевое подключение к Microsoft), чем восстановление из резервной копии. Все ваши существующие машины просто зарегистрируются на новом сервере, как только он включится.

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

Резервное копирование базы данных - это небольшая задача, и резервное копирование обновлений на самом деле не имеет смысла, поскольку вы просто перезагружаете их снова, если вам необходимо перестроить сервер WSUS. Большинство обновлений уже применяются в любом случае.

Я создаю резервную копию своей базы данных WSUS, чтобы мне не приходилось записывать (или запоминать), какие обновления следует отклонить (например, у нас есть собственный плагин Word, который аварийно завершает работу с определенным КБ).

Я рассмотрел это в предыдущей работе, когда резервные копии приближались к емкости ленты. Вместо того, чтобы продолжать резервное копирование WSUS, я установил его на другом сервере и настроил его в качестве нисходящего сервера, хотя он фактически не обслуживал клиентов. Я подумал, что при необходимости я мог бы просто отредактировать настройку объекта групповой политики, указывающую на сервер, и заняться более неотложными вопросами, такими как восстановление остальной части неисправной системы. Использованный диск не имел значения, но он освободил ценное пространство на лентах.

Я бы все равно поддержал это, просто для дополнительного комфорта. Меня поражает, что WSUS - это не то, что абсолютно необходимо включать в ваши обычные задания ночного резервного копирования, и вместо этого его можно запускать в течение дня, что может упростить ситуацию, если у вас не хватает временного окна и / или хранилища. Хотите ли вы сделать резервную копию обновлений, а также базы данных и других настроек, зависит только от вас; если просто загрузить их снова, то вам, вероятно, не нужно.

Если вы решили не выполнять резервное копирование, убедитесь, что вы Тщательно документировали конфигурацию . Восстановление ОС, приложений и программного обеспечения базы данных может быть тривиальным, но если вы не вернете конфигурацию обратно, вы не восстановитесь.

Что вы говорите: перестройка WSUS-сервера верна (хотя, если URL-адрес обновления для заменяющего WSUS-сервера совпадает с неисправным WSUS-сервером, никаких изменений в конфигурации клиента повторно: групповая политика, параметры реестра и т. Д. нужно).

Резервное копирование базы данных WSUS - это просто компромисс времени для загрузки по сравнению с использованием ресурсов резервного копирования (пространство, время в окне резервного копирования). Как правило, он довольно маленький, поэтому я пойду и буду его хватать регулярно.

Сколько будет работы, чтобы настроить его снова?

Сколько усилий / затрат затрачивается на его поддержку?

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

Я просто делаю наш призрачный образ раз в квартал ... несколько месяцев исправлений - это маленькая картошка в схеме вещей ... но я также заставляю ее использовать прокси в любом случае, так что в случае ее смерти я все равно могу загрузить большинство из них локально через это .. (наш прокси имеет большой кэш, 100 ГБ)

Спасибо за напоминание, я добавляю запланированное задание, чтобы не забыть следующий квартал и сейчас поддерживаю его!

Всегда полезно иметь резервную копию любого сервера.

Боль от необходимости снова устанавливать wsus и затем собирать в него все машины гораздо больше, чем 30 секунд, которые требуются для установки некоторого резервного копирования на машине.

Выполняйте ежедневный дамп БД / системы либо на простой внешний том, либо, если у вас есть внутренняя резервная копия, скопируйте его туда.

ИМО нет, время / хлопоты по перестройке сервера WSUS ничтожно мало, и это не критичный ко времени пункт, который убивает вас, когда он не работает.

Если вы хотите максимально снизить количество хлопот, настройте таргетинг на стороне клиента с помощью групповой политики для своих рабочих станций / серверов. Это уменьшит ваши общие затраты на управление WSUS, а также сделает процесс восстановления безболезненным.

Когда вы учитываете стоимость клиентской лицензии SQL для резервного копирования или настраиваете / поддерживаете ее вручную, я действительно не могу найти веского аргумента для ее резервного копирования.