Como ter certeza de que o snapshot readonly 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 de calcular os checksums um no outro e armazená-lo para um exame mais detalhado, ou o BTRFS lida sozinho?

Fundamentação

Estou fazendo backup de meus instantâneos regularmente como uma prevenção para uma possível falha no disco. Dias atrás, não consegui criar btrfs send | btrfs receive para um instantâneo específico. Quando eu apaguei, o resto das operações foi normal. Além disso, btrfs scrub diz que há alguns erros incorrigíveis. Isso me fez pensar que meus instantâneos no disco principal podem estar corrompidos antes de fazer o backup deles no disco externo e, se eu não tiver conhecimento disso, acabaria com backups já corrompidos no disco externo.

Isso é o que eu estou tentando evitar que aconteça. Eu 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 uma falha de disco".

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

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

• Se o volume for montado com as opções nodatasum ou nodatacow , você não terá nenhuma soma de verificação dos blocos de dados. Na maioria dos casos, você não deve estar montando com essas opções, então isso não deve ser um problema.
• Todos os arquivos para os quais o atributo NOCOW está definido ( C na saída do comando lsattr ) também não são verificados. Não é provável que você tenha arquivos realmente importantes com esse conjunto de atributos (os arquivos de diário do systemd já definiram, mas isso é a menos que você os defina manualmente).

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

Você não pode proteger contra isso, exceto por ter outra cópia dos dados em algum lugar. Basicamente, se você perdeu mais dispositivos do que muitos perfis de armazenamento para o volume podem tolerar, seus dados se foram, e nada irá recuperá-lo para você, a não ser que restaure a partir de um backup.

Em relação ao seu caso específico

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

Neste caso, parece que os erros incorrigíveis estão inteiramente em dados exclusivos para instantâneos ou que não estão sendo instantâneos. Você pode facilmente (embora não muito rapidamente) descobrir quais arquivos estão tendo 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 no volume e você verá todos os erros de leitura no console, com o nome do arquivo na mensagem de erro. Isso é potencialmente muito lento, portanto, 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ê ver esses problemas acontecerem novamente em um futuro próximo após corrigi-los, você deve verificar seu hardware, pois algo está corrompendo dados em silêncio.