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?

— MADforFUNandHappy
source

Le fameux quasi-catastrophe de KDE de 2013 est un peu pertinent ici.

— Iwillnotexist Idonotexist

Et méfiez-vous des clones locaux, git essaie d'utiliser des liens physiques lorsque vous créez un clone sur le même système de fichiers. Cela rend le clonage incroyablement rapide, mais si un objet est corrompu, les deux clones le sont.

— allo

Notez que si la corruption ne se produit que pour certains objets anciens sur une machine donnée, ces objets sont plus susceptibles d'être présents sur d'autres clones du référentiel, alors que les fichiers (moins nombreux) les plus récents pourraient encore être utilisables. Je n'ai aucune idée de la façon dont cela s'intègre aux fichiers de pack, cependant.

— o11c

Réponses:

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.

— lourd
source

Pourquoi est-ce que ça a fscktoujours l'air d'être un mauvais mot pour moi ... Je suppose que si cela s'avère positif et que vous n'avez pas de sauvegarde qui pourrait être appropriée cependant;)

— CAD97

@ CAD97 Les programmeurs sont connus pour ces jeux de mots relativement boiteux. C'est assez courant en fait ... Au sommet de ma tête, vous avez des choses comme sh (shell), bsh (Bourne shell), puis bash (Bourne again shell) ... le dernier étant le jeu de mots boiteux ...

— Nelson

@Nelson n'oubliez pas le poisson

— user253751 Le

@ CAD97 Hell, le nom de git lui-même peut être considéré comme alors il ne fonctionne pas correctement pour vous.

— SGR

@ CAD97 - et c'est avant que vous l'exécutiez avec des indicateurs tels que fvcctk - car - si vous l'exécutez ainsi, vos données peuvent déjà être "fvcctk". ;)

— Joe

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.

— Jonas Schäfer
source

Pas besoin d'aller en miroir si vous ne voulez pas. ZFS prend en charge la segmentation avec une parité de 1, 2 ou 3 disques; et la mise en miroir avec un nombre arbitraire de lecteurs (y compris un seul lecteur = aucune redondance). Mon stockage en masse principal est ZFS avec six disques dans une configuration RAIDZ2, qui est essentiellement un système de fichiers RAID6 (redondance au niveau du système de fichiers). Cela permet de détecter et de récupérer de la perte de l’un de ces disques, ainsi que des erreurs non corrigibles sur un disque supplémentaire; ou la perte de deux lecteurs et aucune erreur ailleurs lors de la récupération; sans aucune perte de données. Les sauvegardes sont toujours recommandées.

— un CVn

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é.

— AnoE
source