Disk sizing for WSUS and Linux repository mirrors

The problem in simple terms: how updates eat disk and break branches

On paper an update server is simple: download patches once, distribute to everyone, save bandwidth. In practice storage quickly balloons and branches start failing at the worst moments. Almost always the reason is the same: updates accumulate faster than you can manage them.

It's not only packages that bloat the disk — sync settings matter too. Volume spikes when unneeded products are enabled (old Windows versions or Office), multiple languages, heavy classifications (feature updates, drivers), and parallel branches and generations (Windows 10/11, different Windows Server versions).

The logic is similar for Linux: multiple distributions, architectures (x86_64, aarch64), branches (stable/testing), plus package history that a mirror keeps “just in case”.

Branches usually fail not because of “bad internet” but because of desynchronization. Typical scenarios:

• the branch has clients expecting one package base while the mirror already removed an intermediate version;
• in WSUS parts of a chain are missing (a client needs an older SSU, but you only have the latest cumulative);
• the link is so slow that the update window can't "catch up" with the central server and machines hang on partially downloaded sets.

To avoid this, plan ahead: clear retention rules (what and how long to keep), deduplication and appropriate storage type, sync and distribution schedules (so you don't saturate the line during the day), and change control. Any "add product/language/classification" checkbox should go through a change with disk and traffic assessment.

Before sizing the disk, gather minimal input data — otherwise any number is a guess:

• list of OSes and products (Windows versions, Office, Server; for Linux — distributions, repositories, architectures);
• number of nodes in HQ and branches and growth rates;
• update classifications and languages actually needed;
• link parameters: speed, stability, update windows, traffic limits.

If you design infrastructure for a government agency or a large distributed network, tie requirements to support and delivery up front. For example, GSE.kz has practices around schedules, fault tolerance and regional service: this helps not only calculate volume but also avoid breaking updates in remote sites.

What contributes to volume: WSUS and Linux mirrors broken down

Disk usage grows not because of "updates in general" but because of concrete parts: content (files), metadata (descriptions and indexes) and history (how many releases and branches you keep). If you separate these mentally, it's easier to see what can be cut without harming branches.

WSUS: content and metadata

WSUS has two major data categories:

• Metadata: the list of updates, dependencies, applicability rules and statuses. They are usually smaller than content, but grow over time and can slow operations.
• Content: what is actually downloaded (CAB, MSI, patches). This is the usual disk hog.

Important: you don't need to download every update. Volume heavily depends on chosen products and versions, languages, and whether you download content in advance or on demand.

Linux mirrors: packages, indexes and "heavy" entities

A Linux repository mirror usually consists of packages (deb/rpm and associated files), metadata (Packages, repodata, Release, dependency lists), signatures and keys, and history (old package versions if you don't prune them). Container images, if mirrored, are a separate load and have different growth dynamics.

Metadata takes less space than packages but changes frequently. On slow links frequent metadata changes become a noticeable load even if packages themselves aren't downloaded every day.

Full mirror vs partial mirror

A full mirror grows quickly because it pulls everything: different releases, branches (stable, updates, security, testing) and several architectures. A partial mirror limits itself to what's actually used: specific distributions, releases and branches, plus one or two architectures.

Big drivers of growth are release frequency and security updates, number of architectures (amd64 + arm64 almost doubles volume), and presence of EOL systems. EOL often forces you to keep old repos, otherwise legacy servers and workstations cannot update or resolve dependencies.

Architecture for HQ and branches: what affects the disk

Storage depends not only on how many Windows and Linux systems you have but also on how updates travel across the network. The same organization can rely on a single large disk in HQ or a combination of "medium disk in HQ + small disks in branches". Both can be valid if they match the link characteristics and operational model.

The simplest option is to keep everything in HQ and let branches download over WAN. Then disk needs concentrate in the center, but bandwidth demands increase: on unstable links updates can easily saturate the line and affect business traffic. The alternative is local caches or replicas in branches (downstream WSUS for Windows and local cache/mirror for Linux). WAN load reduces, but the total disk footprint across the network grows.

The strongest influences on disk and the risk of "breaking a branch" are:

• branch autonomy (how many days it must operate without the link and still update);
• link speed and quality (weak links require more local storage and staggered distribution);
• installation windows (night/weekend/group schedules: the narrower the window, the higher the peak and the more sense in local caches);
• mixed device fleet (PCs, servers, terminal farms pull different sets and frequencies);
• client behavior (reinstalls, laptops returning from travel: caches can repeatedly circulate the same packages).

Split update policies: critical servers receive a minimal set (usually security) after validation; normal PCs receive the full set on schedule. This directly affects disk: more branches, languages, architectures and approval groups mean more unique content to store.

A pragmatic scenario: HQ keeps a full set for everyone, branches keep a local minimum for 7–14 days of autonomy. If a branch loses connectivity, it continues to operate, and the central store doesn't need to keep endless history for rare update windows in remote sites.

Disk sizing for WSUS: a simple formula and inputs

It's easier to calculate what you'll actually store on disk during the chosen retention rather than "how much Windows weighs."

Basic formula:

WSUS disk = Base (initial sync) + Growth over retention period + Buffer.

Base — the set downloaded during first sync for chosen products, classifications and languages. Growth — how many new packages and revisions accumulate before you delete them according to rules. Buffer is needed because WSUS creates temporary files and maintenance or sync peaks can temporarily increase used space.

Inputs to collect

Before sizing, fix parameters that most inflate volume:

• products: Windows 10/11, Windows Server (which versions are actually present);
• classifications: Security, Critical, Updates, Feature Updates, Drivers;
• languages: keep only languages used by users (often one is enough);
• architectures: x64 is usually sufficient; add x86 and ARM only if such machines exist;
• retention: how many days/months you keep updates before cleanup.

A common error is enabling unnecessary Windows/Server branches. If you don't have Windows Server 2012 R2 in the environment, don't include it. If you don't distribute drivers via WSUS, don't include Drivers — it's one of the most storage-hungry items.

Buffer you must not omit

Include at least 20–30% on top of calculated volume. This covers BITS temporary files, content reassembly, reindexing and months where many cumulative updates or several large Feature Updates arrive.

Example: HQ keeps Windows 11 x64 RU and Windows Server 2019/2022, only Security + Critical + Updates, retention 90 days. Base is defined by the first download and growth by the incoming updates over 3 months. If you add "all languages" and Drivers, the same retention can multiply disk needs even if device count doesn't change.

Disk sizing for Linux mirrors: repos, branches and history

Mirror volume grows with which repositories you mirror, which branches (stable, updates, security, backports), how many architectures and whether you keep package history.

Quick estimate for ballpark numbers:

Volume ≈ (number of distributions) x (number of branches/channels) x (number of architectures) x (history depth)

By "history depth" we mean how long you keep old versions (30, 60, 90 days). If you keep only current versions without past releases, this multiplier falls sharply.

A more practical approach is to measure:

• current size of chosen repositories;
• average monthly growth (from sync logs or size differences over 2–4 weeks);
• retention period (in months);
• buffer for spikes (usually 20–30%).

Then:

Required disk ≈ Current size + (Monthly growth × Retention) + Buffer.

Check what exactly you mirror. Often backports (duplicate dependencies), debug and source packages add unnecessary volume. If they're not needed, don't include them — otherwise you pay in disk for unused content.

If you mirror containers, treat them separately: OCI registries depend on number of images, tags and layer retention.

Retention rules: how long to keep and what to delete first

Retention isn't about saving at any cost but predictability. Storage should not grow endlessly, and branches on weak links should still have necessary packages.

First reduce what even reaches the server. In WSUS enable only real products and 1–2 languages. For classifications, Security, Critical and Updates are often enough. Drivers and Previews typically bloat the store without much benefit.

Then set simple retention periods and cleanup order:

• Superseded updates: keep 30–60 days, then decline and delete (unless old OSes still need them).
• Obsolete products: once an OS is retired, disable that product in sync and clean related updates.
• Inactive computers: remove records for devices that haven't contacted in 30–90 days to avoid slowing reports and cleanup.
• Content after deletion: run cleanup regularly so that "declined" actually frees space.

For Linux mirrors the logic is similar: keep only necessary releases and branches. If standard is LTS, keep LTS and the current release; remove others. Limit history: for example, keep 2–3 repo snapshots or 60–90 days, and keep archives/debug only as needed.

One rule for branches: don't delete updates before all sites have applied them. A practical guideline — keep content for at least two patch cycles after approval (e.g., 60 days) or until a target adoption level (for example, 95%) is reached. If branches update monthly, a 30-day retention often breaks the process.

In distributed environments where local support matters, document these rules: what is supported, how long items are kept, who runs cleanup and which windows branches need. That prevents branches from breaking due to sudden cleanup or someone expanding sync scope.

Automation helps more than ad-hoc manual cleanups. Typical needs:

• weekly growth report and biggest categories;
• alerts at disk thresholds (for example 20% and 10% free);
• scheduled cleanup with result verification;
• checks that branches can download content within their windows.

When you understand required volume and dynamics, plan hardware: buffer for release peaks, disk subsystem speed and reliability (RAID, hot-swap, monitoring). If you need a turnkey server and integration, discuss the whole contour: central node, branches, network and support. GSE.kz can provide hardware, configuration and 24/7 support aligned with government and corporate procurement rules and a national service network.

Step-by-step: how to configure so disk doesn't grow forever

Goal: keep only what's needed by your PCs and servers, and only for the time that helps recover from a bad patch or rollback.

1) Map the environment first, then enable downloads

List OSes, distributions, versions, architectures and languages. Group devices by criticality: office PCs, servers, terminal farms, specialized workstations. This allows staged rollouts rather than everyone at once.

Next set retention and update windows. For most networks 30–90 days of content and wave schedules so branches download at night work well.

Operational sequence:

1. Create WSUS groups by criticality and link speed (HQ, branches).
2. In WSUS enable only needed products and Windows versions and limit languages (often RU and EN are enough).
3. Auto-approve only baseline updates for a pilot group; other groups after validation.
4. For Linux mirrors filter by branches (stable, security) and architectures; avoid pulling full archives and debug packages unless necessary.
5. Separate test and production repositories so a bad sync doesn't break branch updates.

2) Disk control and regular cleanup

Growth is usually due to no cleanup and too broad scope. Schedule:

• WSUS cleanup (obsolete, declined, unused content);
• prune old package versions in Linux mirrors per retention;
• disk fill alerts at 70/85/95%;
• monthly review: which products and repos can be removed.

If you have 24/7 support, focus on scheduling cleanup and update waves — that often helps more than buying extra disk.

Common mistakes that bloat storage and break branches

The root cause is the same: updates start living their own life. The center hoards extra content, and branches suddenly can't find needed package chains, clients go to the internet or get errors.

Typical mistakes:

• Enabling all products and languages in WSUS "just in case". Disk fills with items never installed.
• Setting up WSUS and forgetting cleanup. Obsolete and declined updates accumulate and slow the database.
• Deleting superseded updates too aggressively. If a branch was offline a week or two, it may need intermediate updates that were removed.
• Making a full Linux mirror of everything: multiple distros, branches, EOL releases and extra architectures. Space runs out especially fast if you pull debug/source and don't limit history.
• Mixing test and production in one repo without rules. Then it's hard to roll back or know the golden set.

Another trap is not reserving space for maintenance. You need buffer for temporary downloads, metadata rebuilds, WSUS DB work (indexes) and antivirus. At 95–100% disk usage issues start even without content growth.

Example: a branch with a thin link updates every 10 days. You set an aggressive superseded deletion of 3–5 days to save space. On day 11 the branch requests an intermediate update that no longer exists. Result: install errors or clients bypass your infrastructure to download from the internet.

Quick pre-launch checklist: disk and retention

Before putting the update server into production and connecting branches, run a short check. It takes 15 minutes but prevents sudden out-of-space events and branches left without packages.

Assess not only "how much is used now" but "what will happen in a month" when cumulative updates, new package versions and maintenance temporary files arrive.

Check:

• Free space buffer: keep at least 20–30% free for peaks (Patch Tuesday, big distro updates) and maintenance (index rebuilds, temp files, unpacking).
• Content boundaries: lock which WSUS products, languages, architectures, Linux branches and repos are allowed. Assign an owner to approve changes.
• Hygiene and cleanup: in WSUS remove obsolete and unused updates and ensure declined updates free space; set Linux mirrors to remove old versions per retention rules.
• Growth monitoring: measure weekly and monthly growth and keep a simple quarterly forecast.
• Branches can fetch content: confirm branches download required items before deletion. Otherwise you save disk but create repeated downloads and failures on weak links.

If any item fails, narrow content scope and increase buffer before production — it's safer than fixing desynchronized versions later.

Example calculation: a typical network with HQ and branches

Scenario: 1 HQ and 6 branches. Two branches on 100 Mbps, two on 30–50 Mbps and two on 10–20 Mbps with occasional drops. Updates are distributed centrally but paced so weak links don't "die" on Patch Tuesday.

Assumptions:

• Windows: 2 servers (e.g., 2019/2022) and about 180 PCs on Windows 10/11.
• Linux: 3 distributions for servers and workstations (e.g., Ubuntu LTS, Debian stable, Rocky/Alma).
• Languages and architectures: only needed ones (usually x64, 1–2 languages).

Retention (to keep storage stable)

For Windows set 90 days for update content, with exceptions for critical security and components like .NET. Run cleanup weekly and deep maintenance monthly.

For Linux 14–30 days of history is often enough: old package versions pile up quickly. For stable setups keep one release (no EOL); test branches either live separately with short retention or are not mirrored.

Ballpark disk numbers

Estimates:

• WSUS: metadata and base 15–30 GB. Content with this product set and 90-day retention often hits 350–500 GB.
• Linux mirrors: 80–150 GB per distribution with moderate retention and no extra architectures. For three distributions that's 240–450 GB.
• Buffer for temporary files, staging and "downloaded but not yet distributed" for branches: +20–30%.

Total reasonable provision: 1.2–1.6 TB of usable space. Partitioning: separate volumes for OS, WSUS Content, Linux mirror, and a small staging volume or folder.

If space is tight, first reduce scope: remove extra Windows products, languages, drivers and preview updates. For branches with poor links add local caches (downstream WSUS or local repo caches) and schedule night-time distribution instead of immediate pushes.

Next steps: lock rules and plan infrastructure

To prevent updates turning into endless disk growth, regularly review sizing and formalize retention so it doesn't depend on a single admin.

Review metrics not strictly by calendar but when changes occur: a new Windows or Linux version, a new branch, enabling a product (Office or drivers), or major distro releases. Minimum practice: a short quarterly trend check plus ad-hoc reviews after park changes.

Document rules on 1–2 pages: what is updated, what is disallowed, retention periods, and who approves changes. Predefine exceptions (critical patches kept longer, special groups for specialized systems). This avoids branches breaking because someone expanded sync or cleaned unexpectedly.

Automation outperforms one-off manual cleanups. Typical automation includes:

• weekly report on storage growth and top categories;
• alerts at thresholds (for example 20% and 10% free);
• scheduled cleanup with verification;
• checks that branches can fetch content within allocated windows.

Once you know required volume and dynamics it's easier to plan hardware: buffer for release peaks, disk subsystem performance and reliability (RAID, hot-swap, monitoring). If you need integrated procurement and setup, discuss the entire stack: central node, branches, network and support. GSE.kz can help choose and supply servers and workstations, configure infrastructure and provide 24/7 support aligned with government and corporate procurement rules and a national service network.