Take the 2-minute tour ×

This was me being stupid and the data is by no means critical and is now a learning experience first, time saver second.

I set up a 100GB iSCSI target via the bare bone instructions in napp-it. It's a volume LU.

I then had my Windows 7 machine connect to the iSCSI target, formatted it to NTFS, and tested the performance of it with some large iso file transfers. I then unmapped the drive, reconnected to the target, and was forced to format to NTFS again.

It was then I realized the files I had transferred only existed on the iSCSI target. I threw a little fit and then went about my business. When I was cleaning up my experiment I noticed in this screen: http://imgur.com/1xlcu.jpg

That is my experimental target tank/iSCSI and it still has a lot of data in it.

Assuming my isos are still in this pool how would I go about recovering them?

While writing this I used GetDataBackup for NTFS from www.runtime.org. And while it found two previous NTFS partitions there was no data.

share|improve this question
Any luck? What was the result? –  ewwhite Apr 1 '12 at 13:25
I haven't yet found a solution. It's been put on the back burner. –  David Apr 19 '12 at 17:21
add comment

2 Answers

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.

share|improve this answer
add comment

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.

enter image description here

share|improve this answer
add comment

Your Answer


