Tamanho de envio estimado do ZFS muito maior que o tamanho total dos dados

Como tegbains apontou em um comentário, zfs sendos fluxos não se beneficiam de nenhuma desduplicação no nível de armazenamento. Eles também não se beneficiam de nenhuma outra configuração; é por isso que zfs send | zfs receivepode ser usado para migrar dados para novas configurações que, de outra forma, só entrariam em vigor quando os dados fossem reescritos - como habilitar ou desabilitar a desduplicação ou alterar os algoritmos de compactação.

Esta é a principal razão pela qual o fluxo de envio zfs se torna muito maior do que o espaço de armazenamento alocado. Uma razão provável para isso no caso específico da desduplicação, além do princípio da menor surpresa (se você precisar de uma), é que a desduplicação ( especialmente no ZFS) é muito cara e foi tomada a decisão de que os fluxos de envio zfs devem ser recebidos em taxas mais baixas sistemas especificados.

Seus dados mostram cerca de 2,36 TB alocados, com uma taxa de desduplicação geral de 2,87x. A multiplicação ingênua desses dois números resulta em 6,77 TB, que é próximo o suficiente dos 6,50 TB estimados para ser um valor aproximado razoável. Certamente vale a pena observar que o valor de 6,50 TB se refere a um instantâneo no sistema de arquivos, enquanto o valor de 2,36 TB*2,87 se refere a todo o pool.

Se a sua implementação do ZFS suportar essa opção, você pode ter sorte com zfs send -D(gerar fluxo de envio zfs desduplicado).

Observado com ZFS no Linux 0.6.1.

Não está diretamente relacionado à sua pergunta, mas sugiro atualizar. Stable ZoL está em 0.6.4.1 no momento em que este livro foi escrito (junho de 2015), e houve inúmeras melhorias e correções desde que a versão 0.6.1 foi lançada em março de 2013.