I could then manually replace it with a copy from the 2,5" backup drive before the backup is polluted with the corrupted version. Unfortunately I have read that ZFS doesn't appear to notify the user when it detects corrupted files during an automatic checksum calculation/comparison. So my idea isn't possible.
Na verdade, o ZFS (de certa forma) notifica o usuário sobre quaisquer erros encontrados em operações comuns. Ele faz isso, se os dados não puderem ser lidos ou não forem validados em relação à soma de verificação armazenada em outro lugar, causando um erro de E / S. Como isso se propaga para o software do usuário depende inteiramente de como esse software responde a um erro de E / S; no pior dos casos, pode simplesmente falhar; em um caso melhor, isso de alguma forma informaria que o arquivo não é legível.
what would be the best solution for protecting my data against bit rot with the gear I already own?
Se você quiser pelo menos uma proteção real parcial contra a podridão de bits com uma única unidade, defina copies=2 em seu pool. Observe que isso reduz a capacidade de armazenamento de forma eficaz e deve ser feito antes de armazenar os dados no pool. (Você também pode fazer com que essa configuração tenha efeito, reescrevendo os arquivos, copiando-os para um diretório separado e copiando-os de volta antes de excluir a segunda cópia.) É ainda melhor definir propriedades como checksum , copies , compression e assim por diante durante a criação do pool, se possível.
Com apenas uma única cópia e nenhum armazenamento redundante, o ZFS pode detectar, mas não reparar, a maioria dos erros no nível de armazenamento. (Os metadados são sempre armazenados com uma cópia adicional, portanto, se você tiver um único vdev pool sem redundância e copia = 1, você obtém duas cópias reais dos metadados críticos.) Para fazer isso, esfregue o pool executando sudo zpool scrub poolname . Se você precisar cancelar um scrub em execução, execute sudo zpool scrub poolname -s (o -s significa "stop"). Quando o scrub terminar, você pode obter uma lista de todos os arquivos afetados por erros no nível de armazenamento executando zpool status poolname -v , o que esperamos que imprima no known data errors . Você pode então decidir se deseja descartar esses arquivos ou restaurá-los a partir de backups. Observe que é possível executar o ZFS com checksum=off , o que desativa a soma de verificação. (A página de manual do zfs (8), entretanto, adverte que desabilitar checksums é NÃO uma prática recomendada , ênfase original.)
Você deve executar scrubs regularmente. O tempo que um scrub demora depende muito da quantidade de dados que você tem e de seus padrões de gravação (gravar arquivos grandes uma vez, que nunca são gravados novamente, é muito melhor nesse aspecto do que arquivos pequenos que são atualizados regularmente no local) devido à cópia do ZFS -on-write arquitetura, eventualmente, levando à fragmentação. Eu recomendo executar scrubs não menos do que a cada poucas semanas. Com algumas centenas de gigabytes de dados (com base em sua declaração que você usou para armazenar suas fotos na unidade de 500 GB), não deve mais do que algumas horas.
I don't want to wear down the backup drive unnecessarily
Geralmente, o que mata os HDDs de rotação magnética é o spin-up e a força física. Um disco rígido rotacional magnético não sofre de nada parecido com o desgaste do flash dos SSDs (que geralmente não é um problema com os SSDs modernos). >, de qualquer maneira). Tanto os HDDs como os SSDs são projetados e construídos para serem usados e, desde que sejam saudáveis, podem levar uma surra bastante proverbial. (É quando um HDD é marginal que você deve começar a se preocupar e copie seus dados o mais rápido possível.)