ZFS Pool Maintenance Options
Pool Maintenance and Health Operations
As mentioned the upper section of the Pool Options screen is used for monitoring and maintaining the overall health and integrity of the ZFS pool. From here, administrators can manage scrub operations, review pool status, schedule maintenance tasks, and perform operational recovery functions.
Understanding ZFS Scrubbing
Scrubbing is one of the most important maintenance operations within ZFS and should be treated as a normal part of ongoing storage management rather than an occasional repair task.
During a scrub operation, ZFS systematically reads all data blocks across the pool and validates them against their stored checksums. This allows ZFS to detect silent corruption, damaged sectors, unreadable blocks, cabling issues, controller faults, firmware problems, and other forms of data degradation that traditional filesystems may never detect until the data is actually accessed.
Where redundancy exists within the pool, such as mirrors or RAID-Z configurations, ZFS can often automatically repair damaged data during the scrub process by reconstructing the correct block from parity or mirrored copies.
Regular scrubbing is critical because modern disks are extremely large, and unrecoverable read errors become statistically more likely as capacity increases. Without routine scrubbing, corruption can remain hidden for months or years until backups, virtual machines, or production data are required during a recovery event.
Administrators should also understand that scrub operations are highly intensive. A scrub effectively forces the storage platform to sequentially read the entire pool, which generates sustained disk activity, controller load, cache pressure, and backend I/O traffic. On large pools this can take many hours or even days depending on pool size, drive speed, utilisation levels, and active client workload.
As a result, scrub operations can impact production performance, particularly on heavily utilised systems. While ZFS is designed to remain online during scrubbing, administrators should ideally schedule scrubs during quieter operational periods where possible.
Pool utilisation also plays a major role in scrub efficiency and overall ZFS performance. Allowing a ZFS pool to exceed roughly 80% utilisation is generally considered poor operational practice. As free space becomes constrained, ZFS has fewer available allocation regions to work with, resulting in increased fragmentation, reduced write efficiency, higher latency, longer resilver and scrub times, and significantly increased performance degradation under load.
A heavily filled pool also reduces ZFS’s ability to efficiently self-heal damaged blocks during maintenance operations and can dramatically increase recovery times following disk failures or resilver events.
In enterprise environments, maintaining adequate free capacity within the pool should be treated as part of normal operational planning rather than unused waste space.
A resilver operation occurs when ZFS rebuilds data onto a replacement disk or automatically activates a configured hot spare following a drive failure. Unlike traditional RAID systems, ZFS only rebuilds the blocks that contain live data rather than rebuilding the entire disk. This reduces unnecessary I/O and can significantly improve rebuild times on partially utilised pools. During resilvering, ZFS also validates data integrity using its checksum system, helping ensure damaged or corrupted blocks are not blindly copied onto the replacement device.
Controls are provided to manually start or stop scrub operations, configure recurring scrub schedules, review scrub history, and disable scheduled scrubbing where operational requirements demand manual control over maintenance windows.
To manually start a scrub operation, select Start Scrub. To stop an active scrub, select Stop Scrub.
Note: If a scrub operation is stopped before completion, ZFS will restart the scrub from the beginning the next time it is launched. Scrub progress is not resumed from the previous stopping point.
It is recommended that a weekly scrub schedule be configured using the Schedule Weekly Scrub option to help identify disk, cabling, controller, or data integrity issues before they become operational problems.
The Schedule Weekly Scrub window allows administrators to define when automatic scrub operations will run. One or more days can be selected along with the execution time using 24-hour format. In this example, the scrub is configured to run every Sunday at 02:00.
Once saved, euroNAS will automatically start the scrub operation at the configured time each week.
Understanding ZFS TRIM
TRIM for SSD and NVMe storage works in a similar way to how a ZFS scrub helps maintain pool integrity. While a scrub validates and repairs data consistency across the pool, TRIM helps maintain the internal health and sustained performance of flash storage by informing the device which blocks are no longer in use and can be safely reclaimed. This becomes particularly important where SSD or NVMe devices are being used as metadata, cache, or write acceleration layers, as these devices are often handling large amounts of small-block IO and filesystem metadata activity. A good example would be environments containing large numbers of small files, virtual machine images, or heavy directory traversal workloads, where metadata devices can become extremely active. Regular TRIM operations help the SSD maintain efficient internal garbage collection and free block management, which in turn assists in sustaining responsive metadata and cache read performance over time while also reducing unnecessary flash wear.
The Start TRIM option is used to manually begin a TRIM operation on supported SSD and NVMe devices within the pool. During the operation, ZFS will notify the underlying flash devices which blocks are no longer in use so they can be reclaimed internally. The Stop TRIM option can be used to halt an active TRIM operation if required.
Understanding ZFS Checkpoints
A ZFS checkpoint should be treated as a temporary safety net for the entire storage pool. When a checkpoint is created, ZFS preserves the exact state of the pool at that moment in time, allowing the administrator to roll the entire pool back if required. Any snapshots, datasets, or data created after the checkpoint was taken will be lost if the pool is rewound to that checkpoint. Because ZFS must preserve all blocks referenced by the checkpoint, deleted data may continue consuming space until the checkpoint is removed. For this reason, checkpoints are typically used only during major maintenance, upgrades, or risky configuration changes and should normally be removed once the work has been successfully completed. Due to the potential impact on pool state, snapshots, and available capacity, it is strongly recommended that euroNAS Support is consulted before using this feature.
The Create Checkpoint option is used to manually begin a checkpoint creation operation
The Rewind to Checkpoint option is used to manually rewind to a previously created checkpoint