Home / Tools / Snapshot Space Overhead Estimator

Snapshot Space Overhead Estimator: How Much Storage Do Your Snapshots Really Use?

This snapshot space overhead estimator calculates how much additional storage your Btrfs or ZFS snapshots will consume based on snapshot frequency, retention policy, and data change rate. Helps you avoid running out of space from unchecked snapshot growth.

Snapshots are one of the best features on a modern NAS, instant recovery points that let you roll back files, folders, or entire volumes in seconds. But there's a catch most users don't discover until they get a "volume almost full" warning: snapshots consume real storage space, and the amount depends on how much your data changes.

This calculator estimates how much space your snapshot policy uses based on your dataset size, how frequently data changes, and how many snapshots you keep. Whether you're troubleshooting unexpected space consumption or planning a new snapshot policy, this tool helps you understand the true cost before you run out of room.

Snapshots are not backups. They protect against accidental deletion and file corruption, but they live on the same volume as your data. If the drive fails, you lose both. Always pair snapshots with an off-device backup, see the 3-2-1 backup strategy guide.

Your Snapshot Policy

The size of the data being protected, not your total volume size.
How much of your data changes each day. If unsure, "Low" suits most home NAS users.
More frequent = smaller individual snapshots, but more of them.
Total snapshots kept. With hourly snapshots, 30 retained = ~1.25 days of history, not 30 days.
Available on Btrfs and ZFS. Minimal CPU impact on modern NAS hardware.
ZFS only. Requires ~1-5 GB RAM per TB. Not available on most consumer NAS.
Doesn't affect the calculation, helps tailor tips to your platform.

Results

How this estimate works: This calculator models Copy-on-Write (CoW) snapshot behaviour where each snapshot stores only the blocks that changed since the previous snapshot. The estimate assumes a uniform daily change rate spread evenly across all snapshot intervals.

Real-world variance factors:

  • Actual churn is rarely uniform, large file operations (backups, renders, database rebuilds) cause spikes
  • Block size and alignment affect how much data is captured per change
  • Deleting files within a snapshot-protected volume doesn't free space until all referencing snapshots expire
  • Compression ratios vary by data type (media: low, documents: high, databases: moderate)

Use this estimate as a planning guide, not a precise prediction. Check your NAS or filesystem's actual snapshot space usage to calibrate against this estimate.

Tips for Your Policy

Frequently Asked Questions

Snapshots are point-in-time views of your data stored on the same volume. They're fast to create and restore, making them ideal for recovering accidentally deleted or modified files. However, because they live on the same physical drives as your data, a hardware failure destroys both. Backups are copies of your data stored on a separate device or location. You need both, snapshots for convenience and speed, backups for disaster recovery. Read our 3-2-1 backup strategy guide for how to structure this.
Snapshot space consumption is proportional to how much data changes between snapshots. If you edit large files (databases, virtual machine disks, video projects), each snapshot must preserve the original versions of every modified block. Users with high-churn workloads and long retention policies commonly see snapshots consuming 30-50% of their dataset's size. This calculator helps you estimate whether your policy matches your workload, and whether reducing frequency or retention would help.
On Synology, check Storage Manager → Volume → Usage history for write patterns. On ZFS, compare the 'used' column in zfs list -t snapshot over consecutive days, the difference is your daily churn. On Btrfs, btrfs filesystem du gives snapshot-aware space reporting. If you can't measure directly, start with "Low" (1-2%) for typical home NAS workloads, media libraries, documents, and photos. If you run databases or VMs on the same volume, "High" (7.5%) is more realistic.
Not always. In Copy-on-Write filesystems, space is only freed when the last snapshot referencing a given block is deleted. If you delete snapshot #5 but snapshots #4 and #6 still reference some of the same blocks, those blocks won't be freed. Deleting the oldest snapshots in order typically frees the most space. After deleting snapshots, space reclamation may take minutes to hours depending on filesystem and volume size.
There's no universal answer, it depends on how far back you'd realistically need to restore. For most home NAS users, 7-14 daily snapshots (1-2 weeks of history) provides a practical recovery window without excessive overhead. If you need more granularity for active projects, consider hourly snapshots with shorter retention (e.g., 48 hourly = 2 days). The right number is the shortest retention that still covers your realistic "oops" window. Use our NAS Sizing Wizard to factor snapshot overhead into your storage planning.
The act of creating a snapshot is nearly instantaneous, it's a metadata operation, not a data copy. However, snapshots can cause a small write performance penalty because the filesystem must copy the original block before overwriting it (Copy-on-Write). On modern NAS hardware, this overhead is typically 5-10% and rarely noticeable. The bigger risk is running your volume close to full capacity due to snapshot accumulation, which causes significant performance degradation on most filesystems.
Both use Copy-on-Write, so the fundamental space overhead is similar for the same workload. The differences are in features: ZFS supports native deduplication (at significant RAM cost), native compression with more algorithm choices, and send/receive for efficient snapshot replication. Btrfs supports compression (lzo, zstd) and send/receive but lacks stable deduplication. For most home NAS users on Synology (Btrfs) or TrueNAS (ZFS), snapshot space behaviour is comparable, your churn rate and retention policy matter far more than the filesystem choice. Read our NAS filesystem comparison guide for a full breakdown.
Yes. Snapshots consume real space on the same volume. If your snapshot overhead grows unchecked (due to high churn and long retention), it can fill the volume to capacity. When a volume is full, both new data writes and snapshot creation fail, and NAS performance degrades severely. Most NAS platforms let you set snapshot space limits or automatic purge policies, configure these as a safety net. This calculator helps you estimate whether your current policy is on a sustainable trajectory.

AU Cloud Backup vs On-NAS Snapshots: Cost Comparison (early 2026)

Snapshots are not a backup, they live on the same volume. Pair them with a proper off-site backup. AU cloud backup pricing for context:

ServiceStorageAU monthly costNotes
Backblaze B21 TB~$8 AUDS3-compatible, good Synology/QNAP HBS integration
iCloud+200 GB$1.49 AUDApple devices only, limited NAS integration
iCloud+2 TB$14.99 AUDFamily sharing, not a NAS backup solution
Google One2 TB$14.99 AUDGoogle Drive, limited NAS direct integration
Amazon S31 TB~$28 AUDStandard storage, egress costs extra
Wasabi1 TB~$9 AUDNo egress fees, popular for NAS offsite backup

AU NAS Snapshot Recommended Practice

A practical snapshot policy for most AU home NAS users:

NBN upload speeds: AU residential NBN upload speeds (typically 20-50 Mbps on NBN100/250) can make initial seeding of large datasets to cloud slow, allow days to weeks for first backup of a multi-TB dataset. Use our Transfer Speed Estimator to calculate exact upload time before choosing a cloud backup strategy.