null

ZFS Snapshots

Enterprise Resource Center • ZFS Knowledge Base

ZFS Snapshots

ZFS snapshots preserve a read-only, point-in-time view of a filesystem or volume without immediately creating a complete second copy of its data. They provide a powerful foundation for file recovery, rollback, cloning, replication and storage protection workflows.

Point-in-Time Recovery Read-Only Copy-on-Write Rollback Replication
Tech Supply Direct
Quick Answer

What Is a ZFS Snapshot?

A ZFS snapshot is a read-only representation of a ZFS filesystem or volume at a specific point in time. Instead of immediately copying every block into another location, ZFS preserves references to the blocks that existed when the snapshot was created.

Snapshot creation is extremely fast and initially requires essentially no additional data space. Storage consumption increases later when the active dataset changes and older blocks must remain available because one or more snapshots still reference them.

Snapshot Fundamentals

ZFS Snapshots at a Glance

STATE
Point in Time Preserves the dataset state from the moment the snapshot is created.
ACCESS
Read-Only The snapshot itself cannot be directly modified like the active filesystem.
CREATION
Nearly Instant ZFS does not need to duplicate the entire dataset when creating the snapshot.
STORAGE
Grows With Changes Space is retained as blocks diverge from the active dataset.
RECOVERY
Files or Rollback Snapshots can support individual file recovery or complete dataset rollback.
Copy-on-Write

How Do ZFS Snapshots Work?

ZFS uses copy-on-write behavior. Existing blocks are not overwritten in place when data changes. New data is written elsewhere, allowing an existing snapshot to continue referencing the older blocks.

STEP 1
Active Dataset The filesystem references its current set of data blocks.
STEP 2
Snapshot Created The snapshot preserves references to the blocks that define the dataset at that moment.
STEP 3
Data Changes New or modified data is written to new blocks rather than overwriting snapshot-referenced blocks.
STEP 4
Old State Remains Older blocks remain allocated while snapshots still require them.
Simplified Example

What Happens After a Snapshot?

Consider a dataset containing three files when a snapshot is created. One file is then modified and another is deleted from the live filesystem.

SNAPSHOT — 10:00 AM

Preserved State

report.xlsx — Version A
database.db — Version A
archive.zip — Present
LIVE DATASET — 2:00 PM

Current State

report.xlsx — Version A
database.db — Version B
archive.zip — Deleted
Even though database.db changed and archive.zip was deleted from the active dataset, the snapshot can continue referencing the blocks required to represent their earlier state.
Basic Administration

How to Create a ZFS Snapshot

A snapshot is identified by the dataset name followed by an @ symbol and the snapshot name.

zfs snapshot tank/data@before-upgrade

This creates a snapshot named before-upgrade for the dataset tank/data.

Recursive Snapshots

The -r option creates snapshots for the named dataset and all descendant datasets. OpenZFS creates recursive snapshots at the same point in time.

zfs snapshot -r tank/data@daily-2026-08-14
Snapshot Management

How to List ZFS Snapshots

LIST SNAPSHOTS
zfs list -t snapshot
LIST SNAPSHOTS FOR A DATASET TREE
zfs list -t snapshot -r tank/data
File Recovery

Accessing Files Inside a ZFS Snapshot

Filesystem snapshots can normally be accessed through the dataset's .zfs/snapshot directory. This makes it possible to retrieve an older version of an individual file without rolling back the entire dataset.

cp /tank/data/.zfs/snapshot/before-upgrade/report.xlsx /tank/data/report.xlsx
The snapdir property controls snapshot-directory visibility. Its default hidden setting means the directory can exist without appearing in an ordinary directory listing.
Capacity Planning

How Much Space Do ZFS Snapshots Use?

A newly created snapshot initially shares the same blocks as the active dataset and therefore requires essentially no additional data storage. Snapshot space usage increases as the live dataset changes.

SNAPSHOT CREATED
Minimal Initial Space Existing blocks are shared between the active dataset and snapshot.
DATA MODIFIED
Old Blocks Remain Blocks still referenced by the snapshot cannot yet be reclaimed.
DATA DELETED
Space May Stay Allocated Deleting a file from the live filesystem does not free blocks still required by a snapshot.
Important Capacity Consideration

Snapshots Can Prevent Deleted Data From Freeing Space

Deleting a large file from the active filesystem does not necessarily return that capacity to the pool. If an existing snapshot still references the file's blocks, those blocks must remain allocated.

Long snapshot retention periods combined with rapidly changing datasets can therefore consume substantial storage capacity. Snapshot retention should be planned alongside available pool capacity.

Monitoring

Checking Snapshot Space Usage

zfs list -t snapshot -o name,used,referenced,written -r tank/data
USED Space uniquely referenced by the snapshot.
REFERENCED Amount of data accessible through that snapshot.
WRITTEN Helps identify data written since the previous snapshot.
Recovery Options

Restore a File or Roll Back the Dataset?

TARGETED RECOVERY

Copy Individual Files

When only one or several files need to be recovered, copying them from the snapshot is usually much less disruptive than reverting the entire dataset.

COMPLETE REVERSION

Roll Back the Dataset

A rollback returns the dataset to the selected snapshot state and discards changes made after that point. This is a much more consequential recovery operation.

Dataset Recovery

Rolling Back to a ZFS Snapshot

The zfs rollback command returns a dataset to the state represented by a snapshot. Data written or modified after that snapshot is discarded.

zfs rollback tank/data@before-upgrade
Use rollback carefully. Changes made after the target snapshot are discarded. OpenZFS also requires additional options when rolling back past newer snapshots, and those options can destroy newer snapshots, bookmarks or dependent clones.
Operational Planning

Snapshot Naming and Retention

Consistent snapshot names make recovery and automation easier. Names can identify the snapshot's purpose, date, frequency or the event that triggered its creation.

@hourly-2026-08-14-1400 Scheduled hourly snapshot
@daily-2026-08-14 Scheduled daily snapshot
@before-upgrade Administrative checkpoint
@pre-maintenance Maintenance checkpoint
Example Strategy

Example Snapshot Retention Schedule

Snapshot schedules should be matched to workload, available storage and recovery objectives. A policy might retain different snapshot frequencies for different periods.

Frequency Example Retention Potential Purpose
Hourly 24–48 hours Recent accidental changes
Daily 7–30 days Short-term recovery history
Weekly 4–12 weeks Medium-term recovery points
Monthly Policy dependent Longer recovery history

This is an illustrative schedule, not a universal recommendation. Retention requirements vary significantly by workload and recovery objectives.

Snapshot Lifecycle

Deleting a ZFS Snapshot

Snapshots that are no longer required can be destroyed with zfs destroy.

zfs destroy tank/data@before-upgrade

Destroying a snapshot makes blocks that are no longer referenced by the live dataset or another snapshot eligible to be reclaimed. A snapshot cannot normally be destroyed while it is protected by a hold or required by a dependent clone.

Replication

ZFS Snapshots and Send/Receive

Snapshots are also fundamental to ZFS replication. ZFS send streams can represent a snapshot, while incremental streams can transfer changes between snapshot points.

Snapshot Establishes a defined point-in-time dataset state.
ZFS Send Generates a data stream representing the selected snapshot or incremental changes.
ZFS Receive Receives the stream on another ZFS pool or dataset.
Critical Distinction

Is a ZFS Snapshot a Backup?

A local ZFS snapshot should not be treated as an independent backup. A snapshot stored in the same pool depends on that pool remaining available. Pool loss, hardware destruction or other failures affecting the entire storage system can make both the active dataset and its local snapshots unavailable.

Snapshots are extremely useful recovery points, but important data should also be protected through an independent backup or replication strategy appropriate to the organization's recovery requirements.

Common Applications

What Are ZFS Snapshots Used For?

Accidental File Deletion Retrieve files that were deleted after a snapshot was created.
Previous File Versions Recover an earlier version of a file that was later changed.
Pre-Upgrade Checkpoints Capture dataset state before significant maintenance or software changes.
Dataset Rollback Return a dataset to an earlier state when a complete reversion is appropriate.
ZFS Clones Snapshots provide the origin from which writable ZFS clones can be created.
Replication Snapshot points provide the basis for ZFS send and incremental replication workflows.
Operational Guidance

ZFS Snapshot Best Practices

Use Consistent Names Include dates, frequency or purpose so recovery points are easy to identify.
Define Retention Avoid retaining snapshots indefinitely without a capacity and recovery requirement.
Monitor Pool Capacity Snapshot retention can prevent changed or deleted blocks from being reclaimed.
Snapshot Before Changes Administrative snapshots can provide useful recovery points before significant changes.
Keep Independent Backups Local snapshots should complement, not replace, independent data protection.
Frequently Asked Questions

ZFS Snapshots FAQ

What is a ZFS snapshot?

A ZFS snapshot is a read-only point-in-time representation of a ZFS filesystem or volume.

Are ZFS snapshots instant?

Snapshot creation is nearly instantaneous because ZFS does not copy the entire dataset when creating the snapshot.

Do ZFS snapshots use disk space?

A new snapshot initially requires essentially no additional data space, but its storage impact grows as the live dataset changes and old blocks remain referenced.

Can a ZFS snapshot recover a deleted file?

Yes, if a retained snapshot contains the earlier file, it can generally be copied back into the active filesystem.

Can you modify a ZFS snapshot?

No. Snapshots are read-only. A writable clone can be created from a snapshot when a writable derivative is required.

What does ZFS rollback do?

Rollback returns a dataset to a snapshot state and discards data changes made after that recovery point.

Why does deleting files not free ZFS space?

One possible reason is that snapshots still reference the deleted files' blocks, preventing those blocks from being reclaimed.

Are ZFS snapshots backups?

Local snapshots are useful recovery points but should not be considered independent backups because they remain dependent on the underlying storage pool.

Can ZFS snapshots be replicated?

Yes. ZFS send and receive use snapshot states for full and incremental replication workflows.

Enterprise ZFS Storage

Building or Expanding a ZFS Storage Server?

Tech Supply Direct can help identify compatible enterprise HDDs, SSDs, SAS and SATA storage, memory and related server hardware for ZFS storage deployments, upgrades and capacity expansions.