Size the storage before you quote it.
Feed in RVTools data or manual pool numbers, tune reduction, protection, replication, snapshots, and growth per pool โ and get a year-by-year raw-capacity plan plus a customer-ready report. 100% in your browser, nothing uploaded.
โ๏ธHow it works
1๏ธโฃ Load demand
Drop an RVTools export (.xlsx) and it rolls up provisioned and used storage per cluster, reads datastore totals for validation โ or type pool numbers in manually, or try the demo environment.
2๏ธโฃ Configure storage
The tunable mid-step: per-pool demand basis, data-reduction ratio, local protection (mirror / RAID / erasure coding), remote replication, snapshot retention, overhead, and free-space headroom. Growth horizon, compounding or static, set globally with per-pool overrides. Live raw-capacity previews as you tune.
3๏ธโฃ Get the growth plan
Year-by-year raw-capacity projections, per-pool worked math, validation against current usable capacity, SE talking points, and a downloadable HTML briefing report.
๐ฅWhat it reads from RVTools
| Tab | What it unlocks |
|---|---|
vInfo | Per-cluster VM inventory: provisioned and used storage โ the only required tab. Storage counts regardless of power state (templates excluded) |
vDatastore | Datastore capacity totals โ validates the plan's raw numbers against what the estate actually has |
vSnapshot | Total snapshot footprint, shown as context for retention tuning |
vDisk | Thin vs thick counts โ feeds cleanup findings |
Same tolerant parser as RVTools Analyzer and Server Sizer โ modern and legacy column names both work, missing tabs degrade gracefully. No export handy? Manual entry takes pool-level totals, which is all the math needs.
๐งฎSizing math, explained
For each pool and each year, the chain runs: grow the logical demand, shrink it by data reduction, then multiply back up through every protection layer, overhead, and headroom:
logical[y] = basis ร (1+g)y compounding โ or basis + yรgTB static
raw[y] = (logical[y] รท reduction) ร (1 + snapCopies ร snapSize%) ร localFactor ร (1 + remoteCopies) ร (1 + overhead%) รท (1 โ spare%)
Worked example โ 40 TB used, 20%/yr compound for 3 years, 1.8ร reduction, 1 snapshot copy at 25%, 2-way mirror, 10% overhead, 15% headroom:
| Step | Numbers | Result |
|---|---|---|
| Demand basis | 40 TB used (today) | 40.0 TB |
| Year-3 logical | 40 ร 1.20ยณ | 69.1 TB |
| Data reduction | 69.1 รท 1.8 | 38.4 TB |
| Snapshot overhead | ร (1 + 1 ร 0.25) | 48.0 TB |
| Local protection | ร 2.0 (2-way mirror) | 96.0 TB |
| Remote replication | ร 1 (none) | 96.0 TB |
| System overhead | ร 1.10 | 105.6 TB |
| Free-space headroom | รท (1 โ 0.15) | 124.2 TB raw |
Every pool in the tool shows this worked chain with your numbers plugged in โ today (Year 0) and at the horizon year. The protection layer is where storage quotes are won or lost, so it gets its own explicit step.
โ๏ธHonest limitations
- This is capacity sizing, not performance sizing. It doesn't model IOPS, latency, or workload behavior โ validate the final spec against performance data.
- Data-reduction ratios are planning assumptions, not measurements. Dedupe/compression is workload-dependent โ validate with vendor sizing tools before quoting.
- Snapshot retention cost is an estimate of change rate โ your per-copy percentage is a judgment call.
- Replication bandwidth and RPO aren't modeled โ only the capacity footprint of the replica copies.
- No pricing โ the output is raw TB per pool per year, which your VAR tooling turns into quotes.
๐ฌFrequently asked questions
๐ Is my data uploaded anywhere?
No. Files are read with the browser's FileReader API and parsed in memory by a vendored copy of SheetJS running in this page; manual entries never leave the form. There is no server and no network request carrying your data โ check devtools' network tab, or disconnect after the page loads.
๐พ Is anything stored in my browser?
Only if you use the Projects feature: named saves and autosave live in this browser's localStorage โ 100% local, never uploaded, no cookies or tracking. Your RVTools data itself stays in the page's JavaScript memory; hit "Clear session data" or close the tab and it's gone. Export gives you a portable .json you can keep with the engagement files.
โจ๏ธ Do I need an RVTools export, or can I type numbers in?
Either. The export gives you per-cluster provisioned/used storage automatically, plus datastore totals for validation. Manual entry just needs pool-level totals: VMs, provisioned TB, used TB, and optionally current usable TB โ five minutes with the customer's capacity spreadsheet.
๐๏ธ What's a "pool"?
From an RVTools export, pools are per-cluster storage demand (datacenter / cluster) โ aligned with how Server Sizer groups things. With manual entry you define your own pools, e.g. splitting by tier (flash vs capacity) or workload. One pool, one set of tunables.
โ๏ธ Should I size on "used" or "provisioned"?
Used is actual written data โ the honest footprint. Provisioned includes thin-provisioned commitments that haven't materialized yet โ more conservative, and safer when the estate is thin-heavy with headroom to fill. The tool defaults to used; flip to provisioned when you want the conservative number on the quote.
๐๏ธ What should I use for data reduction?
The 1.8ร default is a middle-ground planning assumption. The rule of thumb baked into the findings: mirroring without meaningful reduction is the most expensive way to buy storage โ every 0.5ร of reduction improvement is worth real TB at the horizon. Vendor reduction guarantees vary by workload; validate before you quote their number.
๐ Compounding or static growth?
Compounding applies a %/yr rate on the prior year's total โ right when growth feeds on itself (organic data growth). Static adds a flat TB/yr โ right when you know the number from the backup growth trend or a project pipeline. You can override the rate per pool while keeping the mode.
๐งฑ What's the difference between overhead and headroom?
System overhead is capacity the array consumes for itself โ formatting, metadata, system reserve. Free-space headroom is slack you deliberately keep โ for rebuilds, snapshot bursts, and not running the array at 100%. The tool treats overhead as a multiplier and headroom as a divisor, which is why small headroom changes move the raw number a lot.
๐ค Can I share the results with my team or the customer?
Yes โ the Growth plan tab generates a standalone HTML briefing you can download and email. Fully self-contained, no external dependencies, and it contains only the analysis, which you control. Scrub customer names from pool labels first if the report leaves your org.
๐ฒ Does it do pricing?
No โ it produces raw TB per pool per year. Your VAR quoting tooling turns that capacity plan into dollars.