Recover NTFS data from a ZFS pool that was exposed as an iSCSI target

Solution 1:

Unfortunately, no - there's no more data there than Windows can see - not unless you took a ZFS snapshot.

To expose from the ZFS to iSCSI, behaving like a raw disk when it's really dealing in files, it needs to create a fake block device as a file on the ZFS pool. This specific file is exposed as a blank "disk" over iSCSI - allowing the Windows iSCSI initiator to format it with the NTFS filesystem. This is in contrast to a file protocol like NFS or SMB, where the filesystem wouldn't be NTFS at all, and the files from the Windows system would be stored directly as files on the ZFS volume.

Since iSCSI exposure works in this way, as a file on top of ZFS that's exposed as a disk, ZFS really has no way of knowing what's "free" and what's "used" from the NTFS perspective. Instead, all it really knows is how big that fake disk file is - and how much has been written to with some kind of data (it's that REFER number - 86 GB, which will include any other files in /tank/iSCSI as well).

Barring having taken a snapshot, the data in that fake disk is the data that's available to you - but in the same way as a normal disk, the files may still be on disk, just with no filesystem to point to them. I'm unfamiliar with that particular tool, but something that checks the whole disk for orphaned files may do the trick.

Solution 2:

I've had this problem before and just ran into it again. I use the UFS Explorer tool as a last-attempt data recovery solution for deleted volumes. In today's case, I'm recovering data from an Linux XFS partition created on top of a ZFS iSCSI export shared via a NexentaStor VM sitting in a VMWare VMDK. Lots of layers of abstraction...

The data was deleted at the XFS filesystem level, so I'm redirecting that iSCSI export to a Windows 2003 Server VM where UFS Explorer lives. From there, I will use UFS Explorer to try to recover the data onto another storage device.

8 hours later...

UFS Explorer was able to recover the data and filenames are intact. I'm copying to another hard drive now. Unfortunately, some directory names are not, replaced with "inodeXXXXXX". This is fairly typical, though. But all-in-all, this type of recovery is possible in some situations.