¿Git previene la degradación de datos?

Leí que ZFS y Btrfs usan sumas de verificación para evitar la degradación de datos y leí que Git tiene integridad a través del hashing esencialmente todo con cada confirmación.

Iba a usar un servidor Git en un NAS de Linux con Btrfs RAID 1 para el almacenamiento, pero si Git tiene integridad, supongo que esto no sería necesario (al menos no si lo único que quiero es evitar la degradación de datos).

Pregunta: Entonces, ¿la integridad de Git, aunque elimina todo esencialmente con cada confirmación, previene o ayuda contra la descomposición de bits?

— MADforFUNandHappy
fuente

El famoso desastre cercano a KDE de 2013 es algo relevante aquí.

— Iwillnotexist Idonotexist

Y tenga cuidado con los clones locales, git intenta usar enlaces duros cuando está creando un clon en el mismo sistema de archivos. Eso hace que la clonación sea increíblemente rápida, pero si un objeto se corrompe, ambos clones se corrompen.

— allo

Tenga en cuenta que si la corrupción solo se produce para algunos objetos antiguos en una máquina determinada, es más probable que esos objetos estén presentes en otros clones del repositorio, mientras que los (menos) archivos más recientes aún podrían ser utilizables. Sin embargo, no tengo idea de cómo se integra esto con los archivos de paquete.

— o11c

Respuestas:

El hash de Git solo ocurre en el momento en que se crean los commits, y a partir de ahí los hashes se usan para identificar los commits. Esto de ninguna manera garantiza la integridad de los archivos. Los repositorios de Git pueden corromperse y perder datos. De hecho, git tiene un comando incorporado para detectar este tipo de pérdida, git fsck , pero como dice la documentación, usted es responsable de restaurar los datos corruptos de las copias de seguridad.

— pesado
fuente

¿Por qué fscksiempre me parece una mala palabra? Supongo que si resulta positivo y no tienes una copia de seguridad que pueda ser apropiada;)

— CAD97

@ CAD97 Los programadores son conocidos por estos juegos de palabras relativamente poco convincentes. Es bastante común en realidad ... Fuera de mi cabeza, tienes cosas como sh (shell), bsh (Bourne shell) y luego bash (Bourne nuevamente shell) ... el último es el juego de palabras cojo ...

— Nelson

@ Nelson no te olvides de los peces

— user253751

@ CAD97 Demonios, el nombre de git en sí mismo puede considerarse como cuando no funciona bien para ti.

— SGR

@ CAD97, y eso es antes de que lo ejecute con marcas como fvcctk, porque si lo está ejecutando de esa manera, es posible que sus datos ya estén editados en "fvcctk". ;)

— Joe

Depende de lo que quieras decir con "prevenir".

(En primer lugar, la rotura de bits es un término con múltiples definiciones. Esta pregunta no se trata de que el código no se pueda ejecutar debido a la falta de mantenimiento ).

Si quiere decir "prevenir" que probablemente detectará la corrupción por descomposición de bits, sí, eso funcionará. Sin embargo, no ayudará a corregir esa corrupción: los hash solo proporcionan detección de errores , no corrección .

En general, esto es lo que se entiende por "integridad": la posibilidad de detectar manipulación no autorizada / no intencionada de datos, no la posibilidad de prevenirla o corregirla.

En general, aún querría un RAID1 junto con copias de seguridad (posiblemente implementado con instantáneas ZFS o similares, no estoy familiarizado con la semántica de ZFS en las instantáneas RAID1 +), por varias razones:

si un disco falla fatalmente, necesita un RAID1 (o una copia de seguridad reciente) para restaurar sus datos; ninguna corrección de errores puede corregir la falla de un disco completo, a menos que tenga una copia completa de los datos (RAID1). Para un breve tiempo de inactividad, esencialmente debe tener RAID1.
Si elimina accidentalmente partes o todo el repositorio, necesita una copia de seguridad (RAID1 no lo protege, ya que refleja inmediatamente el cambio en todos los dispositivos)

Sin embargo, RAID1 de nivel de bloque (por ejemplo, a través de LVM o similar) con solo dos discos en sí mismo no lo protegerá contra la descomposición silenciosa de datos: el controlador RAID no puede saber cuál de los dos discos contiene los datos correctos. Necesita información adicional para eso, como una suma de verificación sobre los archivos. Aquí es donde las sumas de comprobación zsf y btrfs vienen en: pueden ser utilizados (lo cual no quiere decir que se utilizan en estos casos, no sé cómo ZFS o btrfs manejan cosas allí) para distinguir cuál de los dos discos tiene Los datos correctos.

— Jonas Schäfer
fuente

No es necesario que espejes si no quieres. ZFS admite la creación de bandas con paridad de 1, 2 o 3 unidades; y duplicación con un número arbitrario de unidades (incluida una sola unidad = sin redundancia). Mi almacenamiento masivo principal es ZFS con seis unidades en una configuración RAIDZ2, que es básicamente RAID6 a nivel de sistema de archivos (con una redundancia de dos unidades). Esto puede detectar y recuperarse de la pérdida de cualquiera de esas unidades, más errores no corregibles en uno más; o la pérdida de dos unidades y ningún error en otro lugar durante la recuperación; sin ninguna pérdida de datos. Todavía se recomiendan las copias de seguridad.

— un CVn

prevenir la pudrición de la broca

No, no lo hace, de ninguna manera. No hay redundancia similar a RAID introducida por git. Si los archivos en su .gitdirectorio sufren una descomposición de bits, perderá cosas como de costumbre.

ayuda contra la podredumbre?

Yyyy ... no No ayuda contra la ocurrencia de pudrición de bits, pero ayudará a detectar la pudrición de bits. Pero en ningún momento durante el uso normal lo hace por su propia cuenta (bueno, obviamente lo hace cuando revisa algunos objetos, etc., pero no para su historial). Tendría que crear trabajos cron para volver a calcular los hash del contenido y compararlos con los hash reales. Es bastante trivial hacerlo, ya que los githashes son literalmente simplemente hashes de contenido, es trivial recalcularlos y lo git fsckhace por usted. Pero cuando detecta la descomposición de bits, no hay nada en particular que pueda hacer en su contra. Específicamente, como los fragmentos más grandes se comprimen automáticamente, es probable que incurra en una pérdida total de fragmentos si se voltea un bit en un objeto más grande.

— AnoE
fuente