Início / unix / Perguntas / 467001
Accepted
fadedbee
Asked: 2018-09-06 04:17:30 +0800 CST

Como impedir que as pessoas perturbem um conjunto de dados ZFS que é usado apenas para receber?

  • 772

Eu tenho duas máquinas, "remetente" e "receptor".

O remetente executa o seguinte comando todas as noites:

zfs send -i bpool/backups@2018-09-04 bpool/backups@2018-09-05 | ssh receiver /sbin/zfs receive bpool/backups

O envia o último de bpool/backups do remetente para o destinatário. (As datas são geradas automaticamente a cada noite.)

Se alguém (no receptor) fizer tão pouco quanto:

cd /bpool/backups
ls

ele interrompe o trabalho de backup noturno, com o seguinte erro:

root@sender:~# zfs send -i bpool/backups@2018-09-04 bpool/backups@2018-09-05 | ssh recevier /sbin/zfs receive bpool/backups
cannot receive incremental stream: destination bpool/backups has been modified
since most recent snapshot
warning: cannot send 'bpool/backups@2018-09-04': Broken pipe

(Suponho que isso seja por causa de tempos atualizados ou semelhantes.)

Como posso impedir que isso aconteça? (Se eu tornasse receiver:/bpool/backups somente leitura, como o recebimento funcionaria?)

zfs

4 respostas

  1. Best Answer

    zfs recv -Fforçará o conjunto de dados de recebimento a reverter para o instantâneo recebido anterior. Desativar o atime só resolverá o problema de pessoas examinando os arquivos no backup, mas se houver outras alterações, você desejará usar o sinalizador -F.

    • 4

  2. Desativar a atualização do tempo de acesso deve ser suficiente:

    zfs set atime=off bpool/backup
    • 3

  3. Você pode, de fato, definir seu conjunto de dados de destino como somente leitura (definindo a propriedade zfs readonly=ondiretamente no conjunto de dados de destino ou em um de seus pais). Isso não impedirá você de receber instantâneos mais recentes, porque readonlypara um conjunto de dados significa apenas que você não pode fazer alterações nos arquivos (, diretórios e atributos) dentro.

    Isso é diferente da configuração readonly=onquando você importa um pool. Com um pool readonlysignifica que o IO não pode gravar nada no back-end do pool.

    Eu, pelo menos, não estou muito feliz com a resposta aceita, porque simplesmente por princípio, ninguém deve fazer nenhuma alteração em um conjunto de dados que deve receber apenas de qualquer maneira.

    Outra razão pela qual sou contra a -Fopção é que, quando você recebe dados de instantâneos incrementais ( zfs send -i data@older-snap data@newer-snap), a -Fopção também resulta na exclusão de instantâneos do conjunto de dados de backup que também não existem no conjunto de dados de origem (embora apenas os mais recentes). É sempre bom projetar seus serviços para que eles falhem (e relatem erros) quando encontrarem algo inesperado (em vez de apenas ignorar erros).

    Para um conjunto de dados/pool de backup, você também pode querer definir atime=off, porque isso também contradiz sua finalidade.

    Edit: Ah e deve-se acrescentar que você pode manter essas propriedades definidas apenas no conjunto de dados de recebimento (que seria substituído caso fossem definidas diretamente no conjunto de dados de origem) usandozfs receive -o atime=off -o readonly=on

    • 2

  4. Pessoalmente, prefiro montar diretamente os instantâneos como somente leitura, dessa forma nem modificamos os instantâneos por construção.

    Se você estiver em um conjunto de dados criptografado, primeiro execute os seguintes comandos para carregar as chaves:

    $ sudo zfs load-key -a

    Depois é só montá-lo, por exemplo da seguinte forma (sem necessidade de -o roopções):

    $ mkdir /tmp/zp
$ sudo mount -t zfs zpool_my_passport/backup/2020_Dell_laptop@2021_01_05_-_test_update /tmp/zp/

    Mas se acontecer uma modificação, de fato zfs recv -Fé realmente prático (tenho um pouco de medo de ter perda de dados -F, por isso prefiro esse método).

    • 0

relate perguntas