Estimate storage snapshot size based on change rate and retention period.
Copy-on-write and redirect-on-write snapshots only store blocks that changed after the snapshot was taken, so snapshot size grows roughly linearly with the daily change rate multiplied by how many days have elapsed since it was created — the longer a snapshot is retained, the more accumulated changes it must track, until in the worst case it approaches the full size of the source volume (every block has changed at least once).
Snapshot size
size = min(source_size, source_size × daily_change% × days_since_last)
A copy-on-write snapshot can never store more changed data than the source volume actually contains — once every block has been overwritten at least once since the snapshot was taken, the snapshot has effectively captured a full copy and further growth stops.
Because snapshot size grows with elapsed time, a snapshot left in place for weeks or months accumulates far more changed-block overhead than a short-lived one — this is why most storage platforms recommend deleting or consolidating snapshots on a schedule rather than leaving them indefinitely.
Yes — the daily change rate is the dominant driver of snapshot growth; a volatile volume (databases, active VMs) with a high change rate will consume much more snapshot space per day than a mostly static volume (archives, templates), even at the same retention period.