Запись данных которые необходимо хранить несколько лет.

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

Ну это уже слишком древние времена, когда надо было экономить пространство. Я на этом чуть не погорел, когда сдох один Mylex и в скорости засбоил второй. А приехавшая замена оказалась другой моделью.
Зеркало. Только зеркало.

Лучше софт-рэйд Софтовый рэйд 6 к примеру - полная независимость от контроллера, + работоспособность при выходе из строя до 2 любых дисков. Ессно, еженедельная проверка целостности по расписанию. Ну либо софтовое зеркало. Из плюсов, помимо отсутствия привязки к железу - еще и отсутствие проблем с контролем SMART-аттрибутов каждого из дисков.

В моих рекомендациях п.2 - дело техники и личных предпочтений.
Т.е. по поводу п.п.3-5 ни у кого возражений нету? Я рад, чесслово. Подрастают правильные, годные (ТМ) админы, есть нам смена...

PS: Забыл добавить к п.3 - если настраивать DFS, то _обязательно_ оную службу кластеризовать.

Если кому интересно, рисую самую недорогую из _почти_ безотказных конфигураций серверной (у меня так работает без проблем уже четвертый год; конфиг под виндовый лес доменов):
1) Два _одинаковых_ контроллера домена+леса (основной + резервный, роли FSMO раскидать самостоятельно, исходя из загрузки - у меня, к примеру, каждый компьютерный класс из четырех является дочерним доменом, обслуживаемым своим контроллером на виртуалке, т.е. загрузка ролей основных контроллеров понятна, а у кого-то может быть совсем иначе), оба-два также корневые серверы DNS, интегрированные в AD, только безопасное обновление.
2) На оных контроллерах ставится StarWind HA Storage, на коем создаются несколько мелких HA дисков (свидетель, всякие там DHCP/DFS/iSNS/пр.) и один большой - пул виртуальных машин.
3) На контроллерах устанавливается кластер (HA свидетеля мы уже сделали на шаг раньше), в кластер запихиваются всякие там сервисы DHCP/DFS/iSNS/пр. - см.выше; все подключаются через iSCSI с использованием MPIO.

4) Берутся еще три _одинаковых_ сервера, на которых также поднимается кластер (трехнодовый, без диска-свидетеля) и вешается сервис виртуальных машин (в данном случае через Hyper-V), диск для VM подключается как Cluster Shared Volume через iSCSI от StarWind HA Storage.
5) На втором кластере создается туева хуча VM для служебных целей, где брать место - понятно из п.4 (не забывать про распределение ресурсов процессоров и памяти! внимательно смотреть оснастку Hyper-V нынешней версии!).
6) Если есть еще пара серверов - не полениться настроить кластер 1С 8.х, очень способствует спокойному сну.
7) Все это повесить на хороший бесперебойник, типа APC 10+ KVA, настроить на оном сетевой шатдаун (ну и соответственно, выключение на клиентах, включая виртуалки).
8) Не забыть про _хорошее_ сетевое оборудование - несколько портов на каждый физический сервер для LAN + несколько портов для iSCSI с MPIO (политику брать по желанию - я предпочитаю RoundRobin); свитчи ставить третьего уровня и выше, отдельно на LAN, отдельно на iSCSI, желательно все свитчи дублировать.
9) Оставшееся свободное место на всех серверах расшаривается под папки DFS (по паре источников на каждое корневое имя достаточно, главное чередовать серверы-источники, чтобы не получилось одновременного падения доступа к копиям папок).
Ну а далее из данного конфига можно делать все, что придумается, включая бэкапы...
Если кто скажет, что я параноик, все можно сделать проще и дешевле, ну и т.п. - отвечу просто: поработайте с мое, а там посмотрим...

Накой л3 свичи там, где их задача сводится к свичеванию трафика в пределах одной подсети? л3 свичи вообще-то для маршрутизации между подсетями ставятся...
И да, не все л3 свичи одинаково полезны, поставит человек длинки какие-то, потом глюков с ними отгребет немеряно... Впрочем, старые киски немногим лучше в этом плане, их моск тоже имеет свойство вспухать от арп флуда/icmp флуда/мультикаст флуда/прочего, что идет на CPU.

И если уж зашла речь о бесперебойниках и т.п. - лучше 2 бесперебойника, и сервера с двумя БП. Мощность - не обязательно с 10-кратным запасом, хватит и 2-3 крат. Аккумы - лучше нештатные, к примеру, кучка 6СТ-180.

Забыл про это. Да, питальники на серверах минимум двухмодульные, а лучше (у меня так) - трехмодульные, работающие в режиме 2+1.
На второй бесперебойник размера стойки и самой серверной не хватило.
Кста, действительно использую нештатные аккумы тоже...

Да ты не поверишь!
1) Для обеспечения корректной работы MPIO даю всем портам карточек, используемых для iSCSI, номера _разных_ подсетей (типа, 192.168.100.х, 192.168.125.х, ну и пр.); при этом оные карты (4 порта) воткнуты в 4 разных свитча, общающихся между собой.
2) Почему общающихся - только на два из четырех свитчей еще идет по линии 10G от контроллеров домена, каждая из которых в свою очередь разбита на два VLAN'а, а вторая пара свитчей является расширением первой (аггрегировано шесть 1G-каналов).
3) Почему - да так получилось...
4) В обще-пользовательской сети у меня еще пять подсетей через VLAN (4 компьютерных класса + все остальные) - так проще рулить.
Как-то так.

Дык каждый интерфейс/подсеть - в свой влан, и делов... Накой их друг с другом маршрутизировать?
А прочие вланы, одновременно поднятые на нескольких физ. интерфейсах (если таковые имеются) - в бондинг (active-backup).
К слову, чем меньше фич свичей юзается, тем стабильнее работа (в идеале - только вланы + возможно снмп для мониторинга). И л2 свичи обычно менее критичны к всяким вещам типа колец/флуда/etc - даже если моск попух и ушел в себя из-за чрезмерной нагрузки на него, свич продолжает свичевать как ни в чем не бывало...

П.2 внимательно прочел?
Каждый коммутатор (из 4-х) обеспечивает свою подсеть. При этом, таргеты iSCSI обеспечиваются с двух компов через 10G - по одному штука на два из четырех свитчей. Разбиты пополам, каждая половинка на своем Влане.

Илья, стесняюсь спросить, но ты сейчас где работаешь? Все там же, где и пару лет назад?
Это ты так "напряг" свой колледж на нормальное железо?