→ Applies to: SynetoOS 6.x and above

IMPORTANT
If protected data is rewritten frequently — even when the file count doesn't change — snapshots can consume far more space than expected. This is not a malfunction. It's the expected behavior of a copy-on-write storage system (ZFS) combined with the configured retention policy.

How snapshots work on ZFS

• A snapshot is a near-zero-cost "photo." At creation, it copies nothing — it points to the same blocks as the live data.
• ZFS is copy-on-write. When a block is modified or deleted, the old block is not overwritten. It stays on disk as long as at least one snapshot still references it.
• Snapshot space grows based on how much data is modified or deleted after the snapshot was taken, not how much data the snapshot "contains."

WRITTEN vs USED

Step 1. Connect to SynetoOS appliance via SSH as admin

ssh admin@<your_ip_address_or_hostname>

Step 2. Get root privileges

sudo su -

Step 3. List all datasets

zfs list

EXAMPLE OUTPUT

NAME                          USED  AVAIL  REFER  MOUNTPOINT
syn-pool01                    12T   8.5T   96K    /syn-pool01
syn-pool01/veeam-repo         5.5T  8.5T   5.5T   /syn-pool01/veeam-repo
syn-pool01/vm-datastore       3.2T  8.5T   3.2T   /syn-pool01/vm-datastore

NOTE
Under the name field can check all your available datasets.

Step 4. List zfs snapshots for a specific dataset (replace <dataset> with the correct information)

zfs list -p -o name,used,written -t snapshot <dataset>

EXAMPLE

zfs list -p -o name,used,written -t snapshot syn-pool01/veeam-repo

Column	Meaning
WRITTEN	How much data was written between the previous snapshot and this one. Measures change, not occupied space.
USED	Space occupied exclusively by that snapshot — blocks that exist only because they were later overwritten or deleted. This is the space freed by deleting only that snapshot.
usedbysnapshots	Total space retained by all snapshots combined, including blocks shared across multiple snapshots (blocks that don't appear in any single snapshot's USED).

NOTE 
It's normal for usedbysnapshots to be much higher than the sum of individual USED values

• WRITTEN: A dataset of 5.5 TB with WRITTEN = 5.5 TB means virtually 100% of blocks changed in that interval.
• USED: A snapshot with WRITTEN = 5.5 TB but USED = 32 GB means 5.5 TB was rewritten, but almost all of those blocks are still live or shared with other snapshots. Only 32 GB is unique to that snapshot. Deleting it would free 32 GB, not 5.5 TB.

The typical case: "But My Files Don't Change!"

ZFS counts blocks, not files. Data can be rewritten in full even when files "look" the same.

Common causes:

• The protected dataset is a third-party backup repository/target (e.g. Veeam), and the backup software periodically performs an active full or a CBT (Changed Block Tracking) reset — rewriting the entire set even when content is nearly identical.
• Databases, VMs, or large files rewritten internally (defrag, compaction, re-indexing).
• Applications that rewrite files entirely instead of modifying them in place.

NOTE 
Each full-rewrite cycle creates a new copy of the blocks. The previous copy stays retained by snapshots until retention expires it.

Snapshot space ~= (number of full rewrites covered by retention) x (dataset size)

EXAMPLE
A ~5.5 TB dataset with a full rewrite every 5–6 weeks and ~4 months retention retains ~3–4 old full footprints, resulting in ~18 TB of snapshot space alone, on top of the ~5.5 TB live data.

IMPORTANT
If the workload periodically rewrites 100% of its footprint, long retention multiplies space usage. The longer the retention, the more superseded generations accumulate.

Diagnose the Issue

Step 1. Check overall dataset occupation (replace <dataset> with the correct information)

zfs get -p used,usedbydataset,usedbysnapshots,referenced <dataset>

NOTE
If usedbysnapshots >> usedbydataset, the space is held by snapshots.

Step 2. Find periodic full-rewrites (replace <dataset> with the correct information)

zfs list -p -t snapshot -o name,written,used,creation <dataset>

NOTE
Look for snapshots where WRITTEN is close to the dataset size, and measure how often this recurs (e.g. every 5–6 weeks).

Step 3. Identify where space is actually retained

IMPORTANT
Sort by USED, not WRITTEN.
If the sum of USED values is low but usedbysnapshots is high, the space is held in blocks shared across many snapshots. Deleting a single snapshot won't free it — retention needs to be shortened instead.

How to reduce space usage

• Reduce retention so it no longer spans more than one full-rewrite cycle (e.g. weeks instead of months).
• Reduce upstream full-rewrite behavior: configure backup software to avoid frequent active-full backups (use incremental/synthetic full instead); avoid recurring CBT resets.
• Evaluate necessity — check whether the dataset really needs snapshots this frequent (hourly) with this retention.
• Monitor pool occupation (optional) — act immediately above 85–90%, since performance and margins degrade past that point.

What This Is Not

• Deleting an old "base" snapshot does not cause ZFS to rewrite or "promote" the entire disk footprint onto the next snapshot. ZFS doesn't rewrite anything on deletion — it only frees the blocks unique to the removed snapshot.
• A high WRITTEN value is not "wasted space" — it's the amount of change.
• This is not a product defect — it's expected copy-on-write behavior combined with the configured retention.

FAQ

Q: I only have a few GB of files, why do snapshots use TBs?
A: Because it counts how many blocks are rewritten, not how many files exist. If data is periodically rewritten in full, every previous version stays in snapshots until retention expires it.

Q: If I delete the snapshot showing WRITTEN = 5 TB, do I free 5 TB?
A: No. You only free its USED value (often just a few GB). The large space is shared across many snapshots and is only freed by reducing overall retention.

Q: Is this a Syneto bug?
A: No. This is normal storage behavior. It's resolved by adjusting retention configuration and/or fixing the upstream source that periodically rewrites everything.