Git empêche-t-il la dégradation des données?

J'ai lu que ZFS et Btrfs utilisent des sommes de contrôle pour empêcher la dégradation des données et que Git est intègre en hachant essentiellement tout ce qui se passe avec chaque commit.

J'allais utiliser un serveur Git sur un NAS Linux avec Btrfs RAID 1 pour le stockage, mais si Git est intègre, je suppose que cela ne serait pas nécessaire (du moins si la prévention de la dégradation des données est tout ce que je veux).

Question: L’intégrité de Git a-t-elle donc pour but de prévenir ou d’aider à lutter contre la pourriture des bits?

Le hachage de Git ne se produit que lorsque les commits sont créés, et à partir de là, les hachages sont utilisés pour identifier les commits. Cela ne garantit en aucun cas l'intégrité des fichiers. Les dépôts Git peuvent être corrompus et perdre des données. En fait, git a une commande intégrée pour détecter ce type de perte, git fsck , mais comme le dit la documentation, vous êtes responsable de la restauration des données corrompues à partir des sauvegardes.

Cela dépend de ce que vous entendez par "prévenir".

(Tout d’abord, bit-rot est un terme avec plusieurs définitions. Cette question ne concerne pas le fait que le code devienne illisible par manque de maintenance .)

Si vous entendez par "empêcher" qu'il détectera probablement la corruption par décroissance de bits, oui, cela fonctionnera. Cela ne va toutefois pas aider à réparer cette corruption: les hachages fournissent uniquement une détection d' erreur , pas une correction .

C'est généralement ce que l'on entend par "intégrité": la possibilité de détecter des manipulations de données non autorisées / non intentionnelles, et non la possibilité de les empêcher ou de les corriger.

Vous voudriez généralement toujours un RAID1 avec des sauvegardes (éventuellement implémenté avec des instantanés ZFS ou similaires, je ne suis pas familier avec la sémantique ZFS sur les instantanés RAID1 +), pour plusieurs raisons:

• si un disque tombe fatalement, vous avez besoin d’un RAID1 (ou d’une sauvegarde récente) pour restaurer vos données; aucune correction d'erreur ne peut corriger un disque entier en panne, à moins que celui-ci ne dispose d'une copie complète des données (RAID1). Pour un court temps d'arrêt, vous devez avoir essentiellement RAID1.

• si vous supprimez accidentellement des parties ou la totalité du référentiel, vous avez besoin d'une sauvegarde (RAID1 ne vous protège pas car il reflète immédiatement la modification apportée à tous les périphériques).

Un RAID1 au niveau des blocs (par exemple via LVM ou similaire) avec seulement deux disques ne vous protégera pas contre la dégradation silencieuse des données: le contrôleur RAID ne peut pas savoir lequel des deux disques contient les données correctes. Vous avez besoin d'informations supplémentaires pour cela, comme une somme de contrôle sur les fichiers. C’est là que les sommes de contrôle ZSF et btrfs entrent en jeu: elles peuvent être utilisées (ce qui ne veut pas dire qu’elles sont utilisées dans ces cas, je ne sais pas comment ZFS ou btrfs gèrent les choses là-bas) pour distinguer lequel des deux disques est valable. les données correctes.

prévenir le bit-rot

Non, pas du tout. Il n’ya pas de redondance de type RAID introduite par git. Si les fichiers de votre .gitrépertoire souffrent de la pourriture, vous perdrez des choses comme d'habitude.

aider contre peu-pourriture?

Yyyy ... non. Cela n’aide pas à prévenir la pourriture des bits, mais il aidera à détecter la pourriture des bits. Mais à aucun moment lors d'une utilisation normale, il ne le fait par son propre compte (bien évidemment, il le fait lorsque vous extrayez des objets, etc., mais pas pour votre historique). Vous devez créer des tâches cron pour recalculer les hachages du contenu et les comparer aux hachages réels. Il est assez gitsimple de le faire, car les hachages sont littéralement des contenus, il est donc trivial de les recalculer et le git fsckfait pour vous. Mais quand il détecte le bit-rot, il n'y a rien de particulier qu'il puisse faire contre. Plus précisément, étant donné que les plus gros morceaux sont automatiquement compressés, vous perdrez probablement beaucoup de morceaux si un bit d'un objet plus grand est retourné.