How to Prevent Snapshot Replication From Filling the Destination Pool

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Prevent Snapshot Replication From Filling the Destination Pool

Snapshot replication fills a destination pool when retained snapshots and changed blocks accumulate faster than the destination’s cleanup policy can release them.

The preventive fix is to design source retention, destination retention, replication cadence, and free-space alarms as one policy. A replica can legitimately keep more history than the source, but that choice must be bounded. Track which snapshots are needed as incremental bases, how much unique data old snapshots pin, whether bookmarks can replace some local source snapshots, and how much headroom remains before the next large change set arrives.

Set a Destination Retention Policy Explicitly

Decide how many hourly, daily, weekly, and monthly restore points the destination should keep, and document why that history differs from the source. Do not assume replication software will automatically prune every old destination snapshot when the source deletes it.

A ZFS replication overview explains that replication needs snapshot policy because snapshots are both recovery points and incremental transfer boundaries.

Apply the shortest retention to high-churn datasets unless longer history has a concrete recovery value. Keep low-churn archives on a different schedule so one global policy does not waste space where frequent restore points add little value.

Estimate How Much Change Old Snapshots Pin

Measure snapshot USED, written data between snapshots, and the destination pool’s free space before and after large deletes, moves, media replacements, or VM rewrites. A snapshot can keep old blocks alive after live data disappears.

A TrueNAS replication note warns that snapshot churn retains old blocks even when the current live dataset becomes smaller.

Use that churn rate to size retention. A destination with 30 days of rapidly changing VM images may need far more capacity than another dataset with the same live size but mostly append-only family photos.

Reserve Pool Headroom for the Next Replication

Set an operational free-space floor that accounts for the largest realistic incoming incremental plus local snapshot growth and normal filesystem overhead. Alert before reaching the floor rather than when the pool is already nearly full.

Oracle’s snapshot-retention discussion notes that retention controls snapshot growth instead of treating snapshots as cost-free because creation is initially cheap.

Pause or shorten noncritical retention before the destination reaches an emergency state. A replication target needs room to receive and commit new blocks, so leaving only enough space for today’s live dataset is not a safe capacity plan.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Use Bookmarks Where They Preserve Incremental History

When your ZFS version and replication tooling support bookmarks, evaluate whether a bookmark can preserve the incremental send reference after an old source snapshot is no longer needed as a full local restore point.

An offsite-backup design shows how bookmarks preserve incremental bases while allowing snapshot retention to remain independent.

Do not replace every snapshot with a bookmark. Destination restore history still requires actual snapshots, and replication tools vary in how they manage common bases. Use bookmarks only where they simplify the source side without weakening the destination’s recovery objective.

Protect Only the Snapshots Replication Still Needs

Identify the most recent common snapshot shared by source and destination before pruning. When tooling uses holds or equivalent protections, verify that cleanup jobs respect them and that obsolete holds are eventually released.

The FreeBSD ZFS handbook explains that holds protect shared snapshots until the hold is explicitly released.

Do not retain every historical snapshot simply because one common base is required. Protect the small set replication actually needs, then let the destination retention policy govern older independent recovery points.

Audit Replication Snapshots Separately From Backup History

Some tools create their own synchronization snapshots in addition to your scheduled hourly or daily snapshots. List both classes on the destination and make sure the tool-generated set cannot grow without a cleanup rule.

A Sanoid and Syncoid discussion explains that sync snapshots act as guardrails rather than every replication snapshot being intended as long-term backup history.

Review the destination monthly or after any large dataset move. The policy is healthy when expected restore points remain, the next incremental has a valid common base, and pool free space stays above the defined floor. The related ZimaSpace article on snapshot space diagnosis is the recovery branch when the destination is already unexpectedly full.

Frequently Asked Questions

Should the destination keep exactly the same snapshots as the source?

Not necessarily. A backup target can keep longer history, but the difference should be intentional, capacity-tested, and governed by its own retention policy.

Can deleting files on the source immediately free destination space?

No. Replicated snapshots can continue referencing older blocks after the live file disappears. Space is released only when no retained snapshot or other reference still needs those blocks.

Does deleting the oldest snapshot always free the most space?

No. Snapshot space is shared between recovery points. Estimate or measure unique referenced space and protect any common snapshot still required for incremental replication.