“Falha na verificação da chave do host” no comando znapzendzetup create

1

Apenas começando com znapzend , que compilou bem no Ubuntu 14.04 (a máquina fonte, desde a atualização para o Ubuntu 16.04). A máquina de destino é o Ubuntu 16.04 ('backupserver'). Eu configurei um par de chaves ssh sem senha com ssh-keygen / ssh-copy-id [destination] . Eu posso ssh backupserver sem senha muito bem. O problema é que znapzend parece não conseguir acessar o servidor de backup por algum motivo. O mbuffer está em /usr/bin/mbuffer em ambas as máquinas. Aqui está o meu comando znapzendzetup e a saída em execução na máquina de origem:

sudo znapzendzetup create --recursive --mbuffer=/usr/bin/mbuffer --tsformat='%Y-%m-%d-%H%M%S' SRC '1y=>1d' pool/Documents DST '1y=>1d' jon@backupserver:pool/Documents
Host key verification failed.
Host key verification failed.
*** WARNING: executable '/usr/bin/mbuffer' does not exist on jon@backupserver

*** backup plan: pool/Documents ***
dst_0           = jon@backupserver:pool/Documents
dst_0_plan      = 1year=>1day
*** WARNING: destination 'jon@backupserver:pool/Documents' does not exist, will be ignored! ***

enabled         = on
mbuffer         = /usr/bin/mbuffer
mbuffer_size    = 1G
post_znap_cmd   = off
pre_znap_cmd    = off
recursive       = on
src             = pool/Documents
src_plan        = 1year=>1day
tsformat        = %Y-%m-%d-%H%M%S

Do you want to save this backup set [y/N]?

Obrigado por qualquer insight que você possa fornecer!

UPDATE # 1

Estou recebendo também:

Host key verification failed.

ou

Permission denied the ZFS utilities must be run as root.

dependendo se eu executo znapzendzetup com sudo, ou se eu tiver --sudo no comando:

sudo znapzendzetup create ...

ou

znapzendzetup create --sudo ...

Eu adicionei esta linha ao / etc / sudoers (via visudo):

jon ALL=(ALL) NOPASSWD:ALL

E executou esta linha nas máquinas host e de destino:

sudo zfs allow -u jon create,mount,send,receive,snapshot,destroy pool/Documents

Posso tentar ativar o login raiz sem senha, mas entendo que isso é desencorajado. Obrigado por dar uma olhada!

UPDATE # 2

Eu habilitei o login root remoto sobre o ssh alterando estas linhas em / etc / ssh / sshd_confg na máquina de destino:

#PermitRootLogin prohibit-password
PermitRootLogin yes

Em seguida, na máquina de origem:

sudo passwd root
su
ssh-keygen
ssh-copy-id BACKUPSERVER

Os comandos znapzend agora funcionam como sudo e sem o argumento --sudo!

Em seguida, iniciei um comando znapzend com a saída abaixo:

jon@FILESERVER:~$ sudo znapzend --debug --runonce=pool/Documents
[Wed Apr 27 17:54:42 2016] [info] znapzend (PID=6388) starting up ...
[Wed Apr 27 17:54:42 2016] [info] refreshing backup plans...
[Wed Apr 27 17:54:42 2016] [info] found a valid backup plan for pool/Documents...
[Wed Apr 27 17:54:42 2016] [info] znapzend (PID=6388) initialized -- resuming normal operations.
[Wed Apr 27 17:54:42 2016] [debug] snapshot worker for pool/Documents spawned (6391)
[Wed Apr 27 17:54:42 2016] [info] creating snapshot on pool/Documents
# zfs snapshot pool/Documents@2016-04-27-175442
[Wed Apr 27 17:54:42 2016] [debug] snapshot worker for pool/Documents done (6391)
[Wed Apr 27 17:54:42 2016] [debug] send/receive worker for pool/Documents spawned (6393)
[Wed Apr 27 17:54:42 2016] [info] starting work on backupSet pool/Documents
# zfs list -H -o name -t snapshot -s creation -d 1 pool/Documents
[Wed Apr 27 17:54:42 2016] [debug] cleaning up snapshots on pool/Documents
# zfs destroy pool/Documents@2016-04-27-174027
[Wed Apr 27 17:54:43 2016] [info] done with backupset pool/Documents in 1 seconds
[Wed Apr 27 17:54:43 2016] [debug] send/receive worker for pool/Documents done (6393)

Parece ter sido executado com sucesso, mas até agora não fez backup do conjunto de dados para o destino ainda. Quando copia arquivos?

Além disso, apenas FYI, adicionei o znapzend como um serviço com:

sudo cp ~/znapzend-0.15.5/init/znapzend.service /etc/systemd/system
sudo chown root:root /etc/systemd/system/znapzend.service
systemctl enable znapzend.service
sudo systemctl enable znapzend.service
sudo systemctl start znapzend.service
sudo service znapzend status

Obrigado!

UPDATE # 3

Ok, eu tenho isso classificado agora. Eu não tinha a configuração de configuração para entrar com 'root' na máquina de destino, o que impedia o envio / recebimento para funcionar. Aqui está o meu comando znapzendzetup atualizado:

sudo znapzendzetup create --mbuffer=/usr/bin/mbuffer --tsformat='%Y-%m-%d-%H%M%S' SRC '7d=>1h,1y=>1d' pool/Documents DST '7d=>1h,1y=>1d' root@BACKUPSERVER:pool/Documents

O backup foi concluído com sucesso após:

sudo znapzend --debug --runonce=pool/Documents

Obrigado por essa excelente ferramenta de backup + snapshot do ZFS !!!

    
por joncl 25.04.2016 / 19:11

2 respostas

1

Tobi me apontou na direção certa (obrigado!). Minha solução foi habilitar o login de root sem senha sobre o ssh, o que provavelmente não é o ideal, mas estou em uma LAN doméstica, então tudo bem. O problema é que eu não consegui fazer com que um usuário não-root executasse comandos zfs com sudo sobre ssh por algum motivo, mesmo que o login ssh sem senha estivesse funcionando totalmente como aquele usuário não-root. 'znapzendzetup create --sudo ...' funcionaria, mas então 'znapzend --noaction --debug' deu: ' Permissão negada que os utilitários do ZFS devem ser executados como root ' por algum motivo (e não há uma opção --sudo para o comando znapzend, eu acho). Então eu configuro o login ssh como root ( UPDATE # 2 ). Para verificar, eu fiz:

sudo ssh BACUPSERVER 'zfs list'

Então eu tive que lembrar de mudar meu comando znapzendzetup para logar como root com (veja UPDATE # 3 ):

sudo znapzendzetup ... root@BACKUPSERVER:pool/Documents

Ontem à noite eu adicionei um intervalo de snapshot de '1w = > 30min' a todos os meus três conjuntos de dados, e hoje de manhã foi feito um backup perfeito do meu BACKUPSERVER. Nice!

    
por 28.04.2016 / 18:57
0

desde que você esteja usando sudo , presumo que as chaves que você configurou não são válidas para o usuário certo ... tente

sudo ssh backuphost ls

para verificar sua configuração

    
por 26.04.2016 / 15:51

Tags