Предотвращает ли Git деградацию данных

Я прочитал, что ZFS и Btrfs используют контрольные суммы для предотвращения деградации данных, и я прочитал, что Git обладает целостностью благодаря хешированию практически всего с каждым коммитом.

Я собирался использовать сервер Git на сетевом хранилище Linux с Btrfs RAID 1 для хранения, но если Git обладает целостностью, я думаю, что в этом нет необходимости (по крайней мере, если все, что мне нужно, - это предотвращение деградации данных).

Вопрос: Таким образом, целостность Git, хотя хэширование по существу всего с каждым коммитом, предотвращает или помогает против бит-гнили?

— MADforFUNandHappy
источник

Знаменитая катастрофа KDE 2013 года здесь несколько актуальна.

— Iwillnotexist Idonotexist

Остерегаясь локальных клонов, git пытается использовать жесткие ссылки, когда вы создаете клон в той же файловой системе. Это делает клонирование невероятно быстрым, но если один объект поврежден, оба клона будут повреждены.

— алло

Обратите внимание, что если повреждение происходит только для некоторых древних объектов на данном компьютере, эти объекты с большей вероятностью будут присутствовать в других клонах репозитория, в то время как (меньше) более поздние файлы все еще могут быть использованы. Я понятия не имею, как это интегрируется с файлами пакета, все же.

— o11c

Ответы:

Хэширование Git происходит только во время создания коммитов, и с этого момента хэши используются для идентификации коммитов. Это никоим образом не гарантирует целостность файлов. Git-репозитории могут быть повреждены и потерять данные. На самом деле, git имеет встроенную команду для обнаружения такого рода потерь, git fsck , но, как сказано в документации, вы несете ответственность за восстановление любых поврежденных данных из резервных копий.

— heavyd
источник

Почему fsckмне всегда кажется, что это плохое слово ... Полагаю, если получилось положительное, а у вас нет резервной копии, которая может быть уместной;)

— CAD97

@ CAD97 Программисты известны этими довольно слабыми играми. На самом деле это довольно часто ... С моей головы у вас есть такие вещи, как sh (shell), bsh (оболочка Bourne), а затем bash (оболочка Bourne again) ... последняя из них - хромая игра слов ...

— Нельсон

@ Нельсон не забывай рыбу

— user253751

@ CAD97 Черт, само название git можно считать таким же, как тогда, когда оно не работает для тебя.

— SGR

@ CAD97 - и это до того, как вы запустите его с такими флагами, как fvcctk, - потому что - если вы запустите его таким образом, ваши данные уже могут быть "fvcctk" ed. ;)

— Джо

Зависит от того, что вы подразумеваете под «предотвратить».

(Прежде всего, bit-rot - это термин с несколькими определениями. Этот вопрос не о том, чтобы код стал неуправляемым из-за отсутствия обслуживания .)

Если вы подразумеваете под «предотвращением» то, что он, скорее всего, обнаружит повреждение путем распада битов, да, это сработает. Однако это не поможет исправить это повреждение: хэши обеспечивают только обнаружение ошибок , а не исправление .

Обычно это то, что подразумевается под «целостностью»: возможность обнаружения несанкционированных / непреднамеренных манипуляций с данными, а не возможность их предотвращения или исправления.

Как правило, вы по-прежнему хотели бы иметь RAID1 вместе с резервными копиями (возможно, реализованными со снимками ZFS или аналогичными, я не знаком с семантикой ZFS на снимках RAID1 +) по нескольким причинам:

если диск выходит из строя со смертельным исходом, вам нужен либо RAID1 (или недавняя резервная копия) для восстановления ваших данных; никакое исправление ошибок не может исправить неисправность всего диска, если на нем нет полной копии данных (RAID1). Для кратковременного простоя у вас должен быть RAID1.
если вы случайно удалили части или весь репозиторий, вам нужна резервная копия (RAID1 не защищает вас, поскольку он сразу же отражает изменения на всех устройствах)

RAID1 уровня блока (например, через LVM или аналогичный), содержащий только два диска, сам по себе не защитит вас от тихого разрушения данных: контроллер RAID не может знать, какой из двух дисков содержит правильные данные. Для этого вам нужна дополнительная информация, например, контрольная сумма для файлов. Это где ZSF и Btrfs контрольные суммы бывают: они могут быть использованы (что не означает , что они будут использованы в этих случаях, я не знаю , как ZFS или Btrfs обрабатывать вещи там) , чтобы определить , какой из двух дисков имеет правильные данные.

— Йонас Шефер
источник

Нет необходимости заниматься зеркалированием, если вы этого не хотите. ZFS поддерживает чередование с паритетом на 1, 2 или 3 диска; и зеркалирование с произвольным числом дисков (включая один диск = без резервирования). Моим основным хранилищем данных является ZFS с шестью дисками в конфигурации RAIDZ2, которая в основном относится к уровню файловой системы RAID6 (чередование с избыточностью на два диска). Это может обнаружить и восстановить после потери любого из этих дисков плюс неисправимые ошибки еще на одном; или потеря двух дисков и отсутствие ошибок в другом месте во время повторной передачи; без потери данных. Резервные копии по-прежнему рекомендуется.

— CVn

предотвратить гниение

Нет, совсем нет. В git нет никакой избыточности, подобной RAID. Если файлы в вашем .gitкаталоге страдают от бит-гнили, вы потеряете вещи как обычно.

помочь против гниения?

Ыыыо ... нет. Это не помогает против возникновения гниения, но помогает обнаружить гниль. Но ни в коем случае при обычном использовании он не делает этого за свой счет (что, очевидно, происходит, когда вы проверяете некоторые объекты и т. Д., Но не для своей истории). Вам нужно будет создать задания cron, чтобы пересчитать хэши из содержимого и сравнить их с реальными хешами. Это довольно тривиально, поскольку gitхэши - это просто хеши контента, их тривиально пересчитать, и они git fsckделают это за вас. Но когда он обнаруживает гниль, он ничего не может с этим поделать. В частности, поскольку более крупные фрагменты автоматически сжимаются, вы, скорее всего, понесете общую потерю фрагментов, если перевернуть бит в более крупном объекте.

— Anoe
источник