这是我的愚蠢，数据绝不是至关重要的，现在首先是学习经验，其次是节省时间。
我通过 napp-it 中的简单说明设置了一个 100GB 的 iSCSI 目标。这是一个卷 LU。
然后，我将 Windows 7 计算机连接到 iSCSI 目标，将其格式化为 NTFS，并通过一些大型 iso 文件传输测试其性能。然后，我取消映射驱动器，重新连接到目标，并被迫再次格式化为 NTFS。
就在那时，我意识到我传输的文件仅存在于 iSCSI 目标上。我有点生气，然后继续做我的事情。当我清理我的实验时，我注意到这个屏幕： https://i.stack.imgur.com/LI9Qp.png
那是我的实验目标罐/iSCSI，里面仍然有大量数据。
假设我的 iso 仍然在这个池中，我该如何恢复它们？
在撰写本文时，我使用了 www.runtime.org 上的 GetDataBackup for NTFS。虽然它找到了两个先前的 NTFS 分区，但没有数据。
答案1
不幸的是，没有 - 那里没有比 Windows 可以看到更多的数据 - 除非你拍摄了 ZFS 快照。
要从 ZFS 公开到 iSCSI，在实际处理文件时表现得像原始磁盘，它需要在 ZFS 池上创建一个假块设备作为文件。此特定文件在 iSCSI 上显示为空白“磁盘” - 允许 Windows iSCSI 启动器使用 NTFS 文件系统对其进行格式化。这与 NFS 或 SMB 等文件协议形成对比，在这些协议中，文件系统根本不是 NTFS，Windows 系统中的文件将直接作为文件存储在 ZFS 卷上。
由于 iSCSI 暴露以这种方式工作，作为 ZFS 上的文件，暴露为磁盘，因此 ZFS 实际上无法从 NTFS 角度知道哪些是“空闲的”，哪些是“已使用的”。相反，它真正知道的只是该假磁盘文件有多大 - 以及已写入了多少数据（就是这个REFER数字 - 86 GB，其中还包括任何其他文件/tank/iSCSI）。
除非拍摄了快照，否则该假磁盘中的数据就是您可用的数据 - 但与普通磁盘一样，文件可能仍在磁盘上，只是没有文件系统指向它们。我不熟悉那个特定的工具，但检查整个磁盘中是否存在孤立文件的工具可能会奏效。
答案2
我以前遇到过这个问题，刚刚又遇到了。我用的是UFS 探索者工具作为已删除卷的最后一次数据恢复解决方案。在今天的情况下，我正在从 Linux XFS 分区中恢复数据，该分区是在通过位于 VMWare VMDK 中的 NexentaStor VM 共享的 ZFS iSCSI 导出之上创建的。很多抽象层...
数据在 XFS 文件系统级别被删除，因此我将 iSCSI 导出重定向到 Windows 2003 Server VM，其中UFS 探索者生活。从那里，我将使用 UFS Explorer 尝试将数据恢复到另一个存储设备上。
8小时后……
UFS Explorer 能够恢复数据，文件名完好无损。我现在正在复制到另一个硬盘。不幸的是，一些目录名称没有，被替换为“inodeXXXXXX”。不过，这是相当典型的。但总的来说，在某些情况下，这种类型的恢复是可能的。
