How calculator works (click to expand)
1. What this tool is for
This calculator estimates how much storage capacity you need to buy to keep immutable (WORM, write once read many) backups. Immutable backups cannot be changed or deleted until a set period has passed, which is what protects them from ransomware and from accidental or malicious deletion. Because immutable data cannot be removed early, it needs more space than everyday backups, and this tool works out how much. It was built for the design where CommVault protects virtual machines and SQL databases (whose backups are stored on a NetApp AFF system) and NetApp filers hold production file shares, and the goal is to make both immutable and size the extra capacity correctly. Everything runs in your browser and no data leaves your machine.
2. The three ways of storing immutable copies (Sizing mode)
Choose one at the top of the page:
- On-prem NetApp SnapLock (the recommended default). Take NetApp snapshots of the backup storage and the file shares, send them with SnapVault to a dedicated SVM/NetApp system, and lock them with SnapLock so they cannot be deleted early. Sizing is based on disk.
- Cloud: NetApp CVO / BlueXP DataLock. NetApp snapshots are sent to cloud object storage and locked there. This adds a separate rough API cost estimate on top of the shared Estimated Storage Cost.
- Cloud: CommVault to Azure Blob (Storage Lock). CommVault writes its already deduplicated and compressed backups straight into an Azure Blob container that is locked with version level immutability. This adds a micro-pruning option and a full Azure cost model (blob storage by tier and redundancy, seeding, restore, compute and ExpressRoute Direct). See the AzureBlob.md file for details. The built-in Azure prices are UK South, USD, and are valid for August 2026 only - verify before use.
Exact differences between the three modes
The three modes share the same core sizing math; only a few things differ:
- Where the immutable copy lives: Mode A is a dedicated on-prem NetApp system; Mode B is NetApp Cloud Volumes ONTAP with cloud object storage; Mode C is an Azure Blob container written to directly by CommVault.
- How the data gets there: Mode A takes a NetApp snapshot then SnapVault to a SnapLock volume; Mode B sends NetApp snapshots to object storage locked by BlueXP DataLock; Mode C has CommVault write its deduplicated backups straight to Blob.
- How immutability is enforced: Mode A uses SnapLock (WORM) on the volume; Mode B uses object lock (a Retention Until Date on each object); Mode C uses Azure Blob version-level immutability (Storage Lock, which also enables Compliance Lock).
- Snapshot and filesystem reserve: applied in Mode A only (it is a NetApp disk overhead). Modes B and C do not use it.
- Safety headroom and target maximum fill level: these apply only to provisioned storage that is bought up front and cannot be over-filled. They apply in full in Mode A (on-prem provisioned disk) and to the managed-disk share only in Mode B (CVO hybrid). They do NOT apply in Mode C, and do NOT apply to the Blob-tiered share of Mode B, because elastic object storage is billed only for the bytes actually stored - there is no capacity to reserve or leave free.
- WORM storage optimisation (micro-pruning): applied in Mode C only; it reduces the locked daily changes. Modes A and B do not use it.
- Cost estimate: every mode can show a rough Estimated Storage Cost from the Storage price (per TB) you enter - Mode A as a one-off capex, Modes B and C per month and per year. In addition, Mode B shows a separate rough API cost (Put and Get on the daily changed objects, a Retention Until Date re-stamp on all objects about every 28 days, and an optional ransomware scan).
- Everything else is the same across modes: stored data after deduplication and compression, daily change, growth, the rule that nothing can be deleted inside the lock period, and disaster-recovery copies. Safety headroom and target maximum fill level are NOT identical across modes - as noted above, they apply only to provisioned storage (in full in Mode A, and to the managed-disk share only in Mode B) and do NOT apply to elastic object storage (Mode C, or the Blob-tiered share of Mode B).
The Storage price and the Estimated Storage Cost apply to all modes. Mode B and Mode C additionally reveal their own extra options (Mode B: API cost inputs; Mode C: micro-pruning).
3. Workload profiles
A workload profile is one set of data we want to protect, for example the CommVault backup store, or the production file shares. Add as many as you need with the Add workload button. The tool sizes each profile on its own and then adds them together into a grand total. Start with the profiles provided and change the numbers to match your environment. The starting value for the CommVault profile is an illustrative 500 TB and must be replaced with relevant numbers.
4. Filling in each field
For every workload profile you provide:
- Data size to protect: how much data this workload holds before immutable copies are added. If the figure is already deduplicated and compressed (for example a CommVault Data Written number), set the two ratios below to 1.
- Deduplication ratio: how many times duplicate blocks are removed. A value of 3 means 3 to 1.
- Compression ratio: extra shrink from compression. A value of 1.5 means 1.5 to 1.
- Daily data change rate: how much of the data changes each day. This is the single biggest driver of cost, because every day of change is locked for the whole period.
- Immutability (lock) period: how many days the copies stay locked and cannot be deleted. Set this to at least your backup retention so that nothing is left exposed.
- Backup / snapshot frequency: how often a copy is taken. More frequent copies give finer recovery points but do not multiply the space needed.
- Annual data growth: how fast the data is expected to grow each year.
Each field has a short help line beneath it, including the exact NetApp or CommVault command you can run to get the real number.
5. Global settings and overheads
These apply to the whole calculation. The overhead settings (snapshot and filesystem reserve, safety headroom, target maximum fill level, and disaster recovery copies) are the reason the final figure is larger than your raw data. Section 7 below explains each one in plain words with a simple example.
6. Reading the results
After you click Calculate you will see:
- Summary cards: your data, the locked daily changes, and the Capacity to purchase, which is the number to budget for, plus the projected size at the end of the horizon.
- A per workload table so you can see which workload drives the cost.
- A coloured bar showing the split between stored data, locked changes, and overhead.
- A timeline showing how the space grows over the projection period.
- An Estimated Storage Cost from your Storage price (per TB), shown for every mode (Mode A one-off; Modes B and C per month and per year), plus a separate rough API cost for Mode B.
7. Why is the total bigger than my data?
The 'Capacity to purchase' is larger than your raw data on purpose. Each item below adds a slice, and because they multiply together, a few modest percentages add up to a much bigger final figure. None of it is wasted, it is what immutable (unchangeable) backups actually require.
- Locked daily changes (usually the biggest part). Immutable backups cannot be deleted early. So every day's new/changed data must be kept for the entire lock period. Keeping, for example, 32 days of daily changes on top of today's data roughly doubles the space. These are the very copies that ransomware protection and compliance require you to keep.
- Snapshot & filesystem reserve (about 10%). The storage system needs a slice of every volume for its own housekeeping, snapshot pointers and the way NetApp writes data. Like a removal van that needs some empty space to actually pack the boxes, a disk cannot be filled to the brim and still work.
- Safety headroom (about 20%). A planning buffer for surprises: a busy month, a large one-off data load, or our estimates being slightly low. It applies only to provisioned storage that you buy in advance (Mode A, and the managed-disk share of Mode B), where you cannot delete anything to make room. It does NOT apply to elastic object storage (Mode C, and the Blob-tiered share of Mode B), which is billed only for what you actually store.
- Target maximum fill level (80%). Provisioned storage should never run completely full, performance drops sharply and, with WORM, nothing can be deleted to recover. So we size provisioned disk so your real data only ever fills 80% of what you buy, leaving 20% permanently free. Dividing by 0.8 is what turns 'data' into 'capacity to purchase' - but only for provisioned storage (Mode A and the managed-disk share of Mode B). Elastic object storage (Mode C, and the Blob-tiered share of Mode B) has no fill target because you pay per byte stored, not per byte provisioned.
- Disaster-recovery copies (number of sites). If you keep a second immutable copy at another location, so a fire or ransomware cannot destroy both, you need that capacity twice. Two sites = x2; one site = x1.
A simple example
Say you must protect 100 TB, with a 32-day lock and about 3% of data changing per day:
- Locked daily changes add roughly another 100 TB → 200 TB
- + about 10% system reserve → 220 TB
- + about 20% safety headroom → 264 TB
- divided by 80% target fill → 330 TB
- x2 for a second (DR) site → 660 TB
So 100 TB of protected data needs about 330 TB at one site, or about 660 TB across two, mainly because immutable rules force you to keep every day's changes and never delete early.
8. Deduplication Databases (DDBs), Compliance Lock and sealing
CommVault deduplication uses a Deduplication Database (DDB) that indexes the unique blocks stored in a backup storage pool. Whether the DDB needs special handling depends on HOW the backups are made immutable, not on where the DDB is stored. Here is a clear breakdown.
What Compliance Lock does to the DDB. Compliance Lock is a software-only control. It stops anyone in the CommVault console from deleting backups or lowering retention. On its own it does not change how deduplication or pruning works, and it does not require you to seal the DDB. Enabling Compliance Lock on our plans is safe for the DDB; it simply protects the retention settings.
Does the DDB location matter? No. The DDB should sit on fast local disk on the Media Agents; that is best practice and is not made immutable. The location of the DDB does not decide whether you need to seal it. What decides it is whether the deduplicated backup DATA is made immutable in a way that CommVault itself manages.
When is DDB sealing NOT required. If the backups are made immutable OUTSIDE CommVault, by NetApp SnapLock snapshots of the backup volumes with only Compliance Lock enabled in CommVault, then CommVault is not aware the storage is immutable. It keeps deduplicating and pruning normally on the live volume, and the DDB keeps running as usual on the local Media Agents. The immutability, and its extra capacity, live entirely in the NetApp snapshot layer. In this design you do NOT need to seal the DDB. The immutable lock window is simply the SnapLock retention you set (aligned to the CommVault Days retention), for example 32, 183 or 2555 days, with no plus-seal addition. The SnapLock snapshot of the data volume does not include the DDB; if ever needed, CommVault can rebuild the DDB from the library data during recovery.
When is DDB sealing REQUIRED. If you instead enable CommVault's own WORM Storage Lock on a deduplicated storage pool (CommVault manages the immutability, for example object lock on cloud object storage, or a disk library that CommVault locks), then CommVault cannot prune individual shared blocks early. To reclaim space at all, it periodically SEALS the DDB: it closes the current deduplication store and starts a new one, and only prunes a whole sealed store once its lock has fully passed (this is called macro pruning). In this case sealing is required, and CommVault configures it automatically.
- If retention is 7 days or less, the DDB seals every 7 days.
- If retention is 8 to 365 days, the DDB seals every (retention) days.
- If retention is 365 days or more, the DDB seals every 365 days (the maximum).
The real storage lock time is then WORM lock = retention + seal frequency (for example 32 + 32 = 64 days). Two effects then make this storage about 2 to 3 times larger: data is locked for the retention plus the seal frequency, and each new sealed store cannot deduplicate against the old sealed store.
Quick guide.
- Immutability from NetApp SnapLock (or any storage-side WORM outside CommVault) plus Compliance Lock only: no DDB sealing needed; lock window equals your SnapLock retention. This is our setup.
- Immutability from CommVault WORM Storage Lock on a deduplicated pool: DDB sealing is required and automatic; lock window equals retention plus seal frequency; expect about 2 to 3 times more storage.
- Non-deduplicated storage with CommVault WORM: no DDB is involved; files are simply locked for the retention days.
Recommended steps.
- Keep CommVault deduplication as it is and keep the DDB on local Media Agent disk. Do not make the DDB immutable.
- Enable Compliance Lock on the storage pool and plans to protect retention. This does not require sealing.
- Get immutability from NetApp SnapLock snapshots of the backup volumes. Set the SnapLock lock period to at least the CommVault Days retention (for example 32, 183 or 2555 days).
- We do NOT need to seal the DDB in this design. Only enable DDB sealing if we switch to CommVault WORM Storage Lock, in which case it is set automatically and we must re-size for retention plus seal frequency.
- Protect the DDB with regular DDB backups, and keep DDB and index backups off the immutable (WORM) copy.
- Size capacity for the SnapLock retention window (this calculator does that). If we later move to CommVault WORM Storage Lock, re-size for retention plus seal and reduced deduplication.
9. WORM storage optimisation (micro-pruning)
What micro-pruning is. CommVault deduplication reclaims freed space in two ways. Micro-pruning is fine-grained reclamation inside the deduplication store: it truncates chunk files, drills holes to free individual unreferenced blocks, or deletes whole files. Macro-pruning is coarse: it can only delete whole objects or whole sealed deduplication stores, and only after the entire store's lock has expired. On immutable (WORM) storage you normally cannot modify locked objects, so CommVault falls back to macro-pruning only (it seals the deduplication database and holds the whole store until the lock expires), which is why WORM deduplication typically grows to about 2 to 3 times.
What WORM storage optimisation does. WORM storage optimisation is a CommVault capability (the EnableOptimizedWORMStorageLock setting) that lets CommVault do job-level micro-pruning even on WORM object storage, reclaiming eligible data while still enforcing the object lock and retention. It recovers space that macro-pruning would otherwise force you to keep locked, so in this tool it reduces the locked daily changes by the percentage you set.
Why it applies to Mode C only. Micro-pruning is a CommVault deduplication feature, so it only helps when CommVault owns BOTH the deduplication AND the WORM object storage. That is only true in Mode C, where CommVault writes deduplicated backups directly to Azure Blob and manages immutability with Storage Lock (version-level immutability). In Mode A (on-prem NetApp SnapLock) and Mode B (Cloud NetApp CVO / BlueXP DataLock) the immutability is provided by NetApp SnapLock, not CommVault: the locked capacity lives in NetApp WAFL snapshots that hold the changed blocks for the lock period regardless of anything CommVault does, so a CommVault deduplication feature has nothing to optimise there. NetApp snapshots are already block-incremental, which is NetApp's own efficiency and not this feature.
In this calculator. The micro-pruning slider (0 to 30%, an estimate) appears only in Mode C and reduces just the locked daily changes: Locked daily changes = lock days x daily change x (1 - micro-pruning percent). In production it requires the CommServe additional setting EnableOptimizedWORMStorageLock = 1, and the actual reclaim depends on your data's churn and deduplication pattern, so treat the percentage as a planning assumption to validate, not a guarantee.
10. Getting your real numbers
On NetApp use volume show-space, volume snapshot show, volume efficiency stat, volume snaplock show, and snapmirror show -fields last-transfer-size. In CommVault use Data Written compared with Application Size to work out the change rate, and the Storage Policy Copy retention (Days and Cycles) to choose the lock period.
11. Important notes and assumptions
- On NetApp SnapLock Compliance the default lock is 30 years if you do not set it first, so always set the lock period before the first transfer.
- In CommVault, turning on Storage Lock is irreversible and retention cannot be lowered, and it also switches on Compliance Lock. Enabling Compliance Lock on its own is recommended to stop retention being reduced.
- Set the lock period to at least the CommVault retention, otherwise some backups could be left unprotected.
- All sizes use decimal units: 1 TB = 1000 GB = 1,000,000 MB. This tool does not use binary GiB or TiB (1024-based).
- Sizes use decimal units where 1 TB is 1000 GB. Treat all results as planning estimates that needs to be confirmed.