Will a 2 TB Drive Hold the Backup? Size Capacity with TB, TiB, Growth, and Retention

A destination labelled 2 TB is not the same size as 2 TiB. That distinction is easy to miss when a computer, backup tool, cloud invoice, and drive specification do not all use the same unit. A second mistake is to size the destination from today's used space while ignoring the changed data that will remain in retained recovery points.

This guide works through a hypothetical capacity decision: a source currently uses 1.6 TiB, 25 GiB of unique changed data is retained per day, recovery points are kept for 14 days, and the planner deliberately chooses a 15% margin. The goal is not to predict one backup product's storage engine. It is to create a reproducible first-pass capacity check before comparing actual products or service tiers.

Put every input on one unit system

The decimal prefixes used in SI are powers of 1,000, while the IEC binary prefixes are powers of 1,024. NIST lists 1 GB as 1,000,000,000 bytes and 1 GiB as 1,073,741,824 bytes. The current IEC 80000-13:2025 standard covers the names, symbols, definitions, and conversion factors used in information technology, including binary prefixes. See the NIST binary-prefix reference and the IEC 80000-13:2025 overview.

The symbols are not interchangeable. One TiB is about 1.0995 TB, while one TB is about 0.9095 TiB. Choose either GiB or bytes as the working unit, record the unit beside every input, and convert only at clear boundaries. The Calquio Data Storage Converter supports GB, TB, GiB, and TiB as separate choices, which prevents an unlabeled “gigabyte” from entering the calculation.

Record the assumptions before estimating capacity

A useful first-pass estimate needs more than the source volume's advertised capacity. Record these inputs:

• Used source data, not merely the maximum size of the source disk.
• Retained changed data per day: the unique data the backup system is expected to keep, after any known product-specific behavior.
• Retention window: how long those daily changes remain represented in recovery points.
• Planning margin: a percentage chosen for uncertainty and near-term growth.
• Destination unit and usable capacity: the label alone may not equal the space available to backup data.

This structure reflects the variables used by real backup estimators. Microsoft's Azure Backup guidance asks for used size, expected data churn, and retention policy when estimating backup costs and storage. It also distinguishes full, differential, and incremental behavior. That source supports the choice of inputs, not the exact simplified formula below; the formula is Calquio's transparent planning model. See Microsoft's Azure Backup estimation guidance, last updated September 19, 2025.

For this hypothetical example, “25 GiB per day” means 25 GiB of changed data that continues to occupy backup capacity for the whole 14-day window. It is not total application writes, network traffic, or a universal change rate. The 15% margin is also a selected assumption, not an industry rule.

Reproduce the 14-day example

Use GiB as the common working unit.

1. Convert current usage: 1.6 TiB × 1024 = 1638.4 GiB.
2. Estimate retained growth: 25 GiB/day × 14 days = 350 GiB.
3. Add current data and retained growth: 1638.4 + 350 = 1988.4 GiB.
4. Calculate the selected margin: 1988.4 × 15% = 298.26 GiB.
5. Add the margin: 1988.4 + 298.26 = 2286.66 GiB.

The same result can be written as:

required capacity = (current used data + daily retained change × retention days) × (1 + margin)

For the chosen inputs:

(1638.4 GiB + 25 GiB × 14) × 1.15 = 2286.66 GiB

Converting the result gives 2.2331 TiB or 2.4553 TB. The intermediate values matter: they show exactly where a different retention period, measured change rate, or margin should be substituted. They also prevent the invalid shortcut of comparing 2.2331 TiB directly with a decimal 2 TB label.

Test the 2 TB and 3 TB options on the same basis

Convert each nominal decimal capacity to GiB before comparing it with the 2286.66 GiB requirement.

The 2 TB option fails even before filesystem space, backup catalogues, metadata, reserved capacity, or temporary working space are considered. A nominal 3 TB option clears this simplified requirement, but the table is not a purchasing guarantee. Confirm that the product exposes at least the required usable bytes after its own formatting and reserve policies.

For cloud services, also check what “stored data” means for billing and quotas. Some systems charge or limit logical data, compressed data, changed blocks, snapshots, replicated copies, or a combination. The unit conversion is exact; the product model is not interchangeable.

See which assumption changes the decision

Keeping the source at 1.6 TiB, retention at 14 days, and the selected margin at 15% shows how strongly daily change affects the result:

The table is a sensitivity check, not three forecasts. Measure changed data across ordinary days and known peaks rather than selecting the row that fits a preferred destination. Extending the original 25 GiB/day scenario from 14 to 30 days raises the same simplified estimate to 2746.66 GiB, or about 2.9492 TB, before product overhead. Retention can therefore consume the apparent spare capacity without any increase in the starting dataset.

Know what this estimate leaves out

This model intentionally treats every retained day's 25 GiB as additional occupied capacity. It may overstate a system that deduplicates or compresses changes effectively, and understate one that periodically creates full copies, keeps metadata, reserves working space, replicates data, or retains expired recovery points during cleanup. Encrypted or already-compressed files may also behave differently from ordinary documents.

Before committing to a destination:

1. Read the backup product's definition of full, incremental, differential, snapshot, and retained storage.
2. Measure actual used source data and changed data in explicitly named units.
3. Recalculate for the required recovery window and a documented margin.
4. Compare against usable capacity, not only the marketing label.
5. Run a representative backup and restore test, then compare observed consumption with the estimate.

A capacity estimate answers “is this target plausibly large enough?” It does not prove that the backup is complete, isolated, recoverable, or secure. Those require configuration review and restore testing in the chosen system.

Sources

• NIST — Prefixes for binary multiples (unit definitions; accessed August 3, 2026)
• IEC — IEC 80000-13:2025, Quantities and units: Information science and technology (published February 11, 2025; accessed August 3, 2026)
• Microsoft Learn — Estimate and understand Azure Backup pricing (last updated September 19, 2025; accessed August 3, 2026)