传统数据迁移

传统文件迁移通常采用以下两种方式之一进行：反复同步或外部插入。

通过同步进行迁移

这种方法使用活动的主机 X 向新主机 Y 迁移数据，同时主机 X 仍然保持活动状态。在迁移过程中，客户机仍然对原始主机进行读写操作。在进行初次迁移后，将反复地发送增量更改数据，一直到增量数据少到足以在一个停机时段内发送完毕为止。此时，原始共享资源将变为只读状态，最后一部分增量数据将发送到新主机，而所有客户机将更新为指向该新位置。实现这种迁移的最常用方法是通过 rsync 工具，但是还有其他集成的工具可用。这种方法有几个缺点：

• 尽管预期的停机时间较短，但不易量化。如果用户在计划的停机时间即将到来之前提交了大量更改数据，将会延长停机时段。

• 在迁移期间，新服务器处于空闲状态。因为新服务器往往具备新的功能或性能上的改进，所以，这会在可能很长的迁移期间内造成资源浪费。

• 在多个文件系统之间协调的任务很繁重。在迁移数十个或数百个文件系统时，每次迁移都需要不同长短的时间，因此，必须在所有文件系统构成的联合体内计划好各自的停机时间。

通过外部插入进行迁移

这种方法使用活动的主机 X，并另外加入一个新 ZFSSA M，由后者将数据迁移到新主机 Y。所有客户机会立即更新为指向 M，而数据自动在后台进行迁移。这可以为迁移选项带来更多灵活性（例如，能够将来在不停机情况下向新服务器进行迁移），并可以利用新服务器来处理已迁移的数据，但也有一些显著的缺点：

• 迁移 ZFSSA 作为新的物理机，产生相关成本（初始投资、支持成本、供电和冷却等）及其他管理开销。

• 迁移 ZFSSA 成为系统中新的故障点。

• 迁移 ZFSSA 插入已迁移的数据，这样会产生额外的延迟，通常是永久性的。这些迁移 ZFSSA 通常需要持续运行，当然也可以为其另外计划停机时段并将其停用。