我有一个基于ZFS的iSCSI SAN，可将ZVOL提供给一些VM服务器。 如今，networking故障导致客户端上安装的所有iSCSI卷都转为RO。 唯一的办法就是closures它们并重新启动，经常运行fsck让iSCSI卷回到在线状态。 那么，fsck决定彻底摧毁其中一卷。 所以，看起来我不能解决fsck的问题。
我已经读了很多关于在ZFS上恢复文件的情况，但是在这种情况下，我正在处理ZVOL，从某种意义上说，它更简单一些，但是我还没有看到任何处理试图回滚一个块设备。 有什么build议么？
-TIA-
一些数据集详细信息：
Dataset zpool1/vm3 [ZVOL], ID 59, cr_txg 12078, 44.6G, 2 objects, rootbp DVA[0]=<6:6c2c4b1e00:200> DVA[1]=<7:487aa4b200:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=7736596L/7736596P fill=2 cksum=4c78779ec:2049fb2de6c:6f2f6c4a44e9:1042484aee3ded Deadlist: 1K (512/512 comp) mintxg 0 -> obj 48 mintxg 1 -> obj 4157 Object lvl iblk dblk dsize lsize %full type 0 7 16K 16K 7.00K 16K 6.25 DMU dnode dnode flags: USED_BYTES dnode maxblkid: 0 Object lvl iblk dblk dsize lsize %full type 1 5 16K 8K 44.6G 200G 36.45 zvol object dnode flags: USED_BYTES dnode maxblkid: 26214399 Object lvl iblk dblk dsize lsize %full type 2 1 16K 512 0 512 100.00 zvol prop dnode flags: USED_BYTES dnode maxblkid: 0 microzap: 512 bytes, 1 entries size = 214748364800 系统是CentOS 7.1
Linux san1srvp01 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
没有相关的快照; 我认为这是不言而喻的。
之所以提出这个问题，是因为Max Burning的这篇文章涉及到通过法医技术研究对象恢复的问题。 这当然依赖于ZFS内部知识的不足。 我所看到的大部分内容都是关于文件对象的回溯，这些对象与实现原始块存储的对象非常不同，而在ZVOL相关内部，我几乎没有看到任何内容。
即使我不能在技术上“回滚”fsck所做的改变，至less可以帮助我们找回一些关键的原始块。 这应该是可能的，因为ZFS的COW行为…我缺乏足够的知识，但是我通常不会阻止我。
是的，可以做到。 这将是混乱。
没有相关的快照; 我认为这是不言而喻的。
因此，如果没有与zpool和data是健康的时间相关的快照，则没有任何简单的追索或回退的能力。
正如Tero Kilkanen在评论中正确表示的那样，您需要从zvol的有效期开始快照，否则您的数据将丢失。
一些背景：
可以从任何数据集（文件系统或卷（zvol））创build快照，本身也是（只读，从属）数据集。 它们总是primefaces性的，所以你可以在整个数据集的特定时间点上获得状态（尽pipe对于最上面的应用程序，它可能看起来像在最坏的情况下硬盘或系统的重置），并且可以确定您的数据完整性被保留（至less在同步写入时，asynchronous写入当然可能被部分丢弃）。
zvols和文件系统在这方面的唯一区别是 – 因为每个快照总是引用整个数据集 – 您可以从文件系统快照中select要恢复的文件（将其与当前或旧数据混合），但是您只能select使用整个zvol，因为它就像一个非常大的文件（理论上，你可以复制字节范围并自己合并，但是这样做会很不方便）。 除了数据（文件与块）的这个“视图”，行为是一样的。
查看zpool import -T选项。 当心：这是在游泳池，而不是zvol。 也许你可以把你的zvol发送到一个新的zpool中，并使用import -T来导入它使用不同的txg。