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

7883
MADforFUNandHappy

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

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

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

40
Знаменитая KDE [близкая к катастрофе 2013 года] (http://jefferai.org/2013/03/29/distillation/) [здесь несколько уместна.] (Http://www.h-online.com/open/ новости / пункт / KDE-узко избежать бедствий, 1829776.html) Iwillnotexist Idonotexist 6 лет назад 10
Остерегаясь локальных клонов, git пытается использовать жесткие ссылки, когда вы создаете клон в той же файловой системе. Это делает клонирование невероятно быстрым, но если один объект поврежден, оба клона будут повреждены. allo 6 лет назад 3
Обратите внимание, что если повреждение происходит только для некоторых древних объектов на данном компьютере, эти объекты с большей вероятностью будут присутствовать в других клонах хранилища, в то время как (меньше) более поздние файлы все еще могут быть использованы. Я понятия не имею, как это интегрируется с файлами пакета, все же. o11c 6 лет назад 0

3 ответа на вопрос

62
heavyd

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

Почему `fsck` всегда выглядит как плохое слово для меня ... Я полагаю, если получится положительным, и у вас нет резервной копии, которая может быть уместной, хотя;) CAD97 6 лет назад 4
@ CAD97 Программисты известны этими довольно слабыми играми. На самом деле это довольно часто ... С моей головы у вас есть такие вещи, как sh (shell), bsh (Bourne shell), а затем bash (Bourne again shell) ... последний из них - хромая игра слов ... Nelson 6 лет назад 7
@ Нельсон не забывай рыбу user20574 6 лет назад 1
@ CAD97 Черт, само название git можно считать таким же, как когда оно работает не для тебя. SGR 6 лет назад 0
@ CAD97 - и это до того, как вы запустите его с такими флагами, как fvcctk, - потому что - если вы запустите его таким образом, ваши данные уже могут быть "fvcctk" ed. ;) Joe 6 лет назад 1
16
Jonas Schäfer

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие вопросы