Имеется комп,в нем несколько хардов НТФС.Также имеется еще несколько хардов с НТФС отдельно. Харды от 500гб до 2ТБ
Вскоре будет новый комп,с системным ССД и каким-нибудь хардом под данные.Основное применение всего этого хозяйства-монтаж и обработка видео,причем исходные материалы нужно хранить бесконечно.
План пока такой:После сборки нового компа со всех имеющихся хардов снимаются образы,и закидываются на рейд(или на новые харды?).
NAS с рейдом собирается из старого компа , но для него специально покупаются новые харды.Исходные харды идут в шкаф как резерв.
Вопрос такой
1.Для старых данных лучше образы(удобно ли будет его монтировать в ридонли) или разделы старых хардов напрямую закинуть на новые (удобно ли будет это монтировать в ридонли)?
2.Рейд не заменяет бэкапа,так что это все придется бэкапить (порядка 5-15 ТБ) Куда? На еще харды?
(вообще,как правильно организовать бэкап старых ридонли данных,в большинстве случаев понятие "бэкап" относится к горячим,постоянно меняющихся данных)
3.Какую ось ставить на комп,который будет NAS-ом,и какую ФС там применить?(принципиально сохранение структуры старой НТФС,так что это важно если будут использоватся образы с НТФС а не залив физических разделов)
4.Как организовать хранение в новом компе? HDD+бэкапы на NAS?
Облака не предлагать.
Вовремя ты дисковую подсистему обновлять собрался. Придётся немного подождать.
>снимаются образы
Зачем? Доступ к данным ты через монтирование образов организовывать будешь? Данные покопировал и всё.
>Куда? На еще харды?
Самый адекватный вариант. Можешь на блюрей. Можешь на ленту, но там малые объемы невыгодны.
>вообще,как правильно организовать бэкап старых ридонли данных,в большинстве случаев понятие "бэкап" относится к горячим,постоянно меняющихся данных
>4.Как организовать хранение в новом компе? HDD+бэкапы на NAS?
Гугли инкрементальные бэкапы.
>Какую ось ставить на комп,который будет NAS-ом,и какую ФС там применить
Это уже к пердолям из /s. Ради надежности заморачиваются с HEDT (ради ecc) и ZFS.
>>5499790
Необходимость в рейде от нагрузки не зависит. Нужна надежность - делай рейд1/5/6/10 какой там тебе подходит по возможносям и бюджету.
А вообще в dsd тред зайди, там все дискоебы тусуются.
>Зачем? Доступ к данным ты через монтирование образов организовывать будешь? Данные покопировал и всё.
Основаная причина-целостность и неизменяемость данных (вт.ч атрибуты вроде дат создания\изменения) на разделах,запись в которые более не планируется.
>>5499797
>Можешь на блюрей. Можешь на ленту, но там малые объемы невыгодны.
А блюрей не хуже чем HDD по надежности?Лента-очень дорого,тут как я понял выгодно только если от 100 ТБ и больше .
>>5499797
>Необходимость в рейде от нагрузки не зависит. Нужна надежность - делай рейд1/5/6/10 какой там тебе подходит по возможносям и бюджету.
>
А насколько проблемный пердолинг с обеспечением надежности самого рейда(не ебнется ли контроллер в случае железного рейда)?
> Исходные харды идут в шкаф как резерв.
Богоугодно.
Я думаю следует поступить примерно так:
1. Оперативные данные. Новый комп 2 SSD raid 1 и 4 HDD raid 10 - средствами винды. Есть смысл докупить сетевухи 1G/2.5G так чтобы пустить 2 или 4 шнура к свичу с аггрегацией каналов. Обязательно стоит АВТОМАТИЧЕСКИЙ скрипт или софт типа бакулы который делает еженочные бэкапы.
2. Архивные данные и бэкап. В другой комнате старый комп, в нём SATA-контроллеры, сетевухи и жестких дисков по надобности. На нём стоит FreeNAS - в качестве файловой системы ZFS и работает службы nfs и smb. Архивные файлы доступны пофайлово ридонли.
3. Долговременное хранение. В самом простом случае, просто сейф с жестаками с зашифрованными данными в другом офисе. От пожара и взлома основного офиса грубо говоря. Имеете в старом компе мобилрэк - суёте туда очередной диск и вперёд. Если мыслите сотнями терабайт, то LTO. Облако, если денег не жалко.
>Основаная причина-целостность и неизменяемость данных (вт.ч атрибуты вроде дат создания\изменения) на разделах,запись в которые более не планируется.
Даже если так - ты всё равно теряешь в удобстве доступа и, внезапно, в занятом объеме - диски то у тебя стопудово заняты не на 100%, а в образ придется снимать весь диск с пустым пространством.
>А блюрей не хуже чем HDD по надежности?
На полке - лучше. Это девайс для холодного хранения данных.
>А насколько проблемный пердолинг с обеспечением надежности самого рейда
Зачем тебе аппаратный рейд, земля очистилась настолько что люди выкатили mdraid/lvm, а в винде собственный софтрейд еще с семерки поддерживается нормально.
>>5499827
>Новый комп 2 SSD raid 1 и 4 HDD raid 10 - средствами винды. Есть смысл докупить сетевухи 1G/2.5G так чтобы пустить 2 или 4 шнура к свичу с аггрегацией каналов.
Обосрался, ты ему для домашних забот еще фибрченнел предложи. У него ж не энтерпрайз чтобы так заморачиваться.
Даже один диск выдаёт больше сотки в линию.
А у опа будет что-то типа raidz1 из пяти.
Какой-то всратый график.
>Даже один диск выдаёт больше сотки в линию.
Если он будет брать потребительские винты по 2...6тб, то в последней трети скорость будет ниже сотки. Если будет брать SMR... надеюсь не будет. В любом случае агрегация это не первостепенная задача при постройке NAS. Поймет что жмет - сходит карт докупит. Она к слову ж вроде не работает через обычные потребительские свичи/роутеры? Видел такое утверждение в сетевом.
100 мегабайт это не серьезно. Нормальный NAS по сети может и должен работать быстрее одного сраного внутреннего диска.
У меня raidz2 на шкафу стоит из 5 блинниц, по прямому подключению 2,5 гига забивает стабильно на запись, планирую до 10 расширяться.
>>5499822
>железного рейда
Забудь это словосочетание.
>Основаная причина-целостность и неизменяемость данных (вт.ч атрибуты вроде дат создания\изменения) на разделах,запись в которые более не планируется.
Адекватный софт умеет копировать атрибуты. Образ - лишнее усложнение схемы.
Щас он одинаково от других шизиков начитается что нужно больше червей-кабелей по дому пустить да переплатить за червей-коммутаторы с последующим пердолингом агрегации по всем точкам со спорным итоговым результатом. Это бля не 100мбит чтобы охуевать от результата. Пусть сам определяется.
>как сэкономить тысячу рублей, и получить 1 гиг вместо 2,5
Щас бы предлагать пойти докупить 2.5г сетевуху/пачку сетевух с поддержкой агрегации и 2.5г роутер на пустом месте.
>Щас бы предлагать пойти докупить 2.5г сетевуху/пачку сетевух с поддержкой агрегации и 2.5г роутер на пустом месте.
Зачем роутер для связи двух машин? Ты больной? Зачем городить огород на пустом месте, когда прямое подключение pc-pc работает прекрасно? Особенно linux - windows.
И никакая агрегация не нужна для того, чтобы кинуть 2,5 гига одним кабелем. Сетевушку можно в китае купить дешевле 1000 рублей при желании, либо за полторы при отсутствии такового, прямо в ДС.
А кидать 5 дисков в рейде через 1 гиг это как предлагать подключать 3080 по рейзеру в x4 псину. Работать, конечно, будет, но...
>Зачем роутер для связи двух машин?
Чтобы получить доступ к данным с ноутбука, например? Или даже с телефона? Или с другого ПК?
>чтобы кинуть 2,5 гига одним кабелем
ОП не писал что у него там за мать в старом ПК.
>А кидать 5 дисков в рейде через 1 гиг это как предлагать подключать 3080
Хуевые аналогии confirmed.
Если на 3080 майнить то и x1 сойдёт только ограничение в дровах. Повторюсь, от задач зависит.
>Чтобы получить доступ к данным с ноутбука, например? Или даже с телефона? Или с другого ПК?
Ты не поверишь, но все еще никакой проблемы: одна сетевуха на LAN до пеки, другая на WAN. Все равно покупать под NAS мамку с 2,5Г расточительно. Там в основном серверный и гоймерский оверпрайс.
>ОП не писал что у него там за мать в старом ПК.
Если бюджетная - берешь вторую карту. 2к за обе.
>Повторюсь, от задач зависит.
Задача простая - передача данных.
> в винде собственный софтрейд еще с семерки поддерживается нормально.
Нирикамендую.
Тестил я этот софтрейд (под данные, грузился не с него).
Тот, который как бы аналог raid5, бесповоротно помер после того, как я тупо переткнул диски в другие порты.
Настолько бесповоротно, что в этих вендах даже powershell не запускался.
>Задачу передачи данных решает и морзянка.
Отдельный порт 2.5г под пк имеет смысл, если не хватает 1гбит. Агрегация и прочая срань - весьма узкоспецифичная вещь.
>>5500185
>имплаин на 50к можно купить датацентр
>тем более после чиадефицита
Желания продолжать срач желания нет, оп увидит разберется кто шизик а кто нет.
>>5500186
>Настолько бесповоротно, что в этих вендах даже powershell не запускался.
>грузился не с него
Это как вообще? Дело было явно не в бобине.
Ладно, я только что перечитал псто и увидел что оп там нас с новыми винтами собирает. Тогда ты прав, сорян, но сам подход вызывает вопросы.
Если работать с большими массивами данных, то не проще ли это прямо на компе делать? По сети еще и мелкоблок просажен будет в отличие от прямого подключения.
Ну блин, изоляция даёт защиту. Хреновый БП, опрокинутый чай, вирус-шифровальщик, пожар в комнате может унести все твои данные разом. А если у тебя NAS отдельный то уже как-то разносишь риски.
>По сети еще и мелкоблок просажен будет в отличие от прямого подключения.
Надо просто Fibre Channel использовать, бгг.
>Если работать с большими массивами данных, то не проще ли это прямо на компе делать?
Проще, но в десктоп лезет меньше, чем в тот же сервак на хуанане.
Кроме того, NAS очень желателен на ZFS, а это Linux. Так что хочешь не хочешь, а вторую систему запускать где-то придется.
Это всё понятно, но стоит же соблюдать баланс - монтировать локально быстро, потом в хранилище выбрасывать. Да из всего тобой перечисленного нас решает только проблему опрокинутого чая и размещения системника под ногами. Хз в общем.
Раз уж на то пошло, то в NAS стоит воткнуть хороший сосоди под кэш операций.
>Да из всего тобой перечисленного нас решает только проблему опрокинутого чая и размещения системника под ногами. Хз в общем.
Еще ошибки ловить может в ФС до того, как файлы побьются.
>>5500229
>Под ZFS еще и ECC не помешает, кроме того она требовательна к ОЗУ.
Да, благо на 3 дыдре дешевая.
>>5500234
>Родная ось для zfs солярис.
Строго похуй.
>и были там всякие странные глюки.
Сейчас их нет.
>Может, лучше эта, mdraid?
Оно не ловит ошибки налету же.
БП тоже разные, чё. Если ты на насе настроил разграничение прав, то ни с какой винды архивные файлы не попортишь. Плюс ZFS даст тебе снапшоты, откатишься на вчерашний снапшот и всё.
>>5500229
Это вздор. ECC не помешает на любой файловой системе, просто в руководствах к ZFS не забывают об этом настойчиво напоминать.
По требовательность к ОЗУ не знаю. Ну допустим даже на сокет 775 8 гиг можно воткнуть - это с запасом для ZFS. Дедупликацию, конечно, лучше не включать.
>>5500234
Ну-у-у да. Если с zfs не знаком и ты не ставишь готовый freenas, то наверно действительно проще соорудить из знакомого:
mdadm будет тебе делать raid
lvm будет тебе делать снапшоты
xfs станет файловой системой.
Не вижу в таком наборе ничего плохого. Всё отлично работает. Нет чексумм и копи-он-райт - да и хуй с ними.
>Дедупликацию, конечно, лучше не включать.
Дедупликацию лучше не включать вообще, если ТВЕРДО И ЧЕТКО не знаешь, что она принесет пользу. Для монтажа точно будет один вред.
>Ну допустим даже на сокет 775 8 гиг можно воткнуть - это с запасом для ZFS.
Зависит от обьема массива. Меньше 16 я бы не стал ставить.
Когда пул подходит к концу, производительность часто сильно падает. И необходимость не забивать zpool частенько делает ZFS неприменимым.
Да ZFS вообще не про производительность. Она про надёжное архивное хранение ещё и со сжатием, она про охуительные выкрутасы со снапшотами, про квоты и, внезапно, про офигительную интеграцию с солярой.
Например, есть работающий на ldom он в качестве диска использует zvol. И ты решил на его основе сделать эталонную систему. Зашёл в саму систему сделал снапшот фс, проапгрейдил пакетики, всё нормально. Выключил, сделал снапшот zvol. Включил, деконфигурнул систему, выключил. Опять сделал снапшот zvol - станет эталоном. Сделал промоут снапшота и теперь наоборот, твоя рабочая система стала сама снапшотом, подал его в лдом, загрузился - система как была. А с эталона ещё снапшотов понаделал и в другие лдомы пораздавал.
Нужно ли это всё здоровым людям... пожалуй, нет. FreeNAS как готовое решение разве что.
>Под ZFS еще и ECC не помешает, кроме того она требовательна к ОЗ
>>5500248
>Это вздор. ECC не помешает на любой файловой системе, просто в руководствах к ZFS не забывают об этом настойчиво напоминать.
>По требовательность к ОЗУ не знаю. Ну допустим даже на сокет 775 8 гиг можно воткнуть - это с запасом для ZFS.
ECC нужна для зфс не больше, и даже меньше, чем для других ФС.
Потребление ОЗУ можно затюнить вплоть до машин с 128Мб ОЗУ.
>>5500263
Админа бы наняли.
С ZFS нужно работать особенно аккуратно при нагрузках связанных с записью.
Правильно выбирать размер блока например, понимать разницу между синхронной и асинхронной записью.
Ну и если требуется много синхронной записи ставить SLOG на SSD.
Или выключать синхронную запись вообще, если условия позволяют.
>>5500298
>Да ZFS вообще не про производительность. Она про надёжное архивное хранение
Ну, я бы так не сказал.
Производительность на уровне с другими COW файловыми системами. Со своими особенностями конечно.
Ну таки главная фишка ZFS это обнаружение "тихого" повреждения данных, но это как бы не об архивном хранении, а именно о активной системе. И в целом устойчивость к сбоям.
Снапшоты и управление томами вместе с рейдом то-же вкусные вещи, это удобно.
> Ну таки главная фишка ZFS это обнаружение "тихого" повреждения данных
Кек.
> What the CRC Jesus clan don’t seem to realize is that all hard drives since the IDE interface became popular in the 1990s have ECC built into their design and every single bit of information stored on the drive is both protected by it and transparently rescued by it once in a while.
https://www.jodybruchon.com/2017/03/07/zfs-wont-save-you-fancy-filesystem-fanatics-need-to-get-a-clue-about-bit-rot-and-raid-5/