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 j'ai lu que Git est intègre en hachant essentiellement tout ce qui se passe avec chaque commit.
J'allais utiliser un serveur Git sous Linux NAS 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 empêcher 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 à prévenir le bit-rot?
Le hachage de Git ne se produit qu'au moment où 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 est not about le code devient infondable 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. Cependant pasaidera à corriger cette corruption): les hachages fournissent uniquement une erreur une détection, pas une correction .
C'est généralement ce que l'on entend par "intégrité": La possibilité de détecterla manipulation non autorisée/non intentionnelle de données, pas la possibilité de la prévenir ou de la 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 en soi pasvous protègera 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 de plus d'informations. informations pour cela, comme une somme de contrôle sur les fichiers. C’est là que les sommes de contrôle ZSF et btrfs entrent: elles peuvent être utilisées (ce qui ne veut pas dire qu’elles sontutilisées dans ces cas, je ne sais pas comment ZFS ou btrfs y gère les choses) pour distinguer lequel des deux disques contient 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 répertoire .git 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 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 simple de le faire, étant donné que les variables git sont littéralement de simples contenus, il est donc trivial de les recalculer et git fsck le fait 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 gros morceaux sont automatiquement compressés, vous perdrez probablement beaucoup de morceaux si un bit d'un objet plus grand est retourné.