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