Tanto quanto eu sei, não.
'zpool copies' cria bits redundantes como você sabe, e se bem me lembro, é preciso tentar empurrar os bits redundantes o mais longe possível geograficamente, mas não acredito que seja um disco rígido & requisito rápido como é para os bits espelhados em um espelho vdev; restrições de espaço, outras peças em movimento poderia acreditar levar a um cenário em que a cópia # 2 ainda está no mesmo disco. Se isso acontecer uma vez, perder uma unidade de tal configuração seria um problema, retenção de dados.
Também não é algo que os comandos administrativos do pool sejam projetados para tratar da mesma maneira que tratariam os vdevs espelhados. Nem é algo que o fluxo de trabalho do ZFS foi projetado para tratar da mesma maneira que o espelhado ou paridade vdevs - se você perdeu um disco de um pool que tinha vários discos como vdevs de nível superior, mesmo se você tivesse cópias = 2 ou superior definido desde o primeiro dia, eu esperaria que o ZFS se queixasse de maneira poderosa e possivelmente começasse a retornar erros para o acesso a dados.
Eu não esperaria que cópias = 2 (ou mais) funcionassem como RAID 1E. No entanto, se você criou várias partições em seus discos e as configurou nos vdevs espelhados apropriados, provavelmente poderá replicar a ideia do RAID 1E com o ZFS. Se você tivesse 3 unidades, cada uma com 2 partições, e configurasse o vdevs de espelho para que cada par de partições não fosse da mesma unidade, o pool resultante poderia sobreviver a uma única perda de disco. As características de desempenho de tal pool, no entanto, nunca foram exploradas ao meu conhecimento (eu suporia que elas seriam ruins).