No idea, since I do not use Windows.
sudo zfs send ALPHA/Magazyn@auto-2025-04-11_00-00 | sudo zfs receive BETA/Magazyn
It seems to be working. I think it will take some time - the command is executing, but there’s no feedback in the command line. However, in the GUI [Datasets], the recovering volume is visible. I’ll post the final solution in a few hours.
There is a problem, process is interrupted when console closes itself. The process will take around 50 hours to finish (5TB@150Mbps). The “magazn” volume vanished form BETA Dataset (pool). How to ensure that this process is not interrupted?
Login via ssh, make sure you are using bash - if the login shell is anything different, just execute bash.
Bash has “nohup” as the default, so when you put a process in the background (Ctrl-Z, bg) and subsequently logout the process keeps running.
Or use tmux.
1 Like
You can also use the -s flag on the zfs recv side to generate a resume token, which can be used to resume the replication if it was interrupted before completion.
If or when you need to resume, you can use the -t flag on the zfs send side on your subsequent attempts.
The last step: Why destroy the snapshot after it’s received? What’s the harm in leaving it?
Snapshots you are not aware existing take up space if the zvol is susequently written to. And then you come to the forum asking why your pool is full 
I just consider it good practice if the objective is to copy an artifact (zvol or dataset) to clear the snapshot at the destination.
1 Like
A clone of a snapshot is a writable copy of that snapshot.
Note that snapshots contain all of the data from the original dataset/zvol. The blocks that have not changed compared to the original still point at the original while blocks that have changed point at the blocks that used to be part of the original but no longer are.
As a clone is written to it writes new blocks (as any Copy on Write system would), updating the new metadata tree created when the clone was created. Cloned copies of snapshots are used to create useable copies of installed OSes. You install Windows, configure it the way you need, then run sysprep (so you don’t have duplicate UUIDs), snapshot the dataset/zvol as your golden image, then you clone that snapshot whenever you need another Windows VM.
I cannot explain why Windows did not recognize the clone of the snapshot of the zvol. Was the zvol unmounted from Windows when the snapshot was taken? If not, then it may be in an inconsistent state (much like any filesystem which is snapped while mounted).
zfs promote just removes the clone’s dependency on the snapshot.
1 Like
The volume was never dismounted. Snapshots were created at midnight — some while Windows was offline and some while it was online. The LUN inside the ZVOL is not the boot drive.
I will wait over 70 hours for the recovery process to complete. If the volume is not accessible, I will try “my method” (cloning snapshot) again using a different snapshot - one that was created while Windows was offline.
Hi, after recovering using this method, I got exactly the same results as with the cloned snapshot. The partition is not accessible in Windows. The disk size is correct (7 TB), but the partition size is limited to 2048 GB.
I recreated 15 random snapshots - all behave the same. 2TB healthy (protected GPT Partition) and 5TB of non allocated freed space.
This smells like MBR limits…
PS C:\WINDOWS\system32>
>> Get-Disk | Select-Object Number, PartitionStyle, Size, IsOffline
Number PartitionStyle Size IsOffline
------ -------------- ---- ---------
0 GPT 1000204886016 False
5 GPT 7696581410816 False
13 MBR 7696581410816 False
2 GPT 1990180470784 False
That’s a problem from the beginning
It is not MBR it is GTP Partition!
How to recreate GPT Partition?
Did I step on a mine, in a form of not tested use case? Is 7TB ZVOL with GPT forbidden?
Do you have the same iscsi block size set on the clones extent as the original disk?
Please clarify — I did not change any settings regarding block size.
I’m currently recovering the partition. I’ve connected the ZVOL over iSCSI to a Debian VM. There, using gdisk, I discovered that both the primary and backup GPT headers are destroyed or malformed. Then, using TestDisk, I located the correct partition. There’s still work to be done.
After the recovery, I will perform some experiments - for example, whether a 2TB GPT partition will be malformed or not, and whether a 2TB MBR partition will be affected. Is there a threshold or something?
GPT is supposed to handle any practical disk/partition size now and in the future.
The limit is 8 x 1024 ^ 7 bytes with 512 byte sectors.
A GPT (GUID Partition Table) contains a “protective MBR” so older OSs will not detect the disk as empty/new.
Windows reports partition types differently depending on the tool used. For example, Disk Management states that the disk uses GPT, while DISKPART recognizes it as MBR. Linux tools reported a bad checksum.
The blocksize is configured on the iscsi extent.
If you set a different blocksize on a clone of a zvol vs the original, the mbr headers would appear corrupted.
You might have set the original to use 4k sectors vs the clone.
Which would explain the behavior you are seeing.
I used TrueNAS GUI, did not manipulate block size - used default values. How to check that parameter, for my working ZVOL and its clones.
Go to your iscsi shares, view extents, then “edit” the relevant one to see the “logical block size”
1 Like
Again: a GPT contains a protective MBR so tools that do not handle GUID partitioning know the disk is in use.
Bingo!
Original block size 4096
Clone: 512
I will recreate another clone, in 5 hours and give feedback. - I’m a work.
1 Like
Yep, that solved the problem — the clone must have the correct block size. I took one of the cloned snapshots, created a new iSCSI target with the correct block size, connected via iSCSI in Windows, set the disk to Online in Disk Management, and it automatically decrypted. Everything is now perfectly fine.
Stux — I owe you a beer, You can close the ticket now
1 Like