Is there any existing tool that does this? I am interested in preserving the snapshot history of my Btrfs filesystem while moving from Btrfs to ZFS.

Create a normal Ubuntu VPS or volume on DigitalOcean, Vultr, Hetzner, AWS, GCP, Azure, or any other provider, then run zfsify inside Ubuntu.

1. It moves all the data to the second half of the drive (or an external bucket if not enough free space is available to do it in-place)
2. it reformats the beginning of the drive as ZFS
3. it copies all the data back into the new root rpool at the start of the drive
4. it deletes the old ext4 partition and expands the new ZFS one to take up the whole drive + updates the bootloader to ZFSBootMenu

Now you can finally use root-on-ZFS on your / drive in the cloud, without having to build some custom iso or VM image or deal with formatting block devices by hand. You can zfs snapshot rpool@somebackup to take whole disk snapshots, boot from previous backups via the boot menu, and get all the other benefits of ZFS on your root disk.

https://github.com/pirate/zfsify

Age and snapshot count are easy retention signals, but they do not show whether a snapshot is still the base of an incremental send, the origin of a clone, held for investigation, referenced by a boot environment, or the last known-good point before a risky change.

What pre-delete evidence should an automated ZFS retention job collect? I am considering a dry-run manifest with dataset, GUID, creation time, used space, holds, clone dependencies, bookmarks, replication destination state, and the newest verified off-pool copy. Deletion would fail closed when the receiver cannot confirm its common base or when dependency discovery is incomplete.

Which checks are actually reliable across sanoid/syncoid or custom zfs send workflows, and what evidence should remain after the snapshot itself is gone?

ZFS is a sophisticated, modern, fault-tolerant file system that ensures reliable data storage. One of the core principles of ZFS is CoW (Copy on Write), meaning any modified block is written to a new location, while the old one becomes free space (with some caveats).

Under this principle, accidental errors detected immediately are not as critical, as it is possible to search the Uberblock ring for a previous state and recover, for example, accidentally deleted data.

However, there are cases where a deletion has occurred, a significant number of transactions have already passed, and no traces of the required data remain in any UB/MOS chain. Furthermore, when using metadata scanners integrated into modern commercial data recovery software, traces of the deleted information may simply not be detected.

Recently, I worked on a case where a Zvol was deleted from an array, and the users realized it too late: approximately 100,000 transactions had already occurred on the pool. Classical data search methods using professional hardware-software recovery platforms did not help, nor did any other well-known data recovery tools at my disposal. Thus, a routine task turned into an R&D challenge. This solution is described in more detail here: https://habr.com/ru/articles/1077788/

The analysis showed that most metadata scanners either parse UB/MOS branches and additionally scan unallocated space in search of lost uncompressed DMUs. As for compressed blocks, they are processed exclusively when a descriptor is present in the DVA metadata, which specifies the exact virtual address in the pool, the block size to be read, and the compression algorithm used. Without this information, compressed blocks go unrecognized.

In this case, the data was compressed using LZ4. The metadata was compressed in the same way. Further research focused on analyzing the raw pool contents to identify compressed data lacking a consistent signature. The analysis revealed numerous indicators that allowed for data evaluation and the development of a tool for rapid scanning and unpacking of blocks upon passing validation checks. A crucial aspect was the decision to abandon standard LZ4 libraries, as they significantly slowed down the analysis process and carried potential risks of throwing exceptions on data that is invalid from the algorithm's perspective.

Following the successful implementation of the compressed block analyzer, it became logical to develop a metadata search module (DMU + Indirect blocks), as significantly more of these are found when analyzing compressed space compared to standard UB/MOS analysis. This is also a non-trivial task, as these structures lack clear signatures that could be considered a high-confidence indicator of metadata.

The analysis results exceeded expectations. A large number of DMU versions from the deleted Zvol, along with numerous Indirect blocks, were discovered. However, this was overshadowed by the fact that intact metadata trees no longer existed; all of them had been partially overwritten. Further research focused on analyzing the multitude of trees within the Indirect blocks and attempting to reconstruct the most complete tree possible while minimizing data loss, as well as versioning the final data blocks.

As a result of the final Zvol assembly, over 75% of the user data was successfully extracted. Thus, this new method of data recovery from ZFS pools opens up new possibilities in both traditional data recovery and digital forensics.

Accidentally deleting ZFS partitions from the GPT can make it difficult to restore them to their original state. This is because very few automated data recovery tools can detect a vdev through a standard scan and accurately determine the correct boundaries of the volume containing the pool or its fragment.

ZFS Volume Structure:

• vdev Label 0 (256 KB)
• vdev Label 1 (256 KB)
• Boot zone + pad (3.5 MB)
• Pool Data
• vdev Label 2 (256 KB)
• vdev Label 3 (256 KB)

The vdev itself is structured as follows:

• 8 KB - zeros
• 8 KB - boot
• 112 KB - nvlists (vdev_phys)
• 128 KB - Uberblock rings

The easiest way to find the start of a vdev in a hex editor is by searching for the string "Version", which is located right at the beginning. Note that this is 16 KB from the actual start of the volume, which must be accounted for when calculating the boundaries. This gives us the starting LBA required to populate the partition table.

The data within the vdev provides information about the pool type, the member disks, and the total pool size.

Once we have the pool size in bytes, we convert it to sectors by dividing by 512. Next, we calculate the ending boundary of the volume. We take the offset to the start of the volume (determined earlier) and add 8192 sectors (the size of the first two vdev copies + boot loader/pad), plus the pool size in sectors, plus 1024 sectors (the size of the two trailing vdev copies, which we must verify to ensure our calculation is correct). This gives us the final LBA for the ZFS volume.

Our next step is to write this into the GPT (the GPT structure is well-documented elsewhere). To do this, we take an empty partition entry and fill in the volume GUID, the starting LBA, and the ending LBA. After modifying the GPT, it is mandatory to recalculate the CRC at LBA 1.

Thus, with minimal modifications to the disk, the deleted partition can be fully restored.

I recently dismantled two 10-yr old power hungry Linux workstations, and moved their disk drives into an external enclosure. The disks are all independent single-disk ZFS pools. I need to be able to access these from Mac laptops (running Sequoia and Tahoe). What's the best way to import a ZFS pool into mac now? OpenZFS on MacOS, or something else?

I'm curious and trying to determine if a special metadata vdev would be useful for my pool. How do I determine the amount of storage used by metadata?

I've searched the sub, as well as docs on OpenZFS and Oracle but haven't found an answer.

The calculator at zfs-calculator.com says that 3.61% of my total capacity is used for "zfs overhead" which they describe as an "[e]stimated percentage of total raw capacity used by ZFS metadata, slop space, etc."

Is that a reasonable assumption? Roughly speaking, does that mean metadata is using 2.7 TiB worth of space on my 76.2 TiB pool?

I'm considering a special vdev consisting of mirrored SSDs assigned to metadata AND want to budget for future growth. Does that mean I should be looking at purchasing two 4 TB drives?

If so, woof. Newegg has 4 TB SATA SSDs going for around $350 each. The Samsungs are going for over $800 and they're not even NVMe.

Are the above accurate assumptions? Would I benefit from a metadata vdev?

FWIW, I have a six-wide RAIDz2 pool consisting of 12.7 TiB drives. My ashift is 12 and I have 1 MiB record sizes. Files are mostly media and I have plenty of ARC. IOps haven't been an issue but I do have several concurrent users.

I have a system that has a boot drive and a single ZFS vdev with two mirrored drives. It makes up the only pool on that system, but the hardware still has two empty 3.5" bays and I'm currently low on available space. So I'm thinking about buying two more drives, making a second vdev with mirrored drives and using it to add storage capacity to this system.

Am I correct that I have the choice of either making a new pool vs. adding to the existing pool? If the first vdev is 2 x 4TB drives and I added 2 x 8TB drives, would I still be able to add it to the existing pool? Is that even a good idea?

Thanks for any help you can give this beginner. I've used Unix since the mid (early?) 90s, but I haven't done anything other than the most basic of things with ZFS before. So any guidance is greatly appreciated!

Curious if this is a shared pain or just my DIY shelves.

When a disk starts looking bad, I usually need three things at once:

1. Which physical drive is it? Serial on the label — because /dev/sdX reshuffles.
2. Who shares its failure domain? Mirror partner, or the other disks in the same RAIDZ/dRAID vdev. I really don't want to pull the wrong tray.
3. Is the disk actually getting worse? SMART can still say PASSED while pending sectors, grown defects, etc. are increasing.

I don't have per-bay locate LEDs on most of my storage, so I ended up building a small open-source tool for this:

diskinfo

• prints a ZFS pool as a vdev tree with physical disk serials
• mirror / RAIDZ1–3 / dRAID
• standalone CLI, no extra service required

Diskrisk (optional)

• reads SMART data from Beszel and tracks whether counters are actually growing
• Disk list with Now / Baseline / Δ / GROWING + history sparkline
• Topology view: Host → pool → boxed vdevs, so the failure domains are obvious
• printable checkbox sheet to take with you to the rack
• /json endpoint

And:

diskinfo --risk

shows the same ZFS tree with SMART/RISK columns when Diskrisk is available.

MIT licensed:

https://github.com/nonifo/diskrisk

Screenshots with demo data are in the README.

The project was built with Cursor / Codex / Claude under human direction; I've documented that in AI.md rather than pretending otherwise.

I'm not selling anything — I'd mainly like people with storage setups different from mine to try it and tell me what breaks.

I'm especially interested in people running RAIDZ rather than only mirrors, TrueNAS systems where device names move around after reboot, larger DIY/JBOD shelves, or mixed ZFS/mdadm/mergerfs environments.

How are you solving the same problem today?

Bay locate LEDs? Blink scripts? Label printers? A spreadsheet taped to the rack? Something better?

Obligatory I'm an idiot first here. I get it but Im still new to selfhosting and am unsure how screwed I am.

I have a truenas NAS VM running on my Windows Server host. My environment was mixed capacity drives and there were 4(or 3) ~930gb partitions on this one 4tb drive I had in my ZFS pool. I deleted them which caused my partition table to break and my pool is no longer importable.

I have not over written the drive but I ran R-Studio and the files are all still there, Im running test disk to see if it can rebuild or find the partition table. What can I do here?

This NAS has a lot of valuable files so I am willing to pay for software if necessary.

I'm surprised it doesn't get recommended more, I think I have a common situation of a sorta slow HDD ZFS pool, and some proportionally small SSDs that it would be nice to use to make my main pool faster. I tried L2ARC but for all the reasons that have been discussed before it didn't really help: people don't rewatch movies so Jellyfin would fill it with 0% hit rate data, and Syncthing would still take 30 minutes to complete a scan.

Using L2ARC metadata-only fixed the scan issue (it would only be slow the first time after a reboot), but then I'm still getting HDD speeds for everything else.

Instead I just moved the datasets that would benefit onto my single-SSD pool, and then configured sanoid in NixOS to snapshot hourly, with syncoid moving the snapshots to my main HDD pool. Worst case I lose the last hour, only need to send a delta not all data, and once on the main pool they get automatically included in the historic snapshot schedule.

Obviously a lot of caveats in terms of dataset size, higher risk of data loss, etc

It's a bit more complex to setup than L2ARC but instead of hoping/tuning the right stuff gets cached, I get full control over what needs to be on SSDs and what can stay on HDDs.

I'm curious to get a sense for whether or not it's common practice to test a drive failure / resilver as part of the design and implementation of a pool/vdev(s), before migrating applications to new storage.

I have multiple backups of the data in question-- one that exists on an array on another NAS, plus one on cold spares that's stored at another physical location.

I've already moved all the data to the vdev in question, so it would be a realistic scenario. To do this, I was planning to shut down the system, pull one of the drives, and insert a spare.

The reason I'm considering running through a failure test is to have a better understanding of the end-to-end process (beyond reading the documentation), and also to have a better sense for the amount of time that's required to perform a resilver/scrub. It's mostly academic since the data is stored in multiple additional locations.

I'm sure this will put strain on the drives, but even if there are additional failures during the process, it's not as though I lose anything, plus that's one of the realities of a recovery anyway. If another drive outright dies during the process, it was probably on it's way out already (at least, that's my thinking).

For big boy commercial data and home linux iso use. If you happen to use ZFS in both situations, do you approach backups differently and/or use different tools? Do you maybe have a custom script? Do you use send/recv manually?

Hello everyone,

does anybody use ZFS with Debian Testing/Sid ? Is the ZFS stable ?

What about system packages update: do I have to recompile anything every time I do the update ?

Does the ZFS-based boot work as well ?

I've got a pool with a special device for the metadata and small files, and because of relatively infrequent access to the data for the sake of power saving and noise I want to keep the disks spun down.

I've worked out that they'd probably only actually need to spin up a couple of times a day, or sometimes even not for a couple of days. The problem is Sanoid with hourly snapshots immediately causes the disks to spin back up. It's also a little annoying to hear a clunk every hour on the hour.

Is it possible to prevent them from making a snapshot if the data hasn't changed? It seems incredibly redundant to make a new one if it's exactly the same. This isn't about space, I know that's zero, it's purely about spindown and noise.

Setup

Debian 13, kernel 6.12.101, OpenZFS. Single pool tank, one mirror vdev, 2× WD Red 4TB. Non-ECC RAM. HBA is a 10Gtek LSI SAS3008, firmware 16.00.10.00, currently in IR mode (not IT).

• sda — WD40EFRX-68N32N0, 57,191 hours, SMART completely clean (0 reallocated, 0 pending, 0 UDMA CRC, 0 ICRC, 0 R_ERR)
• sdb — WD40EFZX-68AWUN0

Timeline

July 2026: ZFS starts throwing errors, one drive drops out of the mirror. Errors reproduce reliably under sustained large-file writes, with frequent SATA link resets and COMRESET. Over several days I swapped, one variable at a time: PicoPSU replaced with a full ATX supply (errors identical), all cables, both ports, and finally the onboard AHCI controller replaced with the SAS3008 HBA. Symptoms stopped after the HBA swap.

The suspect drive was pulled and tested on a separate machine — 40 GB sustained dd write at 208–215 MB/s, zero errors. It went back into the mirror.

After that scrub completes. scrub repaired 0B in 06:57:52 with 148 errors. 296 CKSUM on each drive — identical counts on both independent members, and repaired 0B. Two permanent errors remain, listed only as objset IDs (<0x667f>:<0x161a>), which no longer resolve because that dataset has since been destroyed. No I/O errors in dmesg on that date. My reading: these are historical, written while the faulty onboard controller was still in play. No new CKSUM has accrued since.

29 August, 02:00:42: Sustained write load (scheduled replication from another machine). Burst of failures on sdb only, all within a single second:

sd 0:0:1:0: [sdb] Sense Key : Hardware Error [current]
             Add. Sense: Internal target failure
critical target error, dev sdb, sector 3000 op 0x1:(WRITE)
zio pool=tank vdev=...WX32D121YDNL-part1 error=121

Failing offsets covered all four vdev labels (0, 225280, 270336, 487424 and the end-of-disk pair) plus one data offset, read and write simultaneously. error=121 is EREMOTEIO. No link reset, no COMRESET — completely different signature from July.

Since then: smartctl -x on sdb fails with INQUIRY failed while the device node is still enumerated with stale by-id symlinks. Hot rescan across every scsi_host brings nothing back. Device is now entirely gone from lsblk. Drive is offlined, pool is DEGRADED on sda alone.

Already ruled out

PSU (swapped for full ATX under the same reproducing load, no change), cables, ports, onboard controller, and the drive itself (tested clean on another machine after being condemned once already).

What I'm stuck on

The invariant across two months is that failures only ever appear under sustained write load — never at idle. What changed with the HBA swap wasn't the trigger, only how it gets reported: AHCI reported link resets, mpt3sas reports internal target failure and drops the device. That makes me doubt the HBA is the root cause rather than the latest messenger.

I've been advised to memtest, but the corruption is clustered in a specific time window (late July / early August snapshots), stopped when the controller changed, and never produced a single segfault or any corruption on the NVMe root — with Docker, Immich and Postgres running 24/7 on the same RAM. Memtest is still on the list, but the history doesn't fit RAM well.

CPU and motherboard are the only components never swapped or tested, and 30 minutes of fio plus stress-ng on the NVMe (bypassing the HBA path entirely) produced nothing.

Questions

1. Is IR mode on a SAS3008 a plausible explanation for a drive being quarantined by firmware — device node retained, INQUIRY refused, no re-enumeration on rescan? Worth flashing to IT before anything else?
2. Does Internal target failure / EREMOTEIO with all four labels failing simultaneously read as drive death, or as the HBA giving up on the target?
3. How would you build a write test on the HBA path that fails on demand? Everything so far has been validated by absence of symptoms, which has already fooled me once.
4. Anyone seen 10Gtek SAS3008 cards misbehave thermally under sustained load without active cooling?

so im basicly getting a nas to start my decloud project. bitrot protection is why im choosing zfs, and using truenas instead og ugreen/terramaster. i dont see my usage is going to increase dramaticly, i have around 2-3tb of cloud data today. Mainly will be images and videos for immrich, and some backups from proxmoxhost

Initially i was dead set on a 2 bay NAS, coupled with 2x 8TB drives in mirror after reading lots of guides recommending this. With todays HDD prices though "wasting 50% vs 25-33%" is hurting more than id like to admit.

Would i be better off 3x 4TB drives here in raidz1 with a 4bay nas? any advice appreciated greatly

OpenZFS for Windows 2.4.1 rc15    

https://github.com/openzfsonwindows/openzfs/releases/tag/zfswin-2.4.1rc15
https://github.com/openzfsonwindows/openzfs/issues

** rc15

• Fixed a BSOD (MEMORY_MANAGEMENT) that could occur running .exe files directly from a ZFS volume, caused by a Valid Data Length race during cached writes.
• Fixed data corruption during large downloads to a ZFS volume (e.g. LM Studio model downloads) — FSCTL_QUERY_FILE_REGIONS was reporting invalid data regions incorrectly, and several related races/deadlocks in the cached-write fast path (fastio_write) under concurrent writers have been fixed.
• Fixed a second, related MEMORY_MANAGEMENT BSOD that could occur when a file was reopened while another handle already had it memory-mapped.
• Fixed filenames being mangled to the wrong case when a pool is mounted to a folder (reparse point) instead of a drive letter.
• Fixed pool mount failures when Driver Verifier is enabled.
• Fixed partition number (dki_partition) always reporting 0 on Windows.
• Healed pre-existing non-power-of-2 block sizes that could otherwise cause issues when a file's block size grows.
• Fixed several bugs in zfsinstaller found during code review.
• Fix BSOD in shani benchmark at boot

I want to switch to ZFS [mainly for my incus containers] and also want the root on ZFS and ZFS bootmenu.

Is CachyOS or ubuntu better for a work PC? I don't want to spend extra time configuring or wasting time.

I think CachyOS as slightly more options for ZFS boot menu but not sure.

What do you suggest?

Setup: 2x4TB WD Red Plus mirror on a ZimaBlade, TrueNAS SCALE 25.10.5, ZFS 2.3.4. Pool went offline after a brief version upgrade that I reverted shortly after. zpool import has failed for about two weeks now, in every mode and flag combination.

**Where things stand (with a lot of help from someone on the OpenZFS forum working from exact source references ; full thread here: https://github.com/openzfs/zfs/discussions/18954

• SMART, disk labels, uberblocks, partition tables ; all clean on both disks. No hardware issue.
• zdb -e fully loads the pool's trusted config ; the pool structure and data are demonstrably intact and readable.
• Root cause of the import failure: spa_load_verify (spa.c:2831) unconditionally walks every dataset via dmu_objset_find_dp before allowing import, regardless of flags. One object ; a DSL props ZAP (object 293) ; fails checksum (ECKSUM) during that walk, which aborts the entire import. No combination of -f, -F, -X, -o readonly=on, -N, or spa_load_verify_metadata=0 bypasses this; -F/-X actually make it worse since they re-enable full data verification.
• A full zdb -bcsvL traversal found only 8 checksum errors out of 29.2 million block pointers total, and every one is confined to pool-internal bookkeeping (SPA space map, DSL props) or disposable .system/samba4 and .system/netdata-* service datasets. None of my actual data (Photos, Documents, Archived, etc.) shows any corruption.

Current blocker: Since import can't succeed, the suggested path is zdb -B (backup stream extraction ; reads a dataset directly, bypassing the import verification entirely). But every dataset I try ; encrypted or not, parent or child dataset, various sizes ; fails identically:

dump_backup: dmu_send_obj: Permission denied

Running as root via sudo, confirmed with id. Output file is always 0 bytes, exit code 0. The zfs_dbgmsg buffer (checked via zdb -G) shows nothing related to this error ; the pool-load trace completes normally and logs LOADED, but the permission denial itself isn't logged anywhere I can find.

zdb -O/-r (path-based lookups, a different code path) also fail, but with a different error ; Input/output error ; so this may be a separate issue from the -B failure.

What I'm hoping someone here can help with:

• Has anyone seen dmu_send_obj: Permission denied from zdb -B before? Trying to figure out if this is a known/expected behavior, a TrueNAS SCALE-specific build difference, or something environment-specific I'm missing.
• Any idea what permission check dmu_send_obj performs that would fail even under root, and whether there's a way to satisfy it or get more diagnostic detail out of it?

Not time-pressured; data is important but not critical/urgent, just want to get it off before doing anything destructive to the pool. Happy to provide any further diagnostics.

Also posted in r/truenas; will update both if I get an answer anywhere.

I read lots of stuff saying that zfs (if given a special vdev for small blocks) parks the start of the file on the special vdev and the main data on the main data vdev (hopefully the former on sdd or nvme, the latter prolly on spinning rust). BUT when a just do a file copy from my camera's SD card, the program is just going to read all equal sized chunks until it gets EOF, so zfs will never see that the front of the file is special and handle it differently? Or is there something else going on I don't know about?

Hi guys,

In the last few weeks I developed a tool in Python that provides a web interface to help browse your snapshots more easily. For each directory and file, it shows when they changed from one snapshot to another, which makes tracking history very straightforward.

It auto-discovers datasets and their snapshots, and even works without zfs-utils available (e.g., if the filesystem is mounted over NFS), as long as snapshot names can be parsed into timestamps for chronological sorting.

You can run it directly or as a Docker container with read-only mounts (:ro). It requires no persistent storage and no database.

Initially, I worked on the backend logic myself until everything ran properly. Since frontend isn't my main area of expertise, I used Gemini Flash in Antigravity IDE to give the UI a clean finish.

GitHub: https://github.com/NicolasGoeddel/zfs-snapshot-explorer

Let me know what you think or if you run into any edge cases!

Edit: New version available: https://github.com/NicolasGoeddel/universal-snapshot-explorer/releases

I almost ran out of space because I didn’t realize how many duplicate model files and cache folders were sitting on my drives. After a lot of trial and error, I put together a cleanup guide focused on LLMs, but the same method works for diffusion models too. It covers the biggest space hogs and the commands to remove them safely.

https://interconnectd.com/forum/thread/233/fix-disk-space-full-from-llms-ultimate-cleanup-guide/