ZFS Cheat Sheet Linux: Essential Commands & Quick Reference

Managing storage on Linux requires robust tools, and OpenZFS stands out as one of the most powerful enterprise-grade file systems and logical volume managers available. Whether you are building a home network-attached storage server or administering complex data centers, having a reliable reference guide is essential for day-to-day operations. This comprehensive ZFS cheat sheet for Linux is designed to give system administrators quick access to the most vital commands for managing storage pools, configuring high-performance datasets, handling snapshot lifecycles, and executing seamless data replication. From basic pool creation and health monitoring to advanced tuning and disaster recovery, these commands provide the building blocks for maintaining resilient and high-throughput Linux storage environments.

Introduction to ZFS on Linux

ZFS is an advanced enterprise-grade file system and logical volume manager originally developed by Sun Microsystems, now fully integrated into modern Linux distributions through OpenZFS.

Understanding ZFS on Linux begins with mastering its dual-command architecture. To administer the storage infrastructure effectively, administrators must become fluent in essential zfs commands that govern the logical data layer while handling underlying hardware health.

The architecture is strictly separated into two distinct administrative domains: physical pool management and logical dataset management. This clear division of labor prevents administrative overlap and provides granular control over both underlying hardware resilience and top-level filesystem features.

zpool commands handle hardware (disks, pools) while zfs commands handle software (datasets, properties, snapshots).

By keeping this physical-versus-logical distinction clear, administrators can safely scale storage capacity, manage high-performance caching layers, and provision datasets without risking structural pool integrity.

Zpool Management: Administering Storage Pools

At the core of the ZFS file system architecture lies the storage pool, or zpool, which abstracts physical storage devices into a unified, resilient pool of resources.

The zpool command suite forms the foundational layer for provisioning raw storage, managing virtual device topologies, and maintaining the overall health of your disk subsystems on Linux. Before any datasets can be created or files stored, administrators must design and initialize appropriate storage pools using structured vdev configurations such as mirrors, raidz, or stripped setups.

Beyond initial provisioning, effective administration requires continuous insight into pool performance, hardware integrity, and lifecycle portability. Whether you are scaling capacity, replacing failing enterprise drives, performing routine data scrubs, or safely migrating complete arrays across different Linux nodes, mastering zpool operations ensures long-term stability and optimal data availability. The following sections explore the essential commands for creating, monitoring, maintaining, and migrating your ZFS storage pools.

Creating and Upgrading Pools

Properly structuring your storage pools is the foundational step for achieving optimal performance, data integrity, and fault tolerance on Linux.

The zpool create command is the primary utility for building a new ZFS storage pool from underlying block devices. When initiating a new pool, it is critical to configure proper sector alignment to avoid severe performance degradation, especially when deploying modern Solid State Drives (SSDs) or Advanced Format 4K mechanical hard drives. By passing the -o ashift=12 property flag during pool creation, you instruct ZFS to align all blocks on 4096-byte boundaries, matching the native sector size of modern storage hardware.

Beyond basic pool creation, ZFS relies on virtual devices, commonly known as vdevs, to aggregate raw disks into flexible storage topologies. Each topology offers unique trade-offs between storage efficiency, read and write performance, and redundancy against disk failures.

Mirror: Duplicates data across two or more disks, providing exceptional read performance and fast resilvering times at the cost of 50 percent or more raw storage capacity.
RaidZ1: A single-parity configuration similar to RAID 5 that tolerates the failure of one disk while conserving more usable space than a mirror.
RaidZ2: A double-parity configuration similar to RAID 6 that protects data against the simultaneous failure of any two member disks, ideal for larger arrays.
Log (ZIL): Dedicated high-speed storage devices used to accelerate synchronous write operations and reduce latency for databases and virtualization workloads.
Cache (L2ARC): Fast read-cache devices typically backed by NVMe or SSD hardware to accelerate random read operations for datasets that exceed system RAM capacity.
Spare: Dedicated hot-spare disks that remain in standby mode and automatically replace a failed primary storage device within the pool.

As you update your operating system and ZFS kernel modules, older storage pools may require feature updates to support newly introduced filesystem capabilities. You can safely inspect and elevate your pool versions by executing the zpool upgrade command, which ensures your underlying data structures can leverage the latest performance improvements and administrative features.

Mastering the creation flags and vdev layouts ensures your ZFS environment remains scalable, resilient, and fine-tuned for your specific hardware architecture.

Monitoring Pool Health and I/O

Keeping a close eye on your storage pools is critical for early detection of hardware degradation, performance bottlenecks, and configuration errors.

The foundation of active storage administration lies in inspecting storage pool metrics regularly. To obtain a high-level overview of all pools on your system, the zpool list command serves as the primary tool. By default, it displays the pool name, total size, allocated space, free space, fragmentation percentage, expansion capacity, deduplication ratio, health status, and alternate mount point. You can customize this output extensively using command-line flags. For instance, appending the -v flag provides a verbose breakdown showing individual virtual devices (vdevs) and their status underneath each pool. If you want to script around these outputs or extract specific fields without header information, the -Ho option allows you to omit headers and use tab-delimited values, while the -o flag lets you selectively display custom properties such as capacity, health, or size.

When troubleshooting errors, degraded performance, or silent data corruption, zpool status is the definitive diagnostic utility. Running it without arguments shows the health state of all pools, detailing whether they are online, degraded, faulted, or suspended. To quickly check if any pools require administrative intervention, the -x flag suppresses output for healthy pools and displays only those experiencing issues. For deeper investigation into corrupted blocks or specific failing drives, the -v flag lists individual files with permanent read or write errors. Furthermore, in large enterprise environments with complex multi-path storage arrays, the -LP flags resolve physical paths and display persistent device links rather than raw device nodes, making it vastly easier to identify which physical slot requires a replacement disk.

Command	Flag	Output Description
zpool list	-v	Displays detailed verbose output including individual vdev topologies and status.
zpool list	-o property	Filters output to display only specified properties like size, health, or fragmentation.
zpool status	-x	Displays status only for pools that are degraded, faulted, or otherwise require attention.
zpool status	-v	Lists specific files and data blocks encountering permanent errors.
zpool status	-LP	Resolves physical paths and shows long persistent device paths.
zpool iostat	-v 2	Displays real-time I/O statistics, bandwidth, and latency metrics per vdev every 2 seconds.
zpool history	-il	Outputs a chronological log of all executed zpool commands along with user contexts and internal log IDs.

Beyond static health checks, performance analysis requires tracking real-time operations using zpool iostat for bandwidth usage, operations per second, and latency. This command reports bandwidth usage, operations per second, latency, and queue depths for every storage pool and underlying vdev. Passing the -v flag breaks down these statistics down to individual disk levels, while specifying an interval value (such as zpool iostat -v 5) continuously updates the metrics every five seconds to help pinpoint disk bottlenecks or slow drives during heavy read/write workloads.

Finally, maintaining an audit trail of administrative actions is essential for troubleshooting configuration drift or unexpected changes. The zpool history command records every administrative command executed against your storage pools. By supplying the -i flag, you include internal event logs, and the -l flag appends user identification, host information, and exact execution timestamps to each logged entry, ensuring complete accountability across your Linux storage infrastructure.

Mastering these inspection and monitoring tools ensures you can rapidly isolate hardware failures, analyze real-time throughput, and maintain complete historical visibility over your ZFS storage architecture.

Maintenance, Scrubs, and Disk Replacement

Keeping a ZFS storage pool healthy requires proactive maintenance, regular integrity checks, and proper handling of disk hardware changes.

Data integrity verification in ZFS is primarily handled through the scrubbing mechanism, which reads all blocks in the pool, checks them against checksums, and automatically attempts to repair any detected silent data corruption using redundant copies or parity data from other vdevs. To initiate a scrub manually in the background, you use the zpool scrub command followed by the pool name. You can monitor the progress and status of an ongoing or completed scrub by running zpool status, and if a scrub needs to be halted prematurely—such as to prevent I/O saturation during peak production hours—you can cancel it using the zpool scrub -s command. For long-term reliability, administrators should automate this process using native systemd timers, typically enabled via systemctl enable --now [email protected] or monthly equivalents provided by your Linux distribution's ZFS package.

When hardware errors occur, ZFS logs them in the pool's state, which can be viewed via zpool status -x. Once a transient error is investigated or a flaky cable is reseated, the error counters and fault states must be explicitly acknowledged and cleared by running zpool clear poolname [device]. If you need to take a physical device out of service for testing, maintenance, or replacement, you should manage its availability states carefully. You can take a device offline temporarily using the -t flag (zpool offline -t poolname device), which ensures the device will automatically return to an online state the next time the system reboots. Conversely, a permanent offline command (zpool offline poolname device) keeps the device out of the pool configuration until it is explicitly brought back online using zpool online poolname device.

Remind administrators to never physically remove a disk from a production pool without first offlining it using zpool offline, unless it is entirely dead.

Storage pools often require hardware expansion or hot-swapping of failing drives. For mirrored vdev topologies, you can dynamically add a new mirror component using zpool attach poolname existing_device new_device, or separate a mirror limb using zpool detach poolname device. When a drive fails completely, you swap it out at the OS level and execute zpool replace poolname old_device new_device to copy all data over to the replacement drive and resilver the vdev. To simplify disk replacements further, you can enable the autoreplace pool property (zfs set autoreplace=on poolname), which automatically integrates any new disk plugged into the same physical slot or path as a failed, replaced device. Additionally, if you upgrade physical hard drives or LUNs to larger capacities, enabling the autoexpand property (zfs set autoexpand=on poolname) allows the pool to automatically grow and utilize the newly available space as soon as the underlying partition table or device size changes.

Mastering these maintenance, scrub, and disk replacement workflows ensures high availability and resilience for your Linux storage infrastructure.

Exporting and Importing Pools

Safely moving your ZFS storage pools between different physical servers or temporarily disconnecting them requires a solid grasp of export and import commands.

When you need to unmount and detach a storage pool so it can be safely imported on another Linux host, the zpool export command is used. This process ensures all dirty data in memory is flushed to disk, the pool state is marked cleanly, and the operating system releases all file locks on the devices. If applications or shell sessions are actively using files within the pool, the export might fail unless you force it. Forcing an export is accomplished by appending the -f flag, which immediately terminates active processes and forcefully unmounts all datasets contained within the pool. Always exercise caution when using the force flag in production environments, as abrupt interruptions can cause data loss for uncommitted writes.

To bring an exported pool back online on the same system or a completely new Linux host, use the zpool import command. Running zpool import without any arguments will scan available block devices and list any healthy, export-clean pools that are ready to be attached. If your storage pool relies on devices located in a non-standard directory, you can instruct ZFS to scan that specific location using the -d flag followed by the absolute path. For administrators dealing with emergency situations where a pool was accidentally deleted, the -D flag comes into play, allowing ZFS to search for and recover previously destroyed pools.

In scenarios where you want to discover and automatically attach every available pool attached to the system, the -a flag is your go-to option. Furthermore, ZFS gives you the flexibility to rename a pool while you are importing it. This is particularly useful when resolving naming collisions or reorganizing server topologies. The syntax for renaming during an import requires specifying both the old name (or discovered GUID) and the new desired name, structured as zpool import old_pool_name new_pool_name. This robust migration toolkit makes ZFS storage incredibly portable across enterprise data centers and home labs alike.

Mastering the export and import workflows ensures your ZFS pools remain highly portable, fault-tolerant, and ready for hardware migrations.

Let us examine the specific administrative commands and configuration patterns required to deploy and maintain robust ZFS storage pools.

ZFS Dataset and Volume Management

Mastering the zfs command suite is essential for translating raw storage pools into flexible, high-performance file systems and raw block devices tailored to your specific application needs.

While storage pools establish the foundational architecture, the zfs command utility governs everything sitting on top of those pools. This includes hierarchical datasets, file system structures, sparse block volumes, and granular operational properties. Because ZFS combines the traditional volume manager and file system into a single integrated layer, administrative workflows look significantly different compared to standard Linux partitioning tools like LVM and ext4. Instead of dealing with block device mapping and mkfs formatting separately, you can dynamically spin up file systems, assign custom quotas, enforce compression algorithms, and share directories over network protocols using streamlined commands.

Understanding how to carve up your storage effectively requires a firm grasp of hierarchical dataset naming conventions, property inheritance, and space management. Whether you are provisioning thin-provisioned zvols for virtual machines, restricting user storage consumption with quotas, or configuring enterprise-grade mount points, the following sections detail the core subcommands and parameters required to master ZFS dataset and volume administration on Linux.

Creating and Listing Datasets and Zvols

Managing file systems and block devices under a single unified architecture is one of the most powerful features of OpenZFS.

To build new hierarchical file systems within your storage pool, the primary command is zfs create. Unlike traditional partition-based systems, ZFS datasets act as dynamic file systems that automatically draw space from the pool's shared storage capacity. When organizing a complex directory tree, you can use the parent flag (-p) to create intermediate filesystems simultaneously if they do not already exist, preventing missing-directory errors during automated deployments.

In addition to standard file systems, ZFS allows administrators to provision raw block devices known as zvols. By utilizing the volume flag (-V) followed by a specified size, you can instantly provision block devices that can be formatted with arbitrary file systems or exposed directly to virtualization layers. For environments where physical storage is constrained, combining the volume flag with the sparse flag (-s) enables thin-provisioned sparse volumes, preventing the storage pool from allocating full space upfront.

To verify your allocations, inspect current capacities, and monitor dataset hierarchies, you will frequently rely on the zfs list datasets functionality. Executing the base zfs list command displays all active datasets, mount points, used space, and available capacity across your system. You can further refine this output by filtering for specific dataset types using the type flag or by formatting custom column views to suit your administrative reporting needs.

Mastering dataset and zvol creation ensures you can flexibly partition your storage pool for applications, containers, and virtual machines.

Destroying Datasets

When managing storage on a Linux system, knowing how to properly remove unwanted or obsolete storage allocations is just as crucial as creating them, though it requires extreme caution.

The standard command for deleting a ZFS dataset or raw block volume is `zfs destroy`. Unlike traditional Linux filesystems where files are unlinked and sent to a trash directory, a ZFS destruction command is immediate and permanent. By default, attempting to run `zfs destroy` on a dataset that contains child datasets, clones, or dependent snapshots will result in an error, protecting you from accidental mass data loss.

To safely verify what will be affected before executing a permanent wipe, you should always leverage dry-run mode using the `-n` flag combined with the verbose `-v` flag. Running `zfs dry-run` behavior via `zfs destroy -nv pool/dataset` prints out an exact itemized list of all child datasets, volumes, and individual snapshots that would be purged by the operation, allowing you to audit your targets carefully.

When you are certain you want to proceed and need to override dependencies, ZFS provides several powerful modifier flags. The `-r` flag recursively destroys all child datasets and associated snapshots beneath the specified target. The `-R` flag goes a step further by removing all dependent clones and related objects outside the immediate hierarchy that rely on the target. Finally, combining `-f` and `-r` forces an immediate unmount of active mountpoints before executing the recursive purge.

Executing zfs destroy -r is completely irreversible and will violently unmount and wipe datasets, child datasets, and snapshots immediately without secondary confirmation.

Always double-check your target paths and utilize dry runs to ensure you never purge critical storage layers by mistake.

Managing ZFS Properties and Quotas

Fine-tuning your storage environment relies heavily on understanding how to query, modify, and control dataset properties and space allocations within your ZFS pool.

The core toolkit for managing dataset configuration revolves around three main commands: zfs get, zfs set, and zfs inherit. To inspect current configurations, the zfs get command is used alongside specific property names or the 'all' keyword. For instance, running zfs get all tank/data provides an exhaustive list of every parameter affecting that specific dataset, including inherited values, active configurations, and performance statistics. Property values can be modified dynamically on the fly using the zfs set command, such as enabling compression or adjusting performance limits without requiring any unmounting or service restarts. If a dataset property has been manually overridden but you wish to revert it to the default inherited behavior from its parent dataset, the zfs inherit command clears the local override.

Key configurable properties dictate the exact behavior of compression, data integrity, and caching. Compression is one of the most beneficial features; modern standards like lz4 provide incredible compression ratios with virtually negligible CPU overhead, while zstd offers higher compression levels at the cost of additional compute cycles. Other legacy or alternative compression algorithms include gzip, zle, and lzjb. Deduplication eliminates duplicate blocks of data to save storage space, but it demands massive RAM allocations for its lookup tables; you can monitor the actual deduplication savings ratio by inspecting the system using the zdb -DD utility. Furthermore, recordsize dictates the block size for standard filesystems (often tuned for databases or virtual machine images), while volblocksize manages the equivalent block size for raw block volumes, known as zvols.

Property	Standard Value	Function
compression	lz4 (or zstd)	Enables transparent real-time data compression to save disk space.
dedup	off	Eliminates duplicate data blocks globally at the expense of high RAM usage.
recordsize	128K	Defines the optimal block size for standard datasets and file workloads.
primarycache	all	Determines whether the ARC caches data, metadata, or both.
secondarycache	all	Controls whether the L2ARC caches incoming blocks from disk.

Space management and quota controls allow administrators to enforce strict boundaries on storage consumption. A standard quota limits the total space a dataset and all of its child elements can consume, whereas refquota strictly limits the space consumed by the dataset itself, excluding its snapshots and clones. To guarantee minimum space availability, reservation ensures a dataset has a guaranteed allocation of pool capacity, while refreservation ensures that exact amount is reserved exclusively for the dataset's live data blocks, independent of snapshots. In multi-tenant or shared environments, user quotas—configured via properties like userquota@username—prevent individual users from exhausting the entire storage pool, and their utilization can be audited using the zfs userspace command.

Performance optimization is heavily influenced by caching layers and administrative delegation. ZFS utilizes primarycache (controlling what is kept in the main system RAM Adaptive Replacement Cache) and secondarycache (managing what is stored on faster secondary devices like NVMe L2ARC drives). By default, both are set to 'all', caching both data and metadata, but they can be tuned to 'metadata' if workloads require extreme metadata acceleration. Finally, rather than granting root privileges to non-privileged operators, ZFS supports secure administrative permission delegation using the zfs allow and zfs unallow commands. This allows specific users or groups to perform targeted tasks—such as creating snapshots, mounting datasets, or managing clones—without full superuser access.

Mastering these properties and storage quotas ensures your ZFS filesystems remain performant, securely compartmentalized, and optimized for specific workloads.

ZFS simplifies storage administration by automating file system mounting and network sharing directly through dataset properties.

Unlike traditional Linux file systems that rely heavily on manual entries in the /etc/fstab file, ZFS manages mount points dynamically. By default, when a dataset or file system is created, ZFS automatically mounts it at a path corresponding to its name under the pool root. Administrators can explicitly control mounting behavior using the zfs mount and zfs umount commands. To mount all unmounted file systems across your storage pools simultaneously, use the zfs mount -a command, while zfs umount can be used to unmount a specific dataset when performing maintenance or changing properties.

The canmount property offers fine-grained control over whether a dataset should be mounted automatically. Setting canmount=on (the default) allows the dataset to be mounted normally via zfs mount -a or at creation time. Changing this property to canmount=off prevents the dataset from ever being mounted, which is particularly useful for parent datasets that serve purely as organizational containers or properties hierarchies without holding direct file data. Additionally, setting canmount=noauto ensures that the dataset will not mount automatically during system boot or via the global -a flag, requiring administrators to mount it manually when needed.

Customizing where datasets appear in the directory tree is achieved through the mountpoint property. Administrators can assign custom paths using the syntax zfs set mountpoint=/custom/path pool/dataset. If you prefer to manage mounting through traditional Linux utilities and configuration files like /etc/fstab, you can set the mountpoint to legacy. When configured as legacy, ZFS will not manage the mount point automatically, allowing you to use standard mount and umount system commands and maintain traditional fstab entries.

Sharing datasets over the network is equally streamlined through the built-in sharenfs property, eliminating the need to manually configure and edit /etc/exports in many environments. By enabling this property with zfs set sharenfs=on pool/dataset, ZFS automatically publishes the file system using the system's NFS server daemon. You can also pass specific NFS export options directly to the property, such as zfs set [email protected]/24,subtree_check pool/dataset, ensuring that security and access constraints are applied instantly without requiring an explicit exportfs -ra reload command.

Mastering ZFS mount points, the canmount property, legacy options, and sharenfs integration allows for seamless, automated storage and network distribution across Linux systems.

The following subtopics provide a structured breakdown of creating, tuning, maintaining, and sharing your ZFS datasets and block volumes.

Snapshots, Clones, and Replication

ZFS transforms traditional backup and replication paradigms by integrating point-in-time snapshots, lightweight branching clones, and stream-based data transmission directly into the file system architecture.

Effective data protection begins with the ability to capture the exact state of a dataset instantaneously without incurring performance overhead or duplicating active storage capacity. ZFS leverages a copy-on-write mechanism that makes snapshots virtually instantaneous and incredibly space-efficient, recording only block modifications made after the snapshot was initialized. Beyond local time-machine style recovery, administrators can transform these read-only reference points into fully writable experimental environments using ZFS clones, or serialize entire dataset hierarchies into compressed byte streams for remote disaster recovery and off-site replication.

Snapshot Management

Mastering snapshot management is essential for effective data protection and point-in-time recovery on ZFS file systems.

Creating a point-in-time snapshot in ZFS is instant and consumes no additional storage space initially, as it merely captures the file system state as it exists at the exact moment of execution. To create a snapshot, use the zfs snapshot command followed by the target dataset and an @ symbol combined with a user-defined snapshot name. For example, running zfs snapshot tank/data@backup-20231025 captures the current state of the tank/data dataset under that specific label. To inspect all available snapshots across your system, query the dataset hierarchy by utilizing the zfs list commands filtered by the snapshot type flag: zfs list -t snapshot. This command displays every snapshot along with its used space, creation date, and reference metrics.

Renaming and deleting snapshots provide essential flexibility for lifecycle management and storage reclamation. If a snapshot needs a more descriptive or standardized label, you can use the zfs rename command specifying both the old snapshot path and the new name, such as zfs rename tank/data@backup-20231025 tank/data@monthly-20231025. When a snapshot is no longer needed, it can be safely destroyed using the zfs delete dataset approach via the zfs destroy command. If dependent clones or newer snapshots block the deletion, ZFS will prevent the action unless you explicitly handle dependencies or use recursive flags, making the snapshot deletion process both safe and deterministic.

When data corruption or unwanted modifications occur, you can revert a dataset back to a previous point-in-time state using the zfs rollback command. Executing zfs rollback tank/data@backup-20231025 discards all changes made to the dataset after that snapshot was taken. By default, ZFS will block a rollback if newer snapshots exist unless you include the -r flag, which automatically destroys any intermediate snapshots created after the target point. Additionally, if the dataset is currently mounted and active, appending the -f flag forces an unmount of the file system to ensure the rollback operation completes without interruption.

Effectively leveraging snapshots, renames, and rollbacks ensures rapid data recovery and robust versioning control within your ZFS environment.

Branching with Clones and Promotes

Understanding how to branch data efficiently using snapshots is a core strength of the ZFS filesystem architecture.

In ZFS terminology, a snapshot is inherently read-only and serves as an immutable point-in-time reference of a dataset. However, administrators frequently need to experiment with data, test software upgrades, or spin up temporary environments from a known good state without altering the original production dataset. This is where the `zfs clone` command becomes essential. Unlike a full data copy, which consumes duplicate storage and time, a clone creates a new, writable filesystem directly from an existing snapshot using a copy-on-write mechanism. Initially, the clone shares all underlying data blocks with the parent snapshot, meaning it consumes virtually zero additional disk space at the moment of creation. As data within the clone is modified or written to, new blocks are allocated independently, ensuring complete isolation from the original source.

Despite the flexibility of cloning, it introduces a strict dependency relationship. A cloned dataset depends on the specific snapshot it was created from. Consequently, standard administrative procedures prevent the deletion of that parent snapshot as long as any active clone relies on it. This restriction can quickly lead to snapshot bloat and prevent you from reclaiming disk space, even if the primary dataset has long since discarded those old states. To resolve this structural dependency and break the tether holding back snapshot removal, ZFS provides the `zfs promote` command.

When you execute `zfs promote` on a clone, the dependency hierarchy is inverted. The clone effectively swaps places with its parent snapshot, promoting itself to an independent, top-level dataset while turning the original parent dataset into a dependent clone of your new dataset. By transferring the burden of dependency, the snapshot that previously blocked cleanup can now be safely destroyed without risking data loss on your active branched environment. This mechanism allows administrators to test unstable patches or configuration changes, graduate those changes into production by promoting the test environment, and gracefully discard historical clutter without disrupting ongoing operations.

# Create a snapshot of the production dataset zfs snapshot tank/prod/db@base # Clone the snapshot into a new writable testing environment zfs clone tank/prod/db@base tank/test/db-trial # After verifying the test environment, promote it to break the dependency on the snapshot zfs promote tank/test/db-trial # Now the original snapshot can be safely destroyed to free up space zfs destroy tank/prod/db@base

Mastering clones and promotions enables streamlined workflows for software development, testing pipelines, and safe system maintenance.

Sending and Receiving (ZFS Replication)

ZFS replication leverages powerful stream generation tools to back up and transfer data efficiently across local storage, remote systems, and cloud targets without losing snapshot history.

The core mechanism of ZFS replication relies on the pairing of the `zfs send` and `zfs receive` commands. `zfs send` reads a dataset snapshot and converts its raw block stream into a byte-stream format that can be redirected, stored in a file, or piped directly over a network connection. Conversely, `zfs receive` ingests that byte-stream and reconstructs the exact state of the dataset and its underlying snapshots on a destination pool. Because this operation works at the filesystem block level rather than file by file, it preserves metadata, properties, and the full hierarchical snapshot tree intact.

To perform a full initial replication of a dataset, you must first create a snapshot of the source. For example, running `zfs snapshot tank/data@snap1` captures the current state, and `zfs send tank/data@snap1 > /mnt/backup/data_snap1.zfs` writes the stream to a file or a mounted backup disk. On the destination machine, you restore this stream using `zfs receive backup-pool/data < data_snap1.zfs`. This establishes the baseline dataset from which all future updates will grow, ensuring that the destination holds an identical structural replica of the source at the moment the snapshot was taken.

For ongoing backups, transmitting an entire dataset repeatedly would waste enormous amounts of time and network bandwidth. ZFS solves this inefficiency through incremental streams using the `-i` or `-I` flags. By specifying an older baseline snapshot alongside a newer target snapshot, `zfs send -i tank/data@snap1 tank/data@snap2` generates a stream containing only the data blocks that have changed between those two points in time. When the receiving end processes this incremental stream via `zfs receive backup-pool/data`, it quickly applies the delta updates, bringing the destination dataset up to date with minimal resource consumption.

These replication streams are rarely restricted to local storage; they are commonly piped over secure shell connections for reliable off-site disaster recovery. A standard remote replication command combines `zfs send` with SSH and `zfs receive` in a single pipeline: `zfs send -i tank/data@snap1 tank/data@snap2 | ssh user@remote-host zfs receive backup-pool/data`. Administrators can also automate and script these backup routines safely by configuring SSH key pairs and leveraging intermediary backup servers, ensuring that point-in-time recovery points are continuously and securely mirrored away from primary production hardware.

Mastering `zfs send` and `zfs receive` enables robust, bandwidth-efficient backup strategies that keep secondary sites completely synchronized with primary storage nodes.

Understanding how to orchestrate snapshots, promote clones, and pipe data streams securely across nodes is essential for maintaining robust, highly available storage infrastructures on Linux.

Keeping a reliable command reference handy is essential for mastering storage administration and maintaining data integrity in production environments. By regularly executing health checks with status utilities, scheduling routine data scrubs, and automating snapshot lifecycles, you can safeguard your critical infrastructure against unexpected hardware failures. Always exercise caution and double-check your flag combinations—particularly when dealing with recursive destructions, forced imports, or volume rollbacks—to prevent accidental data loss. Armed with this ZFS on Linux cheat sheet, you can confidently configure, monitor, and scale your storage pools for maximum performance and resilience.