Daily Post July 28 2026

Email Us |TEL: 050-1720-0641 | LinkedIn | Daily Posts

Mintarc Forge	Contact Us	News Letter	Blog	Partners
Collaboration	Questions?	Monthly Letter	Monthly Blog	Our Partners

Incus Storage Pools using ZFS and Btrfs for Snapshots

Traditional file systems like ext4 paired with basic directory backends does give compatibility, but they don't have the capabilities required for large production environments. To really get the full potential of Incus particularly regarding fast deployment, resource efficiency, and instantaneous snapshots you need Copy-on-Write storage backends. For example these backends are ZFS and Btrfs, two storage technologies that can change how virtualized storage is provisioned and maintained.

Storage Pools in Incus

Incus abstracts storage management away from raw block devices and host paths through a unified construct called a storage pool. A storage pool is a designated storage space allocated to Incus, which the system uses to store instance root file systems, custom data volumes, base images, and snapshots. Establishing this abstraction layer, Incus decouples application workloads from the underlying hardware details. When an administrator launches a new container or virtual machine, Incus requests space from the specified storage pool, creating a storage volume tailored to that instance.

The choice of storage driver configured for a pool determines how these volumes behave under the hood. When using a simple directory driver, creating a snapshot or cloning a container requires copying every single file using utility tools like rsync. This approach is slow, scales poorly with container size, and consumes large amounts of storage space. On the other hand, Copy-on-Write storage drivers use file system and volume management capabilities built directly into the Linux kernel. Managing storage through specialized drivers for ZFS or Btrfs, Incus goes from resource-heavy operations to something more like metadata updates.

Copy-on-Write Architecture

In traditional file systems, modifying a file involves overwriting existing data blocks on the disk drive. If a write operation is interrupted halfway through, the file system can suffer corruption or data loss. Copy-on-Write operates on a different mechanism. When data is modified on a Copy-on-Write file system, the system writes the new data to entirely new, unallocated disk blocks rather than overwriting the old blocks. Once the new write is successfully committed, the metadata pointers are updated to point to the new location.

This architectural design provides two massive benefits for container and virtual machine platforms. First, it renders storage immune to data corruption caused by incomplete writes, as old data remains untouched until the new write is finalized. Second, it allows multiple storage entities to share the exact same underlying physical data blocks until one of those entities modifies a block. This block-sharing behavior is what makes instant snapshotting and zero-cost cloning possible inside Incus storage pools.

ZFS in Incus

When integrated as an Incus storage pool driver, ZFS manages physical storage devices inside a structure known as a zpool. Within this pool, Incus automatically creates individual ZFS datasets for each container root file system and ZFS volumes for virtual machine block devices.

ZFS employs end-to-end checksumming across all data blocks, protecting instances against silent data corruption, often known as bit rot. ZFS integrates native transparent compression using fast algorithms like ZSTD or LZ4. In practice, running dozens of Linux containers on a ZFS pool often gives compression ratios of two to one or higher, effectively doubling available disk capacity.

When an administrator takes a snapshot of a container hosted on a ZFS pool, Incus invokes ZFS snapshot creation natively. The snapshot instantly freezes the dataset’s current metadata state. Because no actual file copying occurs, the snapshot completes in milliseconds regardless of whether the container occupies two gigabytes or two terabytes of disk space. ZFS snapshots consume zero additional storage space at the moment of creation. Storage overhead only grows gradually as the container mutates and new blocks are written to the pool. ZFS also is good at at volume replication, enabling native bit-stream transfer between Incus hosts via send and receive mechanisms.

But, these enterprise features come with a resource requirement. ZFS relies heavily on host system memory to run its Adaptive Replacement Cache. For production environments with high memory capacity, ZFS can be the most resilient and scalable storage choice for Incus deployments.

Btrfs in Incus

Btrfs is a native Linux Copy-on-Write file system designed to deliver storage capabilities without requiring complex setup or heavy RAM overhead. When configured as an Incus storage pool, the Btrfs driver organizes container filesystems into subvolumes. Each container, image, and snapshot exists as an isolated Btrfs subvolume within the overarching file system hierarchy.

The main appeal of Btrfs in Incus is its low barrier to entry and lightweight resource footprint. Where as ZFS, which requires dedicated kernel modules and significant memory allocations, Btrfs is built directly into the mainline Linux kernel. This makes Btrfs a good choice for edge computing devices, developer laptops, single-board computers, and small-scale servers where memory capacity must be preserved for workloads rather than storage management.

Inside Incus, Btrfs snapshotting works on the exact same Copy-on-Write philosophy as ZFS. Taking an instance snapshot creates a read-only or read-write Btrfs subvolume snapshot in real time. The new subvolume references the existing extents of the original dataset without duplicating physical storage blocks. This allows developers to take rapid, effortless snapshots before performing risky application updates or operating system upgrades.

Btrfs excels at container management, you should note a specific design consideration regarding virtual machines. Because Btrfs is primarily an extent-based file system rather than a dedicated block manager, Incus stores virtual machine root disks as large loop files on top of Btrfs subvolumes. Random write operations within virtual machines on Btrfs can cause fragmentation over time. But, for container-centric workloads, Btrfs delivers performance, built-in subvolume tree management, and instant snapshot capabilities with minimal operational overhead.

Instant Snapshots and Copy-on-Write Cloning

The combination of Incus with either ZFS or Btrfs changes day-to-day administrative workflows through instant snapshotting and copy-on-write cloning. A snapshot captures the complete state of an instance’s root file system at a precise moment in time. Because both storage engines rely on metadata pointer manipulation rather than bulk data duplication, snapshots complete instantly. Administrators can automate snapshot generation prior to automated system updates, ensuring that any breaking change can be reverted within seconds by restoring the previous snapshot state.

Copy-on-Write storage pools dramatically accelerate instance provisioning. When launching a new container from a base image in Incus, the storage driver creates a thin clone directly from the cached image snapshot. Instead of uncompressing and expanding a rootfs tarball for every new container, Incus creates a writable child snapshot referencing the base image. Launching a new instance takes less than a second, while consuming virtually zero initial storage capacity. This capability is great in continuous integration pipelines and devops workflows, where hundreds of container environments are repeatedly spun up, tested, and destroyed within minutes.

Selecting between ZFS and Btrfs for an Incus infrastructure depends on hardware resources, workload demands, and operational requirements. Systems equipped with ample memory and dedicated physical storage devices will benefit most from ZFS, utilizing its checksumming, cache hierarchy, and volume options. Conversely, systems running on tighter resource constraints or requiring seamless mainline kernel integration will find Btrfs to be an exceptionally versatile, performant option.