ZFS administration on Solaris 11.4: pools, datasets, snapshots and scrubs

What it is

ZFS is the default file system on Oracle Solaris 11.4 and the only supported root file system (UFS remains supported for data, but boot environments require ZFS). Two commands cover almost all administration: zpool manages storage pools (the physical devices and redundancy), and zfs manages the datasets — file systems, volumes, snapshots — that live inside a pool.

Why it matters

Unlike a Linux LVM-plus-filesystem stack, ZFS pools and datasets are managed as one system with built-in checksums, snapshots and, with send/receive, native replication. Because boot environments (see the beadm article in this series) are themselves ZFS datasets, understanding zfs/zpool is a prerequisite for safe patching, not just storage administration.

How to apply

• Check pool health first: zpool status shows each pool's devices, their state (ONLINE, DEGRADED, FAULTED) and any repair action needed, zpool status -x reports only pools with problems; zpool list gives a one-line summary of size, allocation and health per pool.
• List and inspect datasets: zfs list shows mounted file systems, volumes and their space usage; zfs list -t snapshot restricts the view to snapshots.
• Create a dataset with a property set at creation time: zfs create -o compression=on tank/data; change a property later on an existing dataset with zfs set compression=on tank/data.
• Take a point-in-time copy: zfs snapshot tank/data@before-change. Snapshots are read-only and consume space only for blocks that later change.
• Undo a change by returning to a snapshot: zfs rollback tank/data@before-change. All data written since that snapshot is discarded; by default the command only rolls back to the most recent snapshot and refuses if newer ones exist.
• Replicate or back up a dataset: zfs send tank/data@snap | zfs receive backuppool/data sends a snapshot's data stream as a full send; the send subcommand also supports incremental streams between two snapshots.
• Check data integrity proactively: zpool scrub <pool> reads and verifies every block against its checksum, repairing what redundancy allows; zpool status reports scrub progress and when the last scrub completed.
• Watch pool-level I/O: zpool iostat -v <pool> <interval> (see also the performance article in this series) shows read/write operations and bandwidth per device, repeated at the given interval.

Pitfalls

• Forcing a rollback past newer snapshots: -r destroys every more recent snapshot, and -R additionally destroys clones of them, so confirm what exists with zfs list -t snapshot first. For the root pool's boot-environment datasets, use beadm rather than zfs rollback/destroy directly.
• Treating zpool scrub as a backup: it verifies and repairs redundancy, it does not protect against deleting a dataset or against a pool with no redundancy configured at all.
• Forgetting that destroying a snapshot with dependent clones needs an explicit cascade option — always list dependents before destroying anything.