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

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

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

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

ты будешь каждый день его дописывать - считай постоянно дёргать диск? А если он помрёт, то что?



обычные рейд не пойдут, точнее мб raid1 пойдёт если в классическом понимании. Я за zfs, а именно за raidz2/raiddz3 . Это не бэкап?



ну то есть инфа будет в разрыв писаться ручками? А если инфы 10+ тб?

Нет, это избыточность, которая позволяет в некоторых случаях не потерять данные и главное - не прерывать работу.
Она не защищает ни от собственных ошибок, ни от сбоев системы, ни от вирусов, ни от одновременного выхода из строя сразу нескольких дисков.

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

Да хоть сколько, главное насколько информация ценная. Соответственно и выбирается и метод резервирования, который чаще всего дороже чем сама система.

Меня терзают смутные сомнения насчет того, что он одноблиновый.
Я последний хдд в магазине покупал в 2007 году и тогда макс объем блина был 320Гб.
Сомневаюсь, что с тех пор прогресс так скакнул вверх.

Может стоит сначала вообще узнать, что такое zfs и что там есть, прежде чем такую дичь писать?




хм, а если записать на рейд данные, и потом его отключить? это не бэкап? При это не просто бэкап, а с чек суммами и отказоустойчивостью и со снимками вдобавок.

Добавлено спустя 33 секунды:


там 9 блинов

Я уже несколько раз восстанавливал данные с этого бездарного чуда бестолковой мысли.
Все там через задницу сделано.
Не вычитал родительскую структуру, не возможно проверить корректность дочерней структуры.
Соответственно не возможно точно узнать организацию пулов, найти их правильные границы. И получаешь не данные, а кашу.
Беда то неисправных дисков что часть данных нереально вычитать, ни как. Если эти сбои попадают на метаданные, для всех файловых систем это катастрофа.
Ума привязывать контрольные блоки к самим файлам за более чем 50 лет ни у кого не хватило. Нет метаданных и ищи свисти, куски фрагментированных файлов.
А в ZFS особенно, так как данные хранятся в пулах c разным размером блоков, в зависимости от назначения данных. И пулы выделяются динамически, как придется. Нет нормальных последовательностей, даже черновым поском бесполезно делать.
Кусок файла в одном пуле, кусок где угодно в другом. просто при сбоях, она может себя восстанавливать, а при серьезных потерях - жопа.
Диски уже совсем не те, что были когда эта фигня разрабатывалась. Они сами все нормально спасают пока возможно, не будет он случайно то там то сям сбои выдавать. Если уж сдох, то там действительно дело дрянь и большие куски секторов вообще не вычитаешь.

ок.

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


Какие ты там данные хотел получить, если там всё в виде хэш сумм храниться?



zfs у по барабану куда там что попало - если есть чексуммы на других дисках - ты получишь свои данные, если нет - получишь всё, кроме того, для чего их нет. И чем больше у тебя дисков стоит "на отказ" тем меньше у тебя возможности потерять инфу. raidz2 - 2 любых диска в пуле, raidz3 - 3 любых диска. То есть из допустим 8 дисков в массиве raidz2 ты сможешь получить инфу при потере 2х любых дисков, с raidz3 при 9 дисках - любые 3 диска в пуле.

А если она не прочиталась, тогда что?
Файлы там хранятся обычным образом, структуры (метаданные) хешируются, но через жопу, контрольная сумма в родителе, а не в самой структуре. Потерял родителя, не проверишь эту структуру.
Ни какой гарантии что она еще правильная. В самих структурах, просто набор данных, случайный, подсовывай туда любой мусор, ей все нравится. Но оно не корректно.
Это вообще общая беда всех никс/Ext FS. Структуры не имеют четких однозначных сигнатур. Найти их без целостности ссылок нереально.
ZFS это просто надстройка над бездарной EXT. А не разработка с нуля, с учетом всех недостатков EXT.
NTFS хоть часть метаданных имеет узнаваемые сигнатуры, которые можно найти без родителей, но тоже не до конца, нерезидентные атрибуты, такой же мусор, который невозможно найти без родительской записи.
А в EXT только суперблоки узнаваемы, все остальные 100 типов метаданных - чисто мусор. Который ни как не найдешь, без суперблока и всей цепочки структы.
Вы пока это все сами не поковыряете, вам все это бесполезно объяснять. Вам остается только верить рекламе. )
это ж просто беспредел, один сектор не вычитался в середине каталога и получай миллион потерянных файлов и их возможных версий. Потому что цепочка нарушена, и что брать за основу неизвестно.

Тогда она из избыточности её возьмёт, параллельно попробует её исправить в похеренном месте.



Всё что ты написал - бред сивой кобылы + твои больные фантазии. Ознакомься пожалуйста с принципом работы zfs .

Вот и знакомься c этой рекламной чушью. )
Я это читал. там половина вообще только намерения, а не реализация. с какого хрена они уже более 37 версий выпустили, и ни одна не доведена до конца.
До первого серьезного сбоя, и будешь потом локти кусать, что ни чего не спас.
Я вижу как все сделано в реальной задаче в Дата экстракторе, в структурах данных и виде файлов. и вижу результат анализа, который настолько хреновый, что лучше сразу отказываться и не браться за такие заказы. (
Ася с марта 14 года как начала заниматься подержкой ZFS.
И до сих пор не все версии еще поддерживает, и массу вещей еще не придумала как реализовать.
UFS или R-студия, которые якобы поддержку ее объявили вообще фактически ни чего не реализовали. Только простейшие случаи могут разобрать.
Мне лично, ни рейды ни тем более ZFS, как собаке пятая нога. Вот дуракам, которые на рекламу купились, приходится данные с этого безобразия спасать. ))

ок.

Наверно, 1-2тб в зависимости от технологии записи
почему один блин? по нагреву, шуму 1-3 блина не сильно отличаются, с одним может попасться хуже отбалансированн чем с 9.

yandrey
вероятность выхода из строя 1 головки и 1 блина в одном ХДД против вероятности выхода из строя 1 головки и 1 блина из 9 головок и 9 блинов в одном ХДД...
хз. может тер вер тут и не работает, но всегда старался взять под хранилище одноблиновый ХДД почему-то интуитивно.

Не правильно считаете. Сами по себе головки и блины крайне редко выходят из строя.
Пластины так считай ни когда, если туда пыли не насыпать или жидкости (которая совершенно леко проникает под резинки) или нагреть диск больше 250 градусов, когда уже защитный фторопластовый слой поплывет.
Фторопласт, говорят, испаряется со временем, но с какой скоростью конкретный тип фторопласта испаряется, который используется в дисках, - данных нет.
По крайней мере 25-30 летние харды еще работают.
Буквально единицы случаев за десятки лет, когда головка умерла и после замены поверхность вычитывается без сбоев.
Практически всегда, если мертвая голова, то поверхность там зацарапана. т.е. уже из-за царапин умерла головка.
Диски в основном гибнут от случайных вибраций (ударов и громких звуков) чем легче диск и выше плотность записи, тем он чувствительнее к внешним вибрациям.
Так что совершенно без разницы, одна головка или несколько царапнут поверхность из-за внешних вибраций. Диск все равно не жилец.

Tomset, благодарю за развернутое разъяснение!

Нет никаких проблем бэкапить инфу с RAID-массива на другой RAID-массив - специально выделенный именно для бэкапов...

Хм, интересно, а не об этом ли я говорил постоянно?

глупость в том, что нет ни какого смысла крутить кучу дисков постоянно, если не требуется непрерывный процесс. Убивая ресурс сразу многих дисков.
Ждать когда случайная вибрация убьет сразу их все, потому что они все работе. А особо ретивые еще и парковку на всех отключают, что бы не щелкали и не было задержек.
Основное от чего гибнут любые диски это всякие случайные вибрации и громкие звуки. На втором месте, логические ошибки (пользователя, системы, вирусы) и ничтожно малая часть дохнет по остальным причинам.
От первых двух причин рейд ни как не спасает.
Первая причина отчасти решается организацией помещения, серверной, куда ни кто не ходит, всякие экраны и звуко изоляция, устройство полов, тамбуров, дверей, окон, микроклимат.
Вторая только административными мерами, кто куда имеет доступ, созданием копий по времени, теневые копии, тайм машины, организацией безопасности.
И только последние причины, естественный износ, редкие отказы элементов дисков, позволяют в рейде менять диски не прерывая работу.
А для этого нужен постоянный контроль и дежурный админ, который вовремя среагирует на ситуацию. От приходящего админа, толку очень мало. Когда он чухнется, в рейде уже несколько дисков накроется. Дома постоянно следить за состояние рейдов, тоже не удастся. То на работе, то в гостях, то в отпуске или на даче. Так что городить рейды дома ни какого смысла нет.

что такое ресурс диска? в зеркале нагрузка по чтению распределяется, причем не равномерно

Грубо сколько диск операций может сделать за год без ухудшения параметров.
На старых мало емких дисках такой вопрос не стоял. там не возможно было в принципе очень много писать.
На новых 50-150 Тб в год от хоста.
Это и высокая плотность, всякие медиа кэши и черепичная запись.
Очень тонкий магнитный (домены нужны очень маленькие, в толстом магнитном слое мелкие не сделаешь) и защитный слой. Высота полета крайне низкая 4-6 нанометров, от магнитной поверхности, больше пары нанометров защитный слой уже не даст читать и не позволит лететь головкам. От малейших вибраций слой будет истираться
Диск пока крутится, не запаркованный, постоянно читает и корректирует положение головок, а вибрации делают свое черное дело.

Уточняю: на отдельный массив для именно бэкапов.
А ты регулярно утверждаешь, что "отдельный массив не нужен - и так всё зашибись!"
А если требуется?
У клиентов инкрементальный бэкап баз 1С выполняется каждый час - предлагаешь то включать, то отключать питание на массиве для бэкапа?..
Вот с этим абсолютно согласен.