Расчет диска для WSUS и зеркал репозиториев Linux

Задача простыми словами: как обновления съедают диск и рвут филиалы

Сервер обновлений на бумаге выглядит просто: скачал патчи один раз, раздал всем, сэкономил канал. На практике хранилище быстро пухнет, а филиалы начинают отваливаться в самый неудобный момент. Почти всегда причина одна: обновления копятся быстрее, чем вы успеваете ими управлять.

Диск раздувают не только сами пакеты, но и настройки синхронизации. Объем резко растет, когда включены лишние продукты (например, старые версии Windows или Office), несколько языков, тяжелые классификации (feature updates, драйверы), а также параллельные ветки и поколения (Windows 10/11, разные Windows Server).

В Linux логика похожая: несколько дистрибутивов, архитектуры (x86_64, aarch64), ветки (stable/testing), плюс история пакетов, которую зеркало держит "на всякий случай".

Филиалы ломаются обычно не из-за "плохого интернета", а из-за рассинхрона. Типовые сценарии:

• в филиал приехали клиенты с одной базой пакетов, а зеркало уже удалило нужную промежуточную версию;
• в WSUS пропущены части цепочки (клиенту нужен старый SSU, а вы оставили только свежие cumulative);
• канал настолько медленный, что окно обновлений не успевает "догнать" центральный сервер, и машины зависают на частично скачанном наборе.

Чтобы этого не было, решения лучше закладывать заранее: понятный ретеншн (что и сколько держим), дедупликацию и подходящий тип хранилища, расписания синхронизаций и раздачи (чтобы не забивать канал днем), а также контроль изменений. Любая галочка "добавить продукт/язык/классификацию" должна проходить как изменение с оценкой диска и трафика.

Перед расчетом диска соберите минимальные входные данные, иначе любая цифра будет гаданием:

• список ОС и продуктов (Windows версии, Office, Server; для Linux - дистрибутивы, репозитории, архитектуры);
• количество узлов в головном офисе и филиалах и темпы роста;
• классификации обновлений и языки, которые реально нужны;
• параметры каналов связи: скорость, стабильность, окно для обновлений, лимиты трафика.

Если вы планируете инфраструктуру для госорганизации или крупной распределенной сети, полезно сразу привязать требования к поддержке и поставкам. Например, у системного интегратора GSE.kz есть практика по расписаниям, отказоустойчивости и сервису в регионах: это помогает не только посчитать объем, но и не сорвать обновления в удаленных точках.

Из чего складывается объем: WSUS и Linux зеркала по частям

Объем на диске растет не из-за "обновлений вообще", а из-за конкретных частей: контент (файлы), метаданные (описания и индексы) и история (сколько выпусков и веток вы храните). Если разделить это в голове заранее, проще понять, что можно урезать без боли для филиалов.

WSUS: контент и метаданные

В WSUS есть две крупные категории данных:

• Метаданные: список обновлений, зависимостей, правил применимости и статусов. Обычно они меньше по объему, чем контент, но со временем разрастаются и могут замедлять работу.
• Контент: то, что реально скачивается (CAB, MSI, патчи). Именно он чаще всего забивает диск.

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

Linux зеркала: пакеты, индексы и "тяжелые" сущности

Зеркало репозитория Linux обычно состоит из пакетов (deb/rpm и сопутствующие файлы), метаданных (Packages, repodata, Release, списки зависимостей), подписей и ключей, а также истории (старые версии пакетов, если вы их не чистите). Отдельно стоят контейнерные образы, если вы зеркалите еще и registry: это другой тип нагрузки и другая динамика роста.

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

Полное зеркало vs частичное

Полное зеркало быстро раздувается, потому что тянет все подряд: разные релизы, ветки (stable, updates, security, testing) и несколько архитектур. Частичное зеркало ограничивается тем, что реально используется: конкретные дистрибутивы, релизы и ветки, плюс одна-две архитектуры.

На рост сильнее всего влияют частота релизов и обновлений безопасности, число архитектур (amd64 + arm64 почти удваивает объем), а также наличие EOL-систем. EOL часто заставляет держать старые репозитории, иначе старые серверы и рабочие места перестают нормально обновляться или собирать зависимости.

Схема для головного офиса и филиалов: что влияет на диск

Объем хранилища зависит не только от того, сколько у вас Windows и Linux, но и от того, как обновления едут по сети. Одна и та же организация может обойтись одним большим диском в центре или комбинацией "средний диск в центре + небольшие диски в филиалах". И оба варианта будут правильными, если они соответствуют связи и режиму работы.

Самый простой вариант - держать все в головном офисе, а филиалы качают по WAN. Тогда диск нужен в основном в центре, но растут требования к каналу: при нестабильной связи обновления легко забивают линию и мешают бизнес-трафику. Альтернатива - локальные кэши или реплики в филиалах (downstream WSUS для Windows и локальный кэш/зеркало для Linux). WAN разгружается, но суммарный объем дисков по сети увеличивается.

На диск и риск "сломать филиал" обычно сильнее всего влияют:

• автономность филиала (сколько дней он должен жить без канала и все равно уметь обновляться);
• скорость и качество линка (если канал слабый, придется хранить больше локально и разносить обновления по времени);
• окна установки (ночью, по выходным, по группам: чем уже окно, тем выше пик и тем больше смысл в локальном кэше);
• разный парк устройств (ПК, серверы, терминальные фермы тянут разные наборы и частоту);
• поведение клиентов (переустановки, ноутбуки из командировок: кэш начинает гонять одни и те же пакеты по кругу).

Политики обновлений почти всегда стоит разделять: критичные серверы получают минимум (обычно security) и после проверки, а обычные ПК - полный набор по расписанию. Это влияет на диск напрямую: чем больше веток, языков, архитектур и групп одобрения, тем больше уникального контента приходится держать.

Практичный сценарий: головной офис хранит полный набор для всех, а филиалы держат локальный минимум на 7-14 дней автономной работы. Тогда при обрыве связи филиал не встает, а центральное хранилище не вынуждено бесконечно держать историю ради редких окон обновлений в удаленных точках.

Расчет диска для WSUS: простая формула и входные данные

Удобнее считать не "сколько весит Windows", а сколько вы реально будете хранить на диске в течение выбранного ретеншна.

Базовая формула:

Диск WSUS = База (первичная синхронизация) + Прирост за период ретеншна + Запас.

База - набор обновлений, который скачивается при первом включении выбранных продуктов, классификаций и языков. Прирост - сколько новых пакетов и ревизий накопится, пока вы не начнете удалять их по правилам. Запас нужен, потому что WSUS создает временные файлы, а обслуживание и пики синхронизации могут временно заметно увеличивать занимаемый объем.

Какие входные данные собрать

Перед расчетом зафиксируйте параметры, которые сильнее всего раздувают объем:

• продукты: Windows 10/11, Windows Server (какие версии реально есть);
• классификации: Security, Critical, Updates, Feature Updates, Drivers;
• языки: оставляйте только те, что нужны пользователям (часто хватает одного);
• архитектуры: x64 почти всегда достаточно; x86 и ARM добавляйте только при наличии таких машин;
• ретеншн: сколько дней или месяцев вы храните обновления до очистки.

С версиями Windows и Server чаще всего ошибка в "лишних ветках". Если в сети нет Windows Server 2012 R2, не включайте его продукт. Если вы не раздаете драйверы через WSUS, не включайте Drivers: это один из самых прожорливых пунктов.

Запас, без которого расчеты ломаются

Закладывайте минимум 20-30% к расчетному объему. Он уходит на временные файлы BITS, пересборку контента, переиндексацию и ситуации, когда в один месяц выходит много накопительных обновлений и несколько крупных Feature Updates.

Пример: головной офис держит Windows 11 x64 RU и Windows Server 2019/2022, только Security + Critical + Updates, ретеншн 90 дней. База определяется первым скачиванием, а прирост - темпом поступления обновлений за 3 месяца. Если добавить "все языки" и Drivers, тот же ретеншн легко увеличит диск в разы, хотя компьютеров не стало больше.

Расчет диска для зеркал Linux: репозитории, ветки и история

Для зеркала Linux объем растет из комбинации: какие репозитории вы берете, какие ветки (stable, updates, security, backports), сколько архитектур и храните ли историю пакетов.

Быстрая оценка для порядка цифр:

Объем ≈ (число дистрибутивов) x (число веток/каналов) x (число архитектур) x (глубина истории)

Под "глубиной истории" удобно понимать, сколько времени вы оставляете старые версии (например, 30, 60 или 90 дней). Если храните только актуальные версии без прошлых релизов, этот множитель резко падает.

Более практичный способ - считать от факта:

• текущий размер выбранных репозиториев;
• средний прирост в месяц (по логам синхронизации или по разнице размеров за 2-4 недели);
• срок хранения истории (в месяцах);
• запас под пик (обычно 20-30%).

Тогда:

Нужно диска ≈ Текущий размер + (Прирост в месяц x Срок хранения) + Запас.

Отдельно проверьте, что именно вы зеркалите. Часто "лишний" объем дают backports (дублируют зависимости), debug-пакеты и source-пакеты. Если они не нужны, не включайте их: иначе вы платите диском за то, чем никто не пользуется.

Если у вас есть контейнеры, не смешивайте их с зеркалом пакетов. Реестр образов (OCI) лучше считать отдельно: там объем зависит от числа образов, тегов и ретеншна слоев.

Правила ретеншна: сколько хранить и что удалять в первую очередь

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

Сначала сократите то, что вообще попадает на сервер. В WSUS включайте только реальные продукты и 1-2 языка. По классификациям чаще всего достаточно Security Updates, Critical Updates и Updates. Драйверы и Preview почти всегда раздувают базу без заметной пользы.

Дальше задайте простые сроки и порядок уборки:

• Superseded updates: держите 30-60 дней, затем отклоняйте и удаляйте (если нет старых ОС, которым это нужно).
• Устаревшие продукты: как только вывели ОС из эксплуатации, отключайте продукт в синхронизации и чистите связанные обновления.
• Неподключавшиеся компьютеры: удаляйте записи, если устройство не выходило на связь 30-90 дней, иначе отчеты и очистка будут тормозить.
• Контент после удаления: регулярно запускайте очистку, чтобы "отклонено" действительно освобождало место.

Для зеркал Linux логика похожая: храните только нужные релизы и ветки. Если стандарт на LTS, оставьте LTS и текущий релиз, остальное убирайте. Ограничьте историю: например, держать 2-3 снапшота репозитория или 60-90 дней, а архивы и debug-пакеты оставлять только по необходимости.

Правило для филиалов одно: не удаляйте обновления раньше, чем все площадки успели их применить. Практичный ориентир - держать контент минимум 2 патч-цикла после утверждения (например, 60 дней) или до согласованного уровня установки, например 95% машин по отчетам. Если филиалы обновляются раз в месяц по ночам, ретеншн в 30 дней часто ломает процесс.

В распределенных инфраструктурах, где важна локальная поддержка и сервис в регионах, такие правила лучше закрепить коротким документом: что поддерживаем, сколько держим, кто и как часто запускает очистку, какое окно нужно филиалам.

Пошагово: как настроить, чтобы диск не рос бесконечно

Цель простая: хранить только то, что нужно вашим ПК и серверам, и только на срок, который помогает пережить проблемный патч или откат.

1) Сначала соберите картину, потом включайте скачивание

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

Дальше задайте ретеншн и окно обновлений. Для большинства сетей работает диапазон 30-90 дней хранения контента и график волн так, чтобы филиалы скачивали ночью и не в один день.

Рабочая последовательность настроек:

1. Создайте группы в WSUS по критичности и по скорости канала (головной офис, филиалы).
2. В WSUS оставьте только нужные продукты и версии Windows и ограничьте языки (часто хватает RU и EN).
3. Настройте автоодобрение только для базовых обновлений и только для пилотной группы, остальным - после проверки.
4. Для Linux зеркала включите фильтры по веткам (stable, security) и архитектурам, а полный архив и debug пакеты не тяните без причины.
5. Разведите тестовый репозиторий и боевой, чтобы проблемная синхронизация не ломала обновления в филиалах.

2) Контроль диска и регулярная уборка

Рост диска чаще всего идет из-за отсутствия уборки и слишком широкого охвата. Поставьте на расписание:

• очистку WSUS (устаревшие, неподписанные, неиспользуемые файлы контента);
• удаление старых версий пакетов в Linux зеркале по вашему ретеншну;
• контроль заполнения тома и уведомления при 70/85/95% заполнения;
• ежемесячный пересмотр: какие продукты и репозитории больше не нужны.

Если у вас есть поддержка 24/7 и сервисная сеть, отдельное внимание стоит уделить именно расписанию уборки и "волнам" обновлений: это обычно дает эффект быстрее, чем покупка дополнительного диска.

Частые ошибки, из-за которых хранилище пухнет и филиалы падают

Главная причина проблем одна и та же: обновления начинают жить своей жизнью. В центре копится лишнее, а в филиалах внезапно не сходятся цепочки пакетов и обновлений, клиенты уходят в интернет или получают ошибки.

Типовые ошибки:

• В WSUS включают все продукты и все языки "на всякий случай". На диск попадает то, что никогда не будет установлено.
• WSUS настраивают и забывают про регулярную чистку. Копятся устаревшие и отклоненные обновления, база разрастается и начинает тормозить.
• Superseded-обновления удаляют слишком рано. Если филиал был офлайн неделю-две, он может "догонять" по цепочке и упереться в пропуск.
• Для Linux делают полное зеркало "всего подряд": несколько дистрибутивов, все ветки, EOL-релизы и лишние архитектуры. Особенно быстро кончается место, если тянуть debug/source и не ограничивать историю.
• Тестовые и боевые ветки складывают в один репозиторий без правил. Потом трудно откатиться и понять, что считается эталоном.

Отдельная ловушка - не оставлять место на обслуживание. Нужен запас под временные загрузки, пересборку метаданных, обслуживание базы WSUS (индексы) и работу антивируса. Если диск заполнен под 95-100%, проблемы начинаются даже без роста контента.

Пример: филиал с тонким каналом обновляется раз в 10 дней. Вы настроили агрессивное удаление superseded через 3-5 дней, чтобы экономить место. На 11-й день филиал приходит за промежуточным обновлением, которого уже нет. Дальше либо ошибки установки, либо скачивание в обход вашей инфраструктуры.

Быстрая проверка перед запуском: чек-лист по диску и ретеншну

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

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

Проверьте по пунктам:

• Запас свободного места: оставьте минимум 20-30% под пики (Patch Tuesday, крупные апдейты дистрибутивов) и под обслуживание (пересбор индексов, временные файлы, распаковка).
• Границы контента: зафиксируйте, какие продукты WSUS, языки, архитектуры, ветки Linux и репозитории разрешены. Назначьте владельца, кто может это менять.
• Гигиена и очистка: в WSUS удалены устаревшие и неиспользуемые обновления, отклоненные обновления действительно очищены из хранилища; для Linux зеркал настроено удаление старых версий по правилам.
• Мониторинг роста: фиксируйте прирост в неделю и в месяц и держите простой прогноз на квартал.
• Филиалы успевают получить контент: подтверждено, что филиалы скачали нужное до удаления. Иначе вы экономите диск, но получаете бесконечные повторные загрузки и сбои на слабых каналах.

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

Пример расчета: типовая сеть с офисом и филиалами

Возьмем картину: 1 головной офис и 6 филиалов. Два филиала на 100 Мбит/с, два на 30-50 Мбит/с и еще два на 10-20 Мбит/с с редкими просадками. Обновления раздаем централизованно, но так, чтобы слабые каналы не "умирали" в день Patch Tuesday.

Допущения по составу:

• Windows: 2 сервера (например, 2019/2022) и около 180 ПК на Windows 10/11.
• Linux: 3 дистрибутива для серверов и рабочих мест (например, Ubuntu LTS, Debian stable, Rocky/Alma).
• Языки и архитектуры: только нужные (обычно x64, 1-2 языка).

Ретеншн (чтобы хранилище не росло)

Для Windows задаем хранение содержимого обновлений 90 дней, с исключениями под критические security и типовые компоненты вроде .NET. Чистку запускаем раз в неделю, а "глубокую" чистку и обслуживание базы - раз в месяц.

Для Linux часто хватает 14-30 дней истории по пакетам: старые версии копятся быстро. Для стабильных веток держим один релиз (без EOL), а тестовые ветки либо выносим отдельно с коротким сроком хранения, либо не зеркалим.

Итоговый расчет по диску

Прикидка по порядку цифр:

• WSUS: метаданные и база 15-30 ГБ. Контент при таком наборе продуктов и ретеншне 90 дней часто выходит 350-500 ГБ.
• Зеркала Linux: по 80-150 ГБ на дистрибутив при умеренном ретеншне и без лишних архитектур. Для трех дистрибутивов это 240-450 ГБ.
• Запас под временные файлы, staging и "скачали, но еще не раздали" для филиалов: +20-30%.

Итого разумно закладывать 1.2-1.6 ТБ полезного объема. Разбивка по томам простая: отдельно OS, отдельно WSUS Content, отдельно Linux mirror, и небольшой том или каталог под staging.

Если места не хватает, сначала режьте охват: лишние продукты Windows, лишние языки, драйверы и preview-обновления. Для филиалов с плохим каналом добавьте локальный кэш (downstream WSUS или локальный репо-кэш) и раздачу по расписанию ночью, а не "как только вышло".

Следующие шаги: закрепляем правила и планируем инфраструктуру

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

Пересматривайте цифры не "по календарю", а по изменениям: новая версия Windows или Linux, новый филиал, включение нового продукта (например, Office или драйверов), выход крупных релизов дистрибутивов. Практичный минимум - раз в квартал короткая проверка тренда роста плюс внепланово после любых изменений в парке.

Правила лучше оформить документом на 1-2 страницы: что обновляем, что запрещено, сколько держим историю, кто утверждает изменения. Заранее опишите исключения (например, критические патчи держим дольше, для специализированных систем отдельная группа). Тогда филиалы не будут "ломаться" из-за внезапной чистки или из-за того, что кто-то расширил синхронизацию.

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

• еженедельного отчета по росту хранилища и самым "тяжелым" категориям;
• алертов по порогам свободного места (например, 20% и 10%);
• плановой очистки по расписанию с контролем результата;
• контроля каналов филиалов (успевают ли они скачивать в отведенные окна).

Когда понятно, какой объем нужен и какая будет динамика, проще планировать железо: запас под пики релизов, скорость дисковой подсистемы и надежность (RAID, горячая замена, мониторинг). Если нужен сервер и интеграция под ключ, логичный подход - обсуждать весь контур: центральный узел, филиалы, сеть и поддержку. У GSE.kz это удобно тем, что можно подобрать и поставить серверы и рабочие станции собственного производства, а также настроить инфраструктуру и 24/7 поддержку с учетом требований гос и корпоративных закупок и сервисной сети по стране.