Комментарии 16
JBOD
Жесткие диски были сконфигурированы в несколько наборов RAID-массивов, у
Вы ещё RAIDите? В XXI веке? Про ZFS, я так понимаю, не слышали?
Здесь, видимо, использование Veeam является требованием и в данном случае лучше поставить Windows Server и на него Veeam и подключить диски напрямую через контроллер.
Можно, конечно, поднять ZFS с SMB на дополнительном сервере и примонтировать к Veeam по SMB, только это +1 сервер к полке только ради ZFS и прогон трафика по Ethernet будет не бесплатен для процессора, поэтому в данном случае просто не имеет смысла.
А так какие преимущества ZFS при бэкапах? Запись и чтение обычно линейные в очень большие файлы, записанные файлы уже сжатые, снапшоты не нужны. Ну ок, можно RAIDZ3 собрать ценой повышения нагрузки на CPU, но то такое, надо еще обосновать чем это лучше альтернативных вариантов в контексте бэкапового профиля нагрузки.
> А так какие преимущества ZFS при бэкапах?
После того, как Вы погоняете ZFS пару месяцев, в один прекрасный день увидите, что винчестеры отдают Вам несколько не то, что на них было записано (несмотря на коды Рида-Соломона и прочее контрольные суммы секторов, которые вроде как должны там быть), и поседеете — вот тогда этот вопрос у Вас отпадёт.
Смысл ZFS в том, что она не перекладывает контроль за целостностью данных на винчестер.
Я делаю полный скраб раз в пару месяцев — и время от времени оказывается, что данные где-то немножко покоцаны. ZFS тут же исправляет ошибки, в то время как RAID1 попросту не знает, какая из двух копий — истинная: он ведь не хранит контрольные суммы.
Да, проблема порчи данных на уровне жестких дисков есть.
Ну в контексте резервного хранения RAID1 никто использовать не будет. Скорее всего будет RAID5 (так как потеря бэкапов при ребилде из-за второго сдохшего винта как правило не критична) или RAID6.
Кроме того, вполне вероятно, что если бэкап сжатый (а такое бывает не редко), то контрольные суммы будут в самом алгоритме сжатия и да, восстановить при этом данные будет нельзя, но что бэкап битый станет ясно при попытке восстановления. Ну тогда откатиться на день позже. Если люди восстанавливаются из бэкапов, они уже готовы потерять 1-2 дня работы ибо там где откатываться на 1-2 дня нельзя, там снапшоты, репликацию и т.п. подходы используют.
Опять же про восстановление данных, если исходить из ненадежности хранилища (есть еще передача по сети, если хранилище по сети монтируется к бэкапилке), то разумно это вынести в бэкапилку, а не в файловую систему, чтобы она могла прожевать сбои и сети и дисков и здесь тогда разумно поднимать вопрос не про ZFS, а про наличие такого функционала в бэкапилке.
З.Ы. все это в контексте бэкапа, а не работы виртуальных машин и системы хранения для них, где действительно фичи ZFS более сильную позицию имеют.
Не понятно структура raid на полке.
Будет как у нормальных полок? Упадет емкость?
Скорость явно не блещет, не под что другое кроме длинных архивов (Backup(Copy)по версии Veeam) использовать не стоит.
И то при условии что поймем как там raid работает.
Практические кейсы по созданию IT-инфраструктуры на базе дисковых полок Western Digital Ultrastar