Предотвращает ли Git деградацию данных
Я прочитал, что ZFS и Btrfs используют контрольные суммы для предотвращения деградации данных, и я прочитал, что Git обладает целостностью благодаря хешированию практически всего с каждым коммитом.
Я собирался использовать сервер Git на сетевом хранилище Linux с Btrfs RAID 1 для хранения, но если Git обладает целостностью, думаю, в этом нет необходимости (по крайней мере, если все, что мне нужно, - это предотвращение деградации данных).
Вопрос: Таким образом, целостность Git, хотя хэширование по существу всего с каждым коммитом, предотвращает или помогает против бит-гнили?
3 ответа
Хэширование Git происходит только во время создания коммитов, и с этого момента хэши используются для идентификации коммитов. Это никоим образом не гарантирует целостность файлов. Git-репозитории могут быть повреждены и потерять данные. На самом деле, git имеет встроенную команду для обнаружения такого рода потерь, git fsck, но, как сказано в документации, вы несете ответственность за восстановление любых поврежденных данных из резервных копий.
Зависит от того, что вы подразумеваете под "предотвратить".
(Прежде всего, bit-rot - это термин с несколькими определениями. Этот вопрос не о том, чтобы код стал неуправляемым из-за отсутствия обслуживания.)
Если вы подразумеваете под "предотвращением" то, что он, скорее всего, обнаружит повреждение путем распада битов, да, это сработает. Однако это не поможет исправить это повреждение: хэши обеспечивают только обнаружение ошибок, а не исправление.
Обычно это означает "целостность": возможностьобнаружения несанкционированных / непреднамеренных манипуляций с данными, а не возможность их предотвращения или исправления.
Как правило, вы по-прежнему хотели бы иметь RAID1 вместе с резервными копиями (возможно, реализованными со снимками ZFS или аналогичными, я не знаком с семантикой ZFS на снимках RAID1 +) по нескольким причинам:
если диск выходит из строя со смертельным исходом, вам нужен либо RAID1 (или недавняя резервная копия) для восстановления ваших данных; никакое исправление ошибок не может исправить неисправность всего диска, если на нем нет полной копии данных (RAID1). Для кратковременного простоя у вас должен быть RAID1.
если вы случайно удалили части или весь репозиторий, вам нужна резервная копия (RAID1 не защищает вас, поскольку он сразу же отражает изменения на всех устройствах)
RAID1 уровня блока (например, через LVM или аналогичный), содержащий только два диска, сам по себе не защитит вас от тихого разрушения данных: контроллер RAID не может знать, какой из двух дисков содержит правильные данные. Для этого вам нужна дополнительная информация, например, контрольная сумма для файлов. Вот тут и приходят контрольные суммы ZSF и btrfs: их можно использовать (что не означает, что они используются в этих случаях, я не знаю, как ZFS или btrfs обрабатывают вещи там), чтобы различить, какой из двух дисков хранится правильные данные.
предотвратить гниение
Нет, совсем нет. В git нет никакой избыточности, подобной RAID. Если файлы в вашем .git каталог пострадает, вы потеряете вещи, как обычно.
помочь против гниения?
Ыыыо... нет. Это не помогает против возникновения гниения, но помогает обнаружить гниль. Но ни в коем случае при обычном использовании он не делает этого за свой счет (что, очевидно, происходит, когда вы проверяете некоторые объекты и т. Д., Но не для своей истории). Вам нужно будет создать задания cron, чтобы пересчитать хэши из содержимого и сравнить их с реальными хешами. Это довольно тривиально, так как git хеши - это просто хеши контента, их тривиально пересчитать и git fsck делает это для вас. Но когда он обнаруживает гниль, он ничего не может с этим поделать. В частности, поскольку более крупные фрагменты автоматически сжимаются, вы, скорее всего, понесете общую потерю фрагментов, если перевернуть бит в более крупном объекте.