sudo zfs send tank/dana@snap1 | ssh sys2Root zfs recv newtank/dana
onde sys2root é uma entrada em ~ / .ssh / config, ou seja:
host sys2Root
HostName 192.168.0.x
User root
Editar :
Esta questão originalmente focada na questão de reverter a direção da conexão ssh na transferência, mas eu percebi que não era o que estava causando os problemas que eu enfrentei, então eu simplifiquei isso.
Embora a documentação do Ubuntu de zfs
apenas discuta o envio-recebimento via arquivo, essa abordagem é inviável com grandes conjuntos de dados. A documentação da Oracle recomenda usando ssh
no canal, ou seja,
# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
No entanto, ao tentar este procedimento com um conjunto de dados de teste que criei, contendo um único arquivo de 10M, me deparei com o problema de implementação do zfs
(ZFS-on-Linux) do Ubuntu Xenial que requer privilégios de root o lado de recepção):
$ sudo -i
# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
Permission denied the ZFS utilities must be run as root.
warning: cannot send 'tank/dana@snap1': Broken pipe
Eu tentei corrigir esse problema passando ssh
o -t
sinalizador, ou seja, emitindo
# zfs send tank/dana@snap1 | ssh -t sys2 "sudo zfs recv newtank/dana"
que falha com
Pseudo-terminal will not be allocated because stdin is not a terminal.
antes de pedir as credenciais de sys2
, após o que as seguintes mensagens são recebidas:
sudo: no tty present and no askpass program specified
warning: cannot send 'tank/dana@snap1': Broken pipe
Tentativa de realizar uma transferência de teste usando a outra direção, usando
# ssh -t sys2 "sudo zfs send newtank/dana2@snap1" | zfs recv tank/dana2
simplesmente trava depois de pedir as credenciais de sys2
. (Lembre-se, cada instantâneo contém apenas um arquivo de 10M, então acredito que ele não tente fazer nada, mas não sei por que ele trava.)
sudo zfs send tank/dana@snap1 | ssh sys2Root zfs recv newtank/dana
onde sys2root é uma entrada em ~ / .ssh / config, ou seja:
host sys2Root
HostName 192.168.0.x
User root