Данная тема открыта для обсуждения и выбора винчестеров размером от 1.5 ТБ и выше.
Тема для обсуждения и выбора винчестеров размером до 200 гигабайт находится здесь.
Тема для обсуждения и выбора винчестеров размером от 250 до 500 гигабайт включительно находится здесь.
Тема для обсуждения и выбора винчестеров размером от 600-от гигабайт до 1 терабайта находится здесь.

Внимание: Barracuda 7200.12 Firmware Update

Полезная информация по жёстким дискам Seagate: [FAQ] Выбор винчестера от 1.5 ТБ и больше #17062202

Перед тем, как задать вопрос, прочитайте, пожалуйста, FAQ. Это в ваших же интересах.

там есть снэпы, мало того, что пофигу, так ещё и в случае авто снапшотов например на месяц можно файлы доставать на нужную дату

зеркальный рейд делается по большому счёту для одной цели:
минимизация простоя при отказе одного накопителя.
актуально для серверов, в частности для системных дисков, ибо поднимать ос и все роли даже при условии наличия более-менее свежего образа системы будет относительно затяжным, а так взять, переключить на вторичный плекс загрузку, и всё работает.
а для бэкапов данных ,тот тут можно nas купить, либо более дешёвый вариант дешман комп ,который будет по лану собирать через какое-нить ПО данные по сети к себе по расписанию

Godlike66 Я для бэкапов использую внешние харды.

Вполне разумно.

Добавлено спустя 1 минуту 21 секунду:
Жаль, что не все это понимают.

так, а если я на raid скидываю бэкап, он что перестаёт быть бэкапом? Что постоянно вы за муть пишите?

Ни в каком разе не перестаёт.
Но мне лично не очень понятен смысл сего действия в домашнем компьютере (хотя у клиентов на предприятии я именно на RAID1 бэкапы и складываю ).

Разницы нет куда вы бекап складываете, хоть на один диск, хоть на десять в рейде.
Надежность любого рейда ниже чем у единственного диска, лежащего на полочке.
два мало связанных понятия - постоянная доступность, непрерывность процесса и надежность данного решения.
два диска по любому менее надежны чем один, как одна система.
От того что один из них сдохнет, это же не значит что его не нужно заменить.
В рейде диски любят выходить из строя не по одному, а группой, так как диски в основном убивают всякие внешние вибрации, которые сразу действуют на все диски массива.
Для дома где непрерывность процесса - не важна, совершенно бессмысленное решение, делать Riad.
Только деньги переводить. С любого RAID также нужно делать постоянно копии.
Рейд лишь позволяет, не прерывая процесс работы заменить отработавший ресурс или начавший сбоить диск.
Но совершенно не защищает от всех других событий.
Даже ребилд опасно делать. когда один из дисков засбоил, пока не проверишь все остальные.
Редко какой контроллер позволяет проверить отдельно каждый диск, не разбирая весь массив. И то что требовалось - не прерывность процесса, сразу исчезает.

Дальше этой фразы можно не читать. Если не разбираешься в вопросе - пройди мимо и промолчи, не надо свой бред в тему выливать.

Добавлено спустя 1 минуту 56 секунд:


В 2020(да и уже как лет 10 минимум), открою для тебя секрет - никто не использует аппратные рейд для хранения инфы.

Это именно к тебе в бОльшей степени относится, Ага.

Здравствуйте!
Нужен диск большого объёма, в основном для бекапов. Основной критерий -- это надёжность, шум неважен. Выбор пал на следующий диски:
WD Gold WD102KRYZ
WD Ultrastar DC HC330 WUS721010ALE6L4
Прежде всего настораживает, что производитель их ориентирует на другие задачи. Также не совсем понятно их отличие друг от друга. Сколько в каком "блинов" не смог найти. Второй новее, есть какие-то новые технологии?
Также присматриваюсь к WD Ultrastar DC HC520 HUH721212ALE604, но он гелиевый, с ними ещё никогда дел не имел.
Посоветуйте пожалуйста с выбором, может взять какой-то другой? Бюджет ~ 20 т.р.

Это один и тот же диск с разными наклейками. Под бэкапы, ИМХО, вообще пофиг что брать.

В отличие от вас - диванных теоретиков, я пишу только про то, что использую сам и то, что проверенно временем и огромным количеством людей по всему миру. Если вы из каменного века, и для вас raid - это отдельная плата, то я сугубо говорю про софтовый, а если быть точным, то про raidz (zfs)

Это вообще атас, если рухнет. Хрен чего соберешь потом.
Приносят иногда на данные, когда любые средства восстановления систему уже бессильны.
Хоть стой хоть падай. Лучше всего не связываться и сразу отказаться от спасения данных.
Как вариант за очень дорого. но шансы весьма маленькие все удачно спасти.
От FS вообще мало чего зависит. Это разные уровни. Логические повреждения и физические, они как бы сами по себе, хотя и связаны тесно. Без разницы какая FS, если нужные структуры, причем все копии, не вычитываются физически.
Если не делать копии и их ротацию. Не важно с чего и куда. Оно рухнет рано или поздно, обязательно.
Рейд нужен, только для обеспечения непрерывности процесса при плановой замене дисков.
Отказ одного из дисков, это уже потенциальная опасность потерять все. И она достаточно большая, если не проверить остальные диски перед ребилдом. В случае проблем сделать копию того что еще можно спасти. Не запуская ребилд.
Без постоянных копий, у рейда куда больше причин рухнуть, чем у одного диска. Без бекапа по любому ни куда.
Логика совершенно простая, не требуется не прерывный процесс, Рейд тоже не нужен.
Только не затевайте, халивар. какая FS лучше. Абсолютно все имеют кучу недостатков, нужно лишь правильно выбрать, какую применять для конкретных целей. Где эти недостатки будет менее чувствительны.

Можно мне хоть одну ссылку где просто так развалился raidz1/2/3? Ну кроме случаем, когда дурочки не соблюдают обязательное условие - предоставлять zfs прямой доступ к дискам через HBA/AHCI(типа установки поверх аппратного рейда или полусофтового).



Почитай, как на zfs проходит скраб и ресильвер. Там нет такой дикой нагрузки на диски как у аппратных рейд. Так же почитай пожалуйста про снепщоты, теневое восстановление и вообще про всю специфику zfs.



Почитай про шансы отказа у raidz2/3, так же почитай про тухлую инфу на одиночных дисках/аппратных рейд контролерах. Прочитай про "ditto blocks"

Добавлено спустя 11 минут 34 секунды:


Во первых, рейды бывают разные. Raid1/6(если говорить про аппаратный) и mirror/raidz2/3 - служат для увеличения отказоустойчивости.

А какое это отношение имеет к отказам нескольких дисков в массиве?
Я и почитал и по ковырял. Ни чего хорошего, кроме рекламной туфты.
В плане восстановления данных это беда. Но это не по теме.
А в административную ветку я не пойду чтобы это обсуждать. Там вообще кошмар, какие заблуждения у людей. Где они этого набрались, загадка )
Ни один программист понятия не имеет , как умирают диски и что в них в первую очередь, чаще всего рушится и как.
Подумаешь натянули EXt со всеми своими болячками на ZFS. еще более усугубив проблему.
Точно также, как изголились, повторили идею в APFS и ResFS.
Которые восстановить при физических проблемах, стало очень сложно.

Очень даже большое. Диски во время классических ребилдов отъезжали из за сильной нагрузки + на больших дисках он идёт сутками. Так же в обычных рейдах консистенси чек идёт суткми, если не неделями, и от этого его почти никогда не запускают или запускают раз в год. А без консистенси чек - инфа может просто стухнуть на рейде .







Да уж куда им до тебя - ониж тупенькие, чёт какую то zfs придумали - а толку 0. Вот если бы им кто сказал - что на отдельных дисках хранить это надёжнее чем на массивах ... УЖС



Можно пруфец на этот бред ?



Диски - это расходники и восстанавливать их нахрен никому не надо (ну ток если вы инфу на 1 диске не храните). В массиве raidz2/3 отказ 2/3 дисков не повлияет на сохранность инфы. Так что меняете диски, запускаете ресильвер и погнали.

Так же никто вам не запрещает ставить 2/3 копии данных вместо 1 в zfs + возможности кластеризации никто не отменял.

Пруфецев нет пока.
Комплекс в библиотеке структур их не показывает открыто.
А образца нет под рукой
Закрытая пока инфа. чтоб конкуренты DR программ свои быстро не сделали.
Можешь линуксовые листинги поковырять, и убедится в тупости, но это как раз долго.
Не хочу я в эти дебри сейчас лезть. Если кратко
У всех EXT подобных систем общая беда, многие структуры не имеют четких сигнатур. их практически нереально найти если ссылочная целостность потеряна.
Контрольная сумма в родителе, которую использует ZFS. Бесполезна если родитель потерян.
Когда нет описателей пулов под разные типы данных, не реально найти их начало и конец, и определить размер блоков чередования, если там как раз без сигнатурные данные.
EXT,HFS короче все nixFS практически не собираемы, если несколько мегабайт в начале раздела не читаются.
А диски дохнут достаточно стандартно. Тряска > Царапина > грязная голова, которая уже не может писать. И все структуры, которые как раз постоянно меняются и записываются, оказываются убитыми.

Добавлено спустя 24 минуты 15 секунд:

А ни кто и не говорит что их надо восстанавливать. Только люди умудряются все сразу грохнуть. Самым невероятным образом. Воображения не хватит представить. И времени, чтобы все случаи описать.
Может до вас тоже когда нибудь дойдет. Что две-три копии в разных местах хранения, это гораздо надежнее чем любой постоянно работающий рейд. Когда он не требуется для организации не прерывного процесса работы.
Задачи совершенно разные. Требование не прерывной работы и бекап.
С любого рейда копия всегда должны быть!

Ей почти 15 лет. Так же она с недавнего времени Open. Так что тот бред который вы написали, даже во внимание принимать не стоит.



В ZFS нет партишенов. Там есть пул в который собираются диски и поверх пула нарезаются dataset и volume



COW системы или записывают валидную инфу - или не записывают вообще. При этом при записи идёт валидация всех супеней записи.

Добавлено спустя 1 минуту 49 секунд:


А где гарантия, что после записи на отдельные харды я получу в случае проблем именно то, что я записал, а не убитую инфу ?

Добавлено спустя 3 минуты 59 секунд:


Причём тут криворукость людей? Криворукий может и 10 отдельных копий ушатать, а ещё может метеорит упасть или там потом всемирный.



А если я с рейда кидаю копию на рейд? Как тогда быть то?

Толку то, что она Open.
там не написано, как спасать развалившуюся FS. Методики надо придумать, оптимальные алгоритмы.
Производители дисков понятия не имеют и ни чего не пишут для спасения со своих же дисков данных.
Это отдельная дисциплина. И свои корифеи в ней.

Заблуждение. Запусти DDD в виктории и посмотри скорость.
Сам диск запись не проверяет, а система не может каждый сектор сразу проверять. скорость будет ни какая. Все плюсы от скорости за счет организации разно размерных пулов, для каждого типа данных коту под хвост.
Когда у системы появится время проверить записанное, там почти все окажется уже убитым.
Транзакции в любой системе журналирования. Это только проверка отсутствия сбоев во время записи.
Сами записанные данные проверяться только тогда. когда к ним система по новой обратится.
Пока грязная голова серву чует, сбоев на записи не будет. Но это не значит, что данные потом прочитаются.

Ещё раз - покажи мне ссылку развалившуюся zfs.



Да что вы говорите ... Вот вам виде. Правда в zfs понятия сектор нет, есть понятие блок

"The default recordsize is 128 KB, which comes to 32 sectors on a disk with 4 KB sectors, or 256 sectors on a disk with 512-byte sectors"



Для этого есть scrub + self heal