Because of the complexities involved in ZFS analysis, Klennet Recovery has a dedicated ZFS scan mode (three of them, in fact). ZFS recovery is complex and slow. With recommended hardware, you can expect the recovery to take one to two hours per terabyte of the disk capacity.

Preparations

Windows installation

Klennet Recovery is Windows-only. So, there are two options:

• You can move your disks to a Windows PC. With many disks, it may be difficult to find a PC with enough ports to connect them all.
• You can install Windows on a small SSD (120 GB should be okay) and boot your server from it. This way, you do not have to move the disks. However, if the original pool failed due to a hardware problem, the hardware problem is still there. Be careful not to attempt recovery on faulty hardware. At least run a RAM test and take a good look at the power supply.

Connecting the disks

Please do not use cheap PCI-to-SATA controllers to connect the disks. Also, avoid USB-to-SATA adapters like the plague they are. Both tend to malfunction in strange ways if one of the disks has a bad sector or when under heavy load. Troubleshooting will be more expensive than a proper HBA.

For small setups, use Intel chipset SATA ports where possible. If there aren't enough ports, LSI SAS/SATA HBAs are a good option.

CPU. Anything with at least eight threads should be okay. A higher number of threads/cores is better than a higher frequency.

RAM. Depending on the total size of all disks in the pool,

• less than 10 TB, have 32 GB RAM;
• between 10 and 100 TB, have 64 GB RAM;
• for more than 100 TB combined, get as much RAM as you can.

Other factors, such as the number of files being processed, also affect RAM requirements. However, the ballpark figures above hold for most cases.

Hardware stability

ZFS recovery requires collecting a large amount of data and then sorting through it. This puts significant pressure on the hardware, and if the hardware happens to be defective (bad RAM, for example), the recovery fails.

As practical advice, if the pool fails and the cause is unknown, do not run recovery on the same hardware without testing the hardware first. Either test the hardware thoroughly or move the drives to a different system.

Windows updates

The recovery may well take a week or two. You don't want it interrupted by Windows rebooting to install updates. So, install all available updates before starting the recovery, then disable automatic updates.

Target disk space

Klennet Recovery does not fix the pool in place. Instead, it copies the recovered data to a known-good storage. There are two ways you can connect to the target storage.

With small pools, connect a single disk or a couple of disks directly to the PC doing the recovery. Use SATA whenever possible. However, in a pinch, a USB3 external hard drive will work as a target.

With large pools, you can copy the data to a network share. The process is a bit quirky, so make sure you read this page .

Encryption

Klennet Recovery supports native ZFS encryption. It is, however, not a code-breaking tool. You need to provide your passphrase or a key file before you start the scan. Please refer to this page for more details.

Disk selection

You need to connect all the pool disks to the PC for the recovery. You can't recover a ZFS pool by scanning the disks one by one.

Select physical disks or partitions in the disk and partition list, but not both.

If the partition table on one of the disks in the set is damaged, you can try stealing it from the good drive (see here for details).

Only select a set of disks and/or partitions containing one ZFS pool. If you try to open a mix of several ZFS pools, the "Quick" analysis will fail with some or other error message. Other modes will produce a low-quality mishmash of all the pools.

ZFS analysis modes

There are three analysis modes: "Quick", "Normal", and "Deep". However, "Deep" has not yet been fully implemented and is kind of finicky, as of December 2025.

The three modes differ in

• how much intact metadata the method needs to work;
• how far back in time you can go by using this method;
• how long the analysis takes.

Quick requires enough ZFS disk labels to be more or less intact. The labels are required to establish the pool geometry (disk order and vdev RAID levels). A "quick" scan is limited to reliably going back in time for about 5 minutes at most. "Quick" is also a relative term - it may well take a day to process the filesystem.

Normal is roughly equivalent to running the now-discontinued Klennet ZFS Recovery. It can figure out the pool geometry without requiring any ZFS disk labels, and it picks up all old versions of files that are not overwritten. "Normal" scan, however, requires a full scan of the entire disk set and some pretty computationally intensive processing of the data.

Deep scan is still experimental as of December 2025. Theoretically, it picks up even more data, including orphan files and file fragments not referenced from anywhere in the reachable filesystem metadata. However, it requires several passes over the data and a good amount of free SSD space to store the temporary data. It currently only works with RAIDZ1 vdevs.

Picking the appropriate mode for your case

For any kind of instant failure, start with Quick mode. If the result is unsatisfactory, fall back to Normal. "Instant" means that the time between the system working properly and the system being in its final damaged state is less than, say, five minutes.

• You need to recover a pool after a power failure or some kind of instant system crash. The system works fine one moment, then it goes down and fails to come back up.

If the damage takes longer than five minutes to inflict, the Quick mode can no longer go far enough back in time. Start with Normal right away.

• You need to recover a deleted file or files, and the time between deletion and shutdown is longer than five minutes.
• You need to recover from the effects of a cryptovirus, but the snapshots are unavailable or likewise encrypted. In this case, you will be looking for previous versions of the files.

If you know that all the ZFS disk labels have been overwritten, start with the Normal mode. Normal mode neither requires nor uses disk labels.

• A new ZFS pool is created over the disk set, and the goal is to recover the previous pool on the same disks.

Checksum verification

After the scan is complete, Klennet Recovery reads every file and calculates ZFS checksums for its contents. This is roughly equivalent to ZFS scrub. The checksum verification takes a long time and determines which files are recoverable and which are not, with one exception described below.

A special case of a partially written file

When you are copying a big file onto a ZFS pool, the filesystem naturally records several versions of the file as it is being written. Let's say there are two versions of the file. The first version contains only half the data, and the second contains all the data. However, both versions have good checksums. This is because, from the filesystem perspective, there is nothing wrong with the first version. You asked the filesystem to write the first half of the file, and the filesystem complied. The data is there, intact. The filesystem did not know that more data was incoming. Therefore, both versions are marked valid by checksum verification, but the half-written version is useless.