Why Does Snapshot-Only Space Increase After Large Files Are Deleted?

Snapshot-only space can increase after deletion because older snapshots keep references to blocks that the live filesystem no longer needs.

This behavior is normal for copy-on-write snapshots, but the number shown by a NAS can be confusing because “snapshot size,” “snapshot-only space,” “referenced space,” and “reclaimable space” are not interchangeable. Deleting a large live file may reduce current dataset usage while making old blocks unique to one or more retained snapshots. Diagnose the exact metric and retention chain before deleting snapshots or assuming the snapshot folder created another full copy.

Confirm Which Snapshot Metric Actually Increased

Record pool usage, live dataset usage, aggregate snapshot usage, per-snapshot unique usage, and the size of the file that was deleted. Use measurements from the same dataset and the same time window.

Synology’s Snapshot Replication guidance separates visible snapshots from the space they consume and provides controls for calculating reclaimable space. Its snapshot space controls illustrate why the snapshot list and the volume’s reclaimable capacity must be checked together.

If only snapshot-only usage rises while live usage falls, the deletion probably shifted ownership of existing blocks rather than creating new file content. If total pool usage also rises, inspect new snapshots, replication staging, application versions, or other writes during the same period.

Understand Why Deletion Makes Old Blocks Unique to a Snapshot

A snapshot initially shares most blocks with the live filesystem. When the live filesystem overwrites or deletes data, the snapshot continues referencing the older blocks so that its point-in-time view remains intact.

Oracle’s ZFS administration guide explains that snapshot used space grows when previously shared blocks become unique to the snapshot after the active dataset changes.

The deleted file is therefore absent from the live directory but still readable from the older snapshot. The storage is not duplicated at deletion time; the accounting changes because the live filesystem released its reference while the snapshot retained one.

Check Whether Several Snapshots Still Share the Deleted Data

List snapshots created before and after the deletion. Identify the oldest and newest recovery points that can still browse or restore the deleted file.

NetApp’s knowledge base notes that older snapshots retain deleted blocks, so deleting one recovery point may release little space when another snapshot still references the same data.

Do not add the displayed size of every snapshot and assume that total is independently allocated. Shared blocks can appear in many snapshot views while consuming physical storage only once until the last reference is removed.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separate the Snapshot Folder View From Physical Storage Use

Browsing a snapshot folder can make every historical file appear to exist as an ordinary copy. That directory view is a recovery interface, not a literal second folder tree allocated byte for byte.

The FreeBSD ZFS handbook describes snapshots as point-in-time dataset states that share storage until changed data must be preserved. Its snapshot model helps distinguish the files visible through a snapshot path from the blocks that are physically unique to it.

Do not delete files manually inside a hidden snapshot-management directory. Use the NAS snapshot manager or the filesystem’s supported snapshot command so retention metadata and replication state remain consistent.

Compare ZFS and Btrfs Snapshot Accounting Carefully

ZFS and Btrfs both use copy-on-write references, but their dashboards and command-line tools can report exclusive, referenced, shared, or estimated space differently. Use the metric documented for the active filesystem.

Fedora Magazine’s Btrfs walkthrough explains that Btrfs snapshots retain old references as live files diverge, which is the same core reason deleted source files can remain represented in snapshot storage.

A cross-platform NAS dashboard may simplify these values into one “snapshot size.” When the displayed number looks impossible, verify it with filesystem-native usage and snapshot commands before changing retention.

Estimate Reclaimable Space Before Removing Recovery Points

Select one expired snapshot or a bounded range of snapshots and preview the expected reclaim when the platform supports it. Compare the estimate with the snapshot timeline that still contains the deleted file.

Klara Systems explains that snapshot storage grows with divergence, so age and change rate are more useful retention signals than snapshot count alone.

Delete only snapshots that fall outside the recovery policy. Removing the newest snapshot first may free little space, while deleting an older chain can remove recovery points that newer incrementals or replication jobs still require.

Verify Space Recovery Without Repeating the Broader NAS Check

After pruning one approved snapshot range, wait for background reclamation and refresh the same live, snapshot-only, and pool-level measurements. Confirm that applications and replication tasks remain healthy.

The ZimaSpace guide to checking snapshots and recycle bins covers the wider question of which retention layer is consuming NAS capacity; this article focuses only on why snapshot-only usage increases after deletion.

The diagnosis is complete when the deleted file is absent from live data, the expected snapshots still restore it, snapshot-only usage matches the retained timeline, and approved pruning releases the predicted amount without breaking replication or recovery goals.