Calculate storage and lookup overhead from retaining many Helm release history entries.
Both deploys (installs/upgrades) and rollbacks create a new revision in a Helm release's history, so the total number of history entries ever created is the sum of the two. Helm continuously prunes the oldest entries once the count exceeds `--history-max`, so the number actually retained and available for future rollback is capped at that limit — meaning very active releases can lose the ability to roll back to early revisions long before the release itself is decommissioned.
retainedEntries = min(deploys + rollbacks, maxHistory)
No — Helm tracks rollbacks as their own revision type distinct from install/upgrade, but both consume a slot in the same bounded history list subject to `--history-max` pruning.
Not from Helm's own storage — once pruned, the Secret/ConfigMap backing that revision is deleted; recovery would require an external backup of release manifests (e.g. keeping rendered YAML in Git) taken before pruning occurred.
Yes — if a release frequently needs to roll back several versions, a higher `--history-max` keeps more rollback targets available; balance this against the added Secret storage each retained revision costs.