ZFS: Espelho requerido no sistema de backup?

Question

Eu planejo fazer backup de alguns dos meus sistemas de arquivos para um servidor remoto via zfs send . O pool para o qual eu pretendo enviar os backups é exclusivamente configurado para os backups do meu sistema principal. Preciso ter um espelho de unidades no local remoto ou o zfs é inteligente o suficiente para corrigir erros na próxima chamada de zfs send ?

Para esclarecer: em casa eu tenho meu servidor principal no qual eu tenho duas unidades espelhadas como um pool zfs. Agora quero enviar os dados não substituíveis para um servidor externo que também executa um SO com zfs.

A questão é se eu também preciso de redundância no local externo.

Suponha que zfs scrub encontre um erro no local externo. O zfs send corrigiu o erro?

    

Answer 1

O documento sobre práticas recomendadas do ZFS no Solaris responde a essa pergunta:

A pool that is not created with ZFS redundancy (RAIDZ or mirror) can only report data inconsistencies. It cannot repair data inconsistencies. A pool created without ZFS redundancy is harder to manage because you cannot replace or detach disks in a non-redundant ZFS configuration.

Como zfs send/recv sobrescreve os dados (se os sinalizadores corretos forem usados), depende da sua situação se isso for uma preocupação. Por exemplo, se você transferir novos blocos a cada 5 minutos e seu pool principal morrer 2 minutos depois, a possibilidade de corrupção é muito menor do que quando o pool de backup é atualizado apenas uma vez por semana, mês ou até mais.

A disponibilidade de hardware também pode ser importante: e se seu disco de backup morrer (não há problema, você ainda tem o pool principal), mas não pode substituí-lo por um dia, então vários backups planejados falharão agora? A redundância também ajuda no nível do hardware, não apenas na integridade dos dados. Claro, isso não importa muito se você tiver duas outras máquinas configuradas que continuam a funcionar.

Uma alternativa para casos de uso especiais (apenas um disco possível devido a restrições de espaço ou porta, tamanho do conjunto menor que a metade do tamanho máximo do disco) pode ser definir copies=2 para o pool de backup. Dessa forma, os dados são duplicados internamente no pool de backup (exigindo 200% de espaço) e fornecem integridade de dados, mas uma falha de hardware ainda destruirá seu pool de backup. Pode, no entanto, ser útil para um armazenamento de backup externo longo, em que apenas discos únicos são possíveis ou para sistemas menores. Observe que ele não funciona para dados existentes, portanto, é necessário um backup completo posteriormente.

Além disso, uma palavra de aviso do guia vinculado:

If you store ZFS send stream on a file or on tape, and that file becomes corrupted, then it will not be possible to receive it, and none of the data will be recoverable.

Isso significa que, a menos que você tenha boas razões para isso, use send em combinação com receive , pois somente os pools importados ativos podem ser verificados quanto à corrupção. Se você quiser apenas armazenar o fluxo (por exemplo, se um pool de destino deve conter vários fluxos ao mesmo tempo), sugere-se usar zstreamdump para verificar a integridade.

    

Answer 2

Você não precisa ter um espelho, mas isso aumentará a confiabilidade dos dados armazenados no pool.

O ZFS não corrigirá erros se não houver redundância para os dados afetados. O próprio disco lida com blocos defeituosos, substituindo-os internamente, então, nesse sentido, sim, enviar novamente um pool irá "consertar" o problema. Eu não apostaria muito nisso e substituiria um disco com erros recorrentes.

Note que o disco não irá descobrir por si só setores defeituosos, você precisa lê-los. O comando zpool scrub foi projetado para varrer um pool do zfs por erros.