我有一个ZFS镜像池，共有四个驱动器。 其中两个驱动器旨在用于旋转异地备份。 我的期望是，在初始重新启动之后，我可以detach并随后attach一个磁盘，并且只做一个增量重新启动 – 但是在testing中，无论被连接的磁盘是否已经包含了几乎所有的池内容。
如果使用offline / online方式，只会给我更新磁盘所需的结果 – 而不是完全重build它？ 或者如预期的那样进行这项工作，我需要做一些完全不同的事情 – 例如将每个备份磁盘用作单磁盘池，并在需要更新时将最新的快照send给它。
不要走破碎的ZFSarrays来“旋转”磁盘异地。 如您所见，重build时间很长，重新同步过程将读取/validation数据集的已用大小。
如果你有能力，快照和发送数据到远程系统是一个干净的，非侵入性的方法。 我想你可以通过一个专用的单磁盘池的过程，复制到它，和zpool导出/导入…但它不是很优雅。
经过进一步的实验，我find了一个公平的解决scheme，但它带来了一个重大的权衡。 已offline但未脱离的磁盘稍后可以恢复联机，并且只执行增量重新同步操作（“ 当设备联机时，已写入池的任何数据将与新近可用的设备重新同步。 ”） 。 在我的testing中，这将3个镜像的镜像从28小时缩短到30分钟左右，大约有40GB的数据增量。
权衡是任何具有脱机磁盘的池都会被标记为降级。 如果仍然有至less两个在线磁盘（在镜像池中），这实际上是一个警告 – 完整性和冗余保持不变。
正如其他人提到的，这种总体方法远非理想 – 将快照发送到远程池将更合适，但在我的情况下是不可行的。
总而言之，如果您需要从池中删除磁盘，然后将其添加回来，而不需要完全重新同步，那么我build议的方法是：
zpool offline pool disk ： zpool offline pool disk hdparm -Y /dev/thedisk zpool online pool disk 而且，由于这还没有经过testing，因此存在delta重叠操作不准确的风险。 “活动”池和/或脱机磁盘可能会遇到问题。 如果这发生在我身上，我会更新，但现在将尝试这种方法。
2015年10月15日更新 ：今天，我发现了zpool split命令，该命令将现有池中的新池（使用新名称）分开。 split比offline和detach要干净得多，因为这两个池可以在同一个系统上存在（并单独清理）。 在从系统中拔出之前，新的池也可以干净地（并正确地） export[ed] 。
（我原来的post如下。）
警告！ 在这个页面上的各种意见意味着它是（或可能） zpool detach一个驱动器，然后以某种方式重新连接驱动器，并访问它所包含的数据。
但是，根据这个线程 （和我自己的实验） zpool detach从分离的驱动器中删除“池信息”。 换句话说， detach就像是快速重新格式化驱动器 。 detach很多数据仍可能在驱动器上，但实际上不可能重新装入驱动器并将数据视为可用的文件系统。
因此，在我看来， detach比destroy更具破坏性，因为我相信zpool import可以恢复被破坏的池！
detach 不是 umount ， 也不是zpool export ， 也不是zpool offline 。
在我的实验中，如果我第一次zpool offline设备，然后zpool detach相同的设备，其余的池忘记设备曾经存在。 但是，由于设备本身在detach[ed]之前是offline[d] detach[ed] ，设备本身从未被通知detach 。 因此，设备本身仍然有其池信息，可以移动到另一个系统，然后import[ed] （处于降级状态）。
为了增加防detach保护，您甚至可以在offline命令之后物理拔出设备，但在发出detach命令之前。
我希望offline使用，然后detach ，然后import过程来备份我的池。 就像原来的海报一样，我计划使用四个驱动器，两个使用恒定镜像，另外两个使用每月，旋转，非现场（和离线）备份。 我将通过在单独的系统上导入和擦除备份来validation每个备份，然后再将其传输到现场。 不像原来的海报，我不介意每个月重写整个备份驱动器。 事实上，我更喜欢彻底重写，以获得新鲜的一点。
在同一台机器上，你有没有尝试用镜像中的2个驱动器创build一个新的池？ 接下来，在您的工作池上创build快照，然后将该快照发送到新池，重复，然后下一个快照发送将是增量。 这与“将数据发送到远程系统”不同，因为这是同一个系统/服务器/机器中的池。 使用此设置，仍然可以应用zpool split / offline / detach / attach，但只能在第二个（副本）池中执行，而不能在源池中执行。