> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/monitor-the-weka-cluster/the-wekaio-support-cloud/lwh-storage-sizing.md).
# LWH storage sizing
Size /opt/wekahome/data for Local WEKA Home deployments on K3s. Capacity depends on monitored WEKA processes and statistics retention. This storage holds time-series statistics, events, and queues.
## Storage sizing summary
* Provision approximately 1 GiB per monitored WEKA process per month of statistics retention.
* Add 40 GiB for events, queues, and databases.
* Size for the retention window plus one month. VictoriaMetrics removes complete monthly partitions.
Each process runs on one CPU core, so the monitored process count is the number of cores used on the cluster backends for the Management, Frontend, Compute, and Drives roles, plus the cores used on the clients. This is the same count that `wekaNodesMonitored` takes.
## Storage requirements by process count
Use these capacities for the default 30-day statistics retention. Values include VictoriaMetrics, Postgres, and queue storage.
| Monitored WEKA processes | /opt/wekahome/data |
| ------------------------ | ------------------ |
| 100 | \~140 GiB |
| 250 | \~290 GiB |
| 500 | \~540 GiB |
| 1,000 | \~1 TiB |
| 2,000 | \~2 TiB |
| 5,000 | \~5 TiB |
| 10,000 | \~10 TiB |
| 20,000 | \~20 TiB |
For a different retention, multiply the per-process capacity by `(retention_days + 31) / 61`.
This is approximately 0.7 for 14 days and 2 for 90 days. For 3,000 processes at 45-day retention, allocate approximately 3.8 TiB.
## Storage consumers
| Consumer | Scales with | Share |
| -------------------------- | ------------------------------------ | ----------------- |
| VictoriaMetrics statistics | Processes × retention | Approximately 99% |
| Events DB (Postgres) | event activity, bounded by retention | small, bounded |
| Main and support databases | Fixed | Negligible |
| FSQ and NATS queues | Transient backlog | Tens of GiB |
VictoriaMetrics statistics consume most of the storage.
## Statistics storage calculation
**Active series**: A unique time-series measurement stored by VictoriaMetrics.
VictoriaMetrics capacity depends on active series, samples, and sample size. LWH uses approximately 13 MiB per monitored process each day. This estimate uses 60-second raw resolution and no downsampling.
Use this formula. It includes monthly-partition peak usage and VictoriaMetrics merge headroom:
```
stats_disk ≈ 13 MiB × processes × (retention_days + 31) × 1.3
```
This simplifies to approximately 1 GiB per process per month of retention.
The estimate is validated against these environments:
* **Production fleet**: 124 TiB across six `vmstorage` shards for 336,000 processes. Usage was approximately 12.5 MiB per process daily.
* **Cluster simulator**: 6,400 processes used 24.5 GB in 6.5 hours. Usage was approximately 13.4 MiB per process daily.
### Storage requirements by retention period
Values include approximately 40 GiB for events, queues, and databases.
| Monitored processes | 14 days | 30 days (default) | 90 days |
| ------------------- | ---------- | ----------------- | --------- |
| 100 | \~110 GiB | \~140 GiB | \~240 GiB |
| 500 | \~410 GiB | \~540 GiB | \~1.1 TiB |
| 1,000 | \~780 GiB | \~1.05 TiB | \~2 TiB |
| 5,000 | \~3.7 TiB | \~5 TiB | \~9.8 TiB |
| 20,000 | \~14.5 TiB | \~20 TiB | \~39 TiB |
### Storage requirements by resource preset
Resource presets use the expected monitored process count:
| Preset | wekaNodesMonitored | /opt/wekahome/data @ 30-day retention |
|---|
small | ≤ 1,000 | up to ~1 TiB |
medium | 1,000 – 5,000 | ~1 – 5 TiB |
large | 5,000 – 10,000 | ~5 – 10 TiB |
xlarge | 10,000+ | 10 TiB+ |
## VictoriaMetrics partition behavior
VictoriaMetrics stores data in monthly partitions. It removes a partition only after all data exceeds retention. A 30-day retention period can therefore use one or two months of storage. Peak use occurs immediately after a new month begins.
`wekaNodesMonitored` selects a resource preset. It does not change retention. Set retention with `retentionDays.stats`. The default is 30 days.
## Events database capacity
The events database uses garbage collection. Its size eventually stabilizes:
* **Raw events**: Deleted after `retentionDays.events`. The default is 30 days.
* **Hourly aggregates**: Retained for 365 days. The database stabilizes after approximately one year.
Typical deployments use less than the default 20 GiB events volume. Do not disable events retention. Without a retention period, events storage grows without limit.
## Validate capacity after deployment
Run `homecli local diagnose` to view VictoriaMetrics `data_size` and monitored process count. Calculate the observed daily rate:
```
bytes_per_node_per_day = vmstorage_used ÷ node_count ÷ days_of_data_on_disk
```
Measure after several weeks. Adjust capacity using the observed rate. `TimeToFull` provides early warning before storage fills.
## Sizing considerations
* **Role mix**: I/O-intensive deployments use approximately 13 MiB per process daily. Client-heavy deployments use less. Management-heavy deployments use more.
* **Retention**: LWH stores full-resolution statistics without downsampling. Doubling retention approximately doubles statistics storage.
* **Measured usage**: Use `homecli local diagnose` to refine estimates for your deployment.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.weka.io/monitor-the-weka-cluster/the-wekaio-support-cloud/lwh-storage-sizing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.