Verhindert Git Datenverschlechterung

8037
MADforFUNandHappy

Ich habe gelesen, dass ZFS und Btrfs Prüfsummen verwenden, um eine Datenverschlechterung zu verhindern , und ich habe gelesen, dass Git Integrität hat, indem im Wesentlichen alles mit jedem Commit gehasht wird.

Ich wollte einen Git-Server auf einem Linux-NAS mit Btrfs-RAID 1 für die Speicherung verwenden, aber wenn Git Integrität hat, wäre dies wahrscheinlich nicht erforderlich (zumindest nicht, wenn das Verhindern von Datenverschlechterung alles ist, was ich möchte).

Frage: Also verhindert Gits Integrität, obwohl er mit jedem Commit im Wesentlichen alles hash, gegen Bit-rot?

40
Das berühmte KDE (Fast-Desaster 2013) (http://jefferai.org/2013/03/29/distillation/) ist hier [etwas relevant.] (Http://www.h-online.com/open/) news / item / KDE-eng-vermeidet-Desaster-1829776.html) Iwillnotexist Idonotexist vor 7 Jahren 10
Und vor lokalen Klonen sollte git versuchen, feste Links zu verwenden, wenn Sie einen Klon im selben Dateisystem erstellen. Das macht das Klonen unglaublich schnell, aber wenn ein Objekt beschädigt wird, sind beide Klone beschädigt. allo vor 7 Jahren 3
Wenn die Beschädigung nur für einige alte Objekte auf einer bestimmten Maschine auftritt, sind diese Objekte mit größerer Wahrscheinlichkeit auf anderen Klonen des Repos vorhanden, während die (weniger) neueren Dateien möglicherweise noch verwendbar sind. Ich habe jedoch keine Ahnung, wie sich dies in Pack-Dateien integrieren lässt. o11c vor 7 Jahren 0

3 Antworten auf die Frage

62
heavyd

Git-Hashing geschieht nur zu dem Zeitpunkt, zu dem Commits erstellt werden, und von dort aus werden die Hashes zum Identifizieren der Commits verwendet. Dies stellt keinesfalls die Integrität der Dateien sicher. Git-Repos können beschädigt werden und Daten verlieren. Git hat zwar einen integrierten Befehl zum Erkennen dieser Art von Verlust, git fsck, aber wie in der Dokumentation heißt, sind Sie für die Wiederherstellung beschädigter Daten aus Sicherungen verantwortlich.

Warum sieht "fsck" für mich immer nach einem schlechten Wort aus ... Ich denke, wenn es positiv erscheint und Sie keine geeignete Sicherung haben;) CAD97 vor 7 Jahren 4
@ CAD97 Programmierer sind für diese relativ lahmen Wortspiele bekannt. Eigentlich ist es ziemlich üblich ... Von meinem Kopf aus haben Sie Dinge wie sh (shell), bsh (Bourne shell) und dann bash (wieder Bourne shell) ... der letzte ist das lame Wortspiel ... Nelson vor 7 Jahren 7
@Nelson, Fisch nicht vergessen user20574 vor 7 Jahren 1
@ CAD97 Verdammt, der Name von git selbst kann so angesehen werden, als wenn er nicht richtig funktioniert. SGR vor 7 Jahren 0
@ CAD97 - und das ist, bevor Sie es mit Flags wie fvcctk ausführen - weil - wenn Sie es so ausführen, sind Ihre Daten möglicherweise bereits "fvcctk". ;) Joe vor 7 Jahren 1
16
Jonas Schäfer

Kommt drauf an was du mit "verhindern" meinst.

(Zuallererst ist Bit-Rot ein Begriff mit mehreren Definitionen. Bei dieser Frage geht es nicht darum, dass Code aufgrund mangelnder Wartung nicht lauffähig ist .)

Wenn Sie mit "verhindern" meinen, dass Korruption wahrscheinlich durch Zerfall von Bits erkannt wird, funktioniert dies. Es hilft jedoch nicht, diese Beschädigung zu beheben: Die Hashes bieten nur eine Fehlererkennung, keine Korrektur .

Im Allgemeinen ist dies mit "Integrität" gemeint: Die Möglichkeit, unbefugte / unbeabsichtigte Manipulationen von Daten zu erkennen, nicht die Möglichkeit, dies zu verhindern oder zu korrigieren.

Im Allgemeinen möchten Sie immer noch ein RAID1 zusammen mit Sicherungen (möglicherweise mit ZFS-Snapshots oder ähnlichem implementiert, ich bin mit der ZFS-Semantik von RAID1 + Snapshots nicht vertraut), und zwar aus mehreren Gründen:

  • Fällt ein Datenträger fatal aus, benötigen Sie entweder ein RAID1 (oder ein aktuelles Backup), um Ihre Daten wiederherzustellen. Keine Fehlerkorrektur kann den Ausfall einer ganzen Festplatte korrigieren, es sei denn, sie verfügt über eine vollständige Kopie der Daten (RAID1). Für eine kurze Ausfallzeit benötigen Sie grundsätzlich RAID1.

  • Wenn Sie versehentlich Teile oder das gesamte Repository löschen, benötigen Sie eine Sicherungskopie (RAID1 schützt Sie nicht, da die Änderung sofort für alle Geräte gilt).

RAID1 auf Blockebene (z. B. über LVM oder Ähnliches) mit nur zwei Festplatten an sich schützt Sie jedoch nicht vor Datenverlust im Hintergrund: Der RAID-Controller kann nicht wissen, auf welcher der beiden Festplatten sich die korrekten Daten befinden. Dazu benötigen Sie zusätzliche Informationen, wie eine Prüfsumme über Dateien. Hier werden die ZSF und Btrfs Prüfsummen kommen: sie verwendet werden können (was nicht heißt, dass sie sich in diesen Fällen verwendet werden, ich weiß nicht, wie ZFS oder Btrfs Dinge behandeln dort) zu unterscheiden, welche der beiden Scheiben hält die korrekten Daten.

Keine Notwendigkeit, mit Spiegeln zu gehen, wenn Sie nicht möchten. ZFS unterstützt das Striping mit 1, 2 oder 3 Laufwerken. und Spiegeln mit einer beliebigen Anzahl von Laufwerken (einschließlich eines einzelnen Laufwerks = keine Redundanz). Mein größter Massenspeicher ist ZFS mit sechs Laufwerken in einer RAIDZ2-Konfiguration, bei der es sich im Wesentlichen um RAID6 auf Dateisystemebene handelt (Striping mit Redundanz von zwei Laufwerken). Dies kann den Verlust eines dieser Laufwerke sowie nicht korrigierbare Fehler auf einem weiteren Laufwerk erkennen und beheben. oder der Verlust von zwei Laufwerken und keine Fehler während des Resilvers; ohne Datenverlust. Backups werden weiterhin empfohlen. a CVn vor 7 Jahren 5
1
AnoE

Bitfäule verhindern

Nein, auf keinen Fall. Es gibt keine RAID-artige Redundanz, die von git eingeführt wurde. Wenn die Dateien in Ihrem .gitVerzeichnis unter Bit-Rot leiden, werden Sie wie gewohnt Sachen verlieren.

Hilfe gegen Bitfäule?

Yyyy ... nein. Es hilft nicht gegen Bitfäule, aber es hilft, Bitfäule zu erkennen. Dies geschieht jedoch während des normalen Gebrauchs zu keinem Zeitpunkt auf eigene Rechnung (naja, natürlich beim Auschecken von Objekten usw., aber nicht für Ihre Historie). Sie müssen Cron-Jobs erstellen, um die Hashes aus dem Inhalt neu zu berechnen und mit den tatsächlichen Hashwerten zu vergleichen. Es ist ziemlich trivial, dies zu tun, da gitHashes buchstäblich nur die Inhaltshashes sind. Es ist trivial, sie neu zu berechnen, und git fscktut dies für Sie. Wenn es aber Bit-rot erkennt, kann es nichts Bestimmtes dagegen tun. Da größere Blöcke automatisch komprimiert werden, ist es wahrscheinlich, dass ein Gesamtverlust auftritt, wenn ein Teil eines größeren Objekts umgedreht wird.

Verwandte Probleme