O Git evita a degradação dos dados

Eu li que o ZFS e o Btrfs usam somas de verificação para impedir a degradação dos dados e eu li que o Git tem integridade através do hash essencialmente tudo em cada commit.

Eu usaria um servidor Git em um NAS Linux com Btrfs RAID 1 para armazenamento, mas se o Git tiver integridade, acho que isso não seria necessário (pelo menos não se fosse para impedir a degradação dos dados).

Pergunta: Então, a integridade do Git, embora o hash de essencialmente tudo o que existe em cada commit, evita ou ajuda contra a podridão de bits?

— MADforFUNandHappy
fonte

O famoso quase desastre do KDE de 2013 é um pouco relevante aqui.

— Iwillnotexist Idonotexist

E cuidado com os clones locais, o git tenta usar links físicos quando você cria um clone no mesmo sistema de arquivos. Isso torna a clonagem incrível rapidamente, mas se um objeto for corrompido, os dois clones serão corrompidos.

— allo

Observe que se a corrupção ocorrer apenas para alguns objetos antigos em uma determinada máquina, é mais provável que esses objetos estejam presentes em outros clones do repositório, enquanto os (menos) arquivos mais recentes ainda poderão ser utilizados. Não tenho idéia de como isso se integra aos arquivos do pacote.

— o11c 28/09

Respostas:

O hash do Git acontece apenas no momento em que as confirmações são criadas e a partir daí as hashes são usadas para identificar as confirmações. Isso de forma alguma garante a integridade dos arquivos. Os repositórios Git podem ser corrompidos e perder dados. De fato, o git possui um comando interno para detectar esse tipo de perda, o git fsck , mas, como diz a documentação, você é responsável por restaurar os dados corrompidos dos backups.

— pesado
fonte

Por que fscksempre parece uma palavra ruim para mim ... Suponho que, se aparecer positivo, e você não tiver um backup que seja apropriado;))

— CAD97

@ CAD97 Os programadores são conhecidos por esses trocadilhos relativamente esfarrapados. Na verdade, é bastante comum ... No topo da minha cabeça, você tem coisas como sh (shell), bsh (Bourne shell) e depois bash (Bourne novamente shell) ... o último sendo o trocadilho coxo ...

— Nelson Nelson

@Nelson don't forget fish

— user253751 28/09

@ CAD97 Inferno, o nome do git em si pode ser considerado como quando não está funcionando direito para você.

— SGR 28/09

@ CAD97 - e isso é antes de você executá-lo com sinalizadores como fvcctk - porque - se você estiver executando assim, seus dados já podem estar "fvcctk" editados. ;)

— Joe

Depende do que você quer dizer com "impedir".

(Primeiro de tudo, bit-rot é um termo com várias definições. Esta questão não é sobre o código se tornar intransponível devido à falta de manutenção .)

Se você quer dizer com "impedir" que provavelmente irá detectar corrupção por decaimento de bits, sim, isso funcionará. No entanto, não ajudará a corrigir essa corrupção: os hashes fornecem apenas detecção de erro , não correção .

Geralmente, isso é o que se entende por "integridade": a possibilidade de detectar manipulação não autorizada / não intencional de dados, não a possibilidade de impedir ou corrigi-la.

Geralmente, você ainda deseja um RAID1 junto com backups (possivelmente implementado com instantâneos do ZFS ou similares, não estou familiarizado com a semântica do ZFS nos instantâneos do RAID1 +), por vários motivos:

se um disco falhar fatalmente, você precisará de um RAID1 (ou de um backup recente) para restaurar seus dados; nenhuma correção de erros pode corrigir a falha de um disco inteiro, a menos que tenha uma cópia completa dos dados (RAID1). Por um curto período de inatividade, você deve essencialmente ter o RAID1.
se você excluir acidentalmente partes ou todo o repositório, precisará de um backup (o RAID1 não o protege, pois reflete imediatamente a alteração em todos os dispositivos)

No entanto, o RAID1 em nível de bloco (por exemplo, via LVM ou similar) com apenas dois discos não protege contra a deterioração silenciosa dos dados: o controlador RAID não pode saber qual dos dois discos contém os dados corretos. Você precisa de informações adicionais para isso, como uma soma de verificação sobre arquivos. É aqui que entram as somas de verificação ZSF e btrfs: elas podem ser usadas (o que não significa que sejam usadas nesses casos, não sei como o ZFS ou btrfs lidam com as coisas lá) para distinguir qual dos dois discos contém os dados corretos.

— Jonas Schäfer
fonte

Não é necessário usar espelhamento, se você não quiser. O ZFS suporta striping com 1, 2 ou 3 unidades de paridade; e espelhamento com um número arbitrário de unidades (incluindo uma única unidade = sem redundância). Meu principal armazenamento em massa é o ZFS com seis unidades em uma configuração RAIDZ2, que é basicamente o RAID6 no nível do sistema de arquivos (com redundância no valor de duas unidades). Isso pode detectar e recuperar a perda de qualquer uma dessas unidades, além de erros incorrigíveis em mais uma; ou a perda de duas unidades e nenhum erro em outro lugar durante o resilver; sem perda de dados. Os backups ainda são recomendados.

— um CVn

evitar rot-bit

Não, de jeito nenhum. Não há redundância semelhante a RAID introduzida pelo git. Se os arquivos em seu .gitdiretório sofrerem uma podridão por bits, você perderá as coisas da mesma maneira.

ajuda contra a podridão de bits?

Yyyy ... não. Não ajuda a ocorrer a podridão de bits, mas ajuda a detectar a podridão de bits. Mas em nenhum momento durante o uso normal, ele faz isso por conta própria (obviamente faz isso quando você verifica alguns objetos e assim por diante, mas não para o seu histórico). Você precisaria criar tarefas cron para recalcular os hashes do conteúdo e compará-los aos hashes reais. É bastante trivial fazê-lo, como os githashes são literalmente simplesmente os hashes de conteúdo, é trivial recalculá-los e git fsckfaz isso por você. Mas quando detecta a podridão por bits, não há nada em particular que possa fazer contra isso. Especificamente, como pedaços maiores são compactados automaticamente, você provavelmente sofrerá perda total de pedaços se um pouco em um objeto maior for invertido.

— AnoE
fonte