Como ter certeza de que o instantâneo somente leitura não está corrompido no BTRFS?

Question

Como podemos ter certeza de que um instantâneo somente leitura não está corrompido devido a uma falha no disco?

A única maneira é calcular as somas de verificação umas sobre as outras e armazená-las para exame posterior, ou o BTRFS cuida disso sozinho?

Justificativa

Estou fazendo backup dos meus instantâneos regularmente como prevenção contra uma possível falha no disco. Dias atrás, não consegui tirar btrfs send | btrfs receiveum instantâneo específico. Quando o excluí, o restante das operações ocorreu normalmente. Além disso, btrfs scrubdiz que existem alguns erros incorrigíveis. Isso me fez pensar que meus instantâneos no disco primário poderiam estar corrompidos antes de fazer backup deles no disco externo e, se eu não soubesse disso, acabaria com backups já corrompidos no disco externo.

É isso que procuro evitar que aconteça. Quero ter certeza de que, se eu puder fazer backup de um instantâneo, ele não estará corrompido.

Answer 1

Existem duas respostas possíveis, dependendo do que você entende por 'corrompido por falha no disco'.

Se você quer dizer simples corrupção de dados em repouso

O BTRFS cuida disso sozinho, de forma transparente para o usuário. Ele verifica tudo internamente, incluindo dados em instantâneos, e depois verifica as somas de verificação à medida que lê cada bloco. Existem algumas exceções a isso:

• Se o volume for montado com as opções nodatasumou nodatacow, você não terá soma de verificação de blocos de dados. Na maioria dos casos, você não deve montar com essas opções, então isso não deve ser um problema.
• Quaisquer arquivos para os quais o NOCOWatributo esteja definido ( Cna saída do lsattrcomando) também não serão verificados. É provável que você não tenha nenhum arquivo realmente importante com esse conjunto de atributos (os arquivos de diário do systemd o têm definido, mas isso é tudo, a menos que você o defina manualmente).

Se você quer dizer destruição não trivial de dados no volume devido à perda de muitos dispositivos

Você não pode se proteger contra isso, exceto tendo outra cópia dos dados em algum lugar. Praticamente, se você perdeu mais dispositivos do que os perfis de armazenamento do volume podem tolerar, seus dados desaparecerão e nada irá recuperá-los para você, exceto a restauração de um backup.

---

Em relação ao seu caso específico

Os problemas dos quais você está falando com envio/recebimento são provavelmente um efeito colateral dos erros incorrigíveis relatados pelo scrub. Quando o BTRFS não consegue corrigir um erro de forma transparente (geralmente porque o bloco é armazenado usando um perfil que não pode fazer recuperação, como single ou raid0), ele retorna um erro de E/S, que fará com que a operação de envio falhe. Portanto, você não acabará com backups já corrompidos se estiver usando o envio/recebimento (e, na verdade, também não o fará com a maioria das outras ferramentas, qualquer bom software de backup gerará um erro se não conseguir ler um arquivo ).

Nesse caso, parece que os erros incorrigíveis estão inteiramente em dados exclusivos de instantâneos ou que não estão sendo capturados. Você pode facilmente (embora não muito rapidamente) descobrir quais arquivos estão apresentando problemas montando o volume de origem em algum lugar sozinho e executando o seguinte comando de onde ele está montado:

find . -exec cat '{}' \; > /dev/null

Isso tentará ler todos os arquivos do volume e você verá erros de leitura no console, com o nome do arquivo na mensagem de erro. Isso é potencialmente muito lento, então você pode querer paralelizá-lo se tiver um grande volume.

Depois de encontrar e lidar com esses arquivos, você não deverá ter mais problemas. Se você perceber que esses problemas acontecem novamente em um futuro próximo após corrigi-los, você deve verificar seu hardware, comoalgoestá corrompendo dados silenciosamente.