Git impedisce il degrado dei dati

Ho letto che ZFS e Btrfs usano i checksum per prevenire il degrado dei dati e ho letto che Git ha integrità attraverso l'hash essenzialmente tutto con ogni commit.

Stavo per usare un server Git su un NAS Linux con Btrfs RAID 1 per l'archiviazione, ma se Git ha integrità immagino che ciò non sarebbe necessario (almeno non se prevenire il degrado dei dati è tutto ciò che voglio).

Domanda: Quindi l'integrità di Git, sebbene l'hash sia essenzialmente tutto con ogni commit, impedisce o aiuta contro il bit-rot?

— MADforFUNandHappy
fonte

Il famoso quasi disastro di KDE del 2013 è piuttosto rilevante qui.

— Iwillnotexist Idonotexist,

E attenzione ai cloni locali, git cerca di usare hard link quando si crea un clone sullo stesso filesystem. Ciò rende la clonazione incredibilmente veloce, ma se un oggetto viene danneggiato entrambi i cloni vengono danneggiati.

— allo

Si noti che se la corruzione si verifica solo per alcuni oggetti antichi su una determinata macchina, è più probabile che tali oggetti siano presenti su altri cloni del repository, mentre i (meno) file più recenti potrebbero essere ancora utilizzabili. Non ho idea di come questo si integri con i file pack, però.

— o11c,

Risposte:

L'hash di Git si verifica solo nel momento in cui vengono creati i commit, e da lì in poi gli hash vengono utilizzati per identificare i commit. Ciò non garantisce in alcun modo l'integrità dei file. I repository Git possono essere danneggiati e perdere dati. In effetti, git ha un comando integrato per rilevare questo tipo di perdita, git fsck , ma come dice la documentazione, sei responsabile del ripristino dei dati danneggiati dai backup.

— heavyd
fonte

Perché mi sembra fscksempre una parolaccia ... Suppongo che se risulti positivo e non hai un backup che potrebbe essere appropriato;)

— CAD97

@ CAD97 I programmatori sono noti per questi giochi di parole relativamente scadenti. In realtà è abbastanza comune ... Dalla parte superiore della mia testa, hai cose come sh (shell), bsh (Bourne shell) e poi bash (Bourne again shell) ... l'ultimo è il gioco zoppo ...

— Nelson,

@Nelson non dimenticare il pesce

— user253751

@ CAD97 Inferno, il nome di git stesso può essere considerato come allora quando non funziona bene per te.

— SGR,

@ CAD97 - e questo prima di eseguirlo con flag come fvcctk - perché - se lo stai eseguendo in questo modo, i tuoi dati potrebbero già essere "fvcctk" ed. ;)

— Joe,

Dipende da cosa intendi per "prevenire".

(Prima di tutto, bit-rot è un termine con più definizioni. Questa domanda non riguarda il fatto che il codice diventi irrefrenabile a causa della mancanza di manutenzione .)

Se intendi "prevenire" che probabilmente rileverà la corruzione per decadimento dei bit, sì, funzionerà. Tuttavia non aiuterà a correggere tale corruzione: gli hash forniscono solo il rilevamento degli errori, non la correzione .

Questo è generalmente ciò che si intende per "integrità": la possibilità di rilevare manipolazioni non autorizzate / non intenzionali dei dati, non la possibilità di prevenirli o correggerli.

Generalmente vorresti comunque un RAID1 insieme ai backup (possibilmente implementato con snapshot ZFS o simili, non ho familiarità con la semantica ZFS su RAID1 + snapshot), per diversi motivi:

se un disco si guasta fatalmente, è necessario un RAID1 (o un backup recente) per ripristinare i dati; nessuna correzione degli errori può correggere l'errore di un intero disco, a meno che non abbia una copia completa dei dati (RAID1). Per un breve periodo di inattività, è necessario disporre essenzialmente di RAID1.
se si eliminano accidentalmente parti o tutto il repository, è necessario un backup (RAID1 non ti protegge poiché riflette immediatamente la modifica a tutti i dispositivi)

RAID1 a livello di blocco (ad es. Tramite LVM o simili) con solo due dischi in sé non ti proteggerà dal decadimento silenzioso dei dati: il controller RAID non può sapere quale dei due dischi contiene i dati corretti. Per questo sono necessarie ulteriori informazioni, ad esempio un checksum sui file. È qui che entrano in gioco i checksum ZSF e btrfs: possono essere usati (il che non vuol dire che sono usati in questi casi, non so come ZFS o btrfs gestiscano le cose lì) per distinguere quale dei due dischi contiene i dati corretti.

— Jonas Schäfer
fonte

Non c'è bisogno di andare con il mirroring se non vuoi. ZFS supporta lo striping con parità di 1, 2 o 3 unità; e il mirroring con un numero arbitrario di unità (inclusa una singola unità = nessuna ridondanza). Il mio principale archivio di massa è ZFS con sei unità in una configurazione RAIDZ2, che è fondamentalmente RAID6 a livello di file system (striping con ridondanza di due unità). Questo può rilevare e recuperare dalla perdita di una di quelle unità più errori non correggibili su un'altra; o la perdita di due unità e nessun errore altrove durante il resilver; senza alcuna perdita di dati. I backup sono ancora consigliati.

— un CVn il

impedire il bit-rot

No, non lo è affatto. Non esiste ridondanza simile a RAID introdotta da git. Se i file nella tua .gitdirectory soffrono di bit-rot, perderai roba come al solito.

aiuto contro il bit-rot?

Aaaa ... no. Non aiuta a prevenire il bit-rot, ma aiuterà a rilevare il bit-rot. Ma in nessun momento durante il normale utilizzo lo fa per proprio conto (ovviamente lo fa quando si estraggono alcuni oggetti e così via, ma non per la cronologia). Dovresti creare cron job per ricalcolare gli hash dal contenuto e confrontarli con gli hash effettivi. È abbastanza banale farlo, poiché gli githash sono letteralmente semplicemente gli hash di contenuto, è banale ricalcolarli e git fsckfarlo per te. Ma quando rileva bit-rot, non c'è nulla in particolare che possa fare contro di esso. In particolare, poiché i blocchi più grandi vengono compressi automaticamente, è probabile che si verifichi una perdita totale del blocco se viene capovolto un bit in un oggetto più grande.

— Anoe
fonte