BlinCT, посмотрите сетевые карты и главное - коммутаторы на 2,5G. Есть вероятность что передумаете по поводу 2,5. Выбор 2,5 резко сужает выбор оборудования и повышает бюджет. Там до 10G ethernet по цене недалеко.
ИБП должен быть с выходами для подключения - usb|rs232. Ну и должна быть хоть какая-то информация о совместимости с системой на которой вы собираете. Обычно есть информация о совместимости. ИБП можно и потом докупить.
Возможности расширения емкости зависят от того чем именно и какой именно рейд соберете. Если это зеркало, то расширить его можно будет как минимум двумя такими же дисками. Если R5, то можно диски докидывать обычно. Но опять же - смотрим чем собираем и читаем мануал. Но тут возникает новая проблема - R5 не рекомендуется для емких дисков (4тб и более), т.к. очень большое время ребилда. Так что приходим к R6, а это уже много дисков и потеря емкости (на 4 дисках 50% емкости в трубу)... Короче - для домашнего R5 и ставим свечку )
Saboteur, добавлять диски что в lvm/zfs , что в mdadm будет проблематично. Есть риски и там и там нажать что-нить не так. Системы NAS типа Truenas вроде умеют это делать через красивый гуй, с минимальными требованиями к квалификации юзера.
информация теряется обычно при пересборке raid'а аппаратного, если у аппаратного рейда нет функции расширения емкости без потери данных. А она обычно сейчас везде есть, но может не хватить гибкости. Например raid5 можно будет диск добавить, но перейти с raid5 на R6 уже никак без полного разрушения.
BlinCT, так то мысль хорошая. Если бюджет позволяет.
- 2,5 гигабитные коммутаторы уже есть или просто в планах?
- кеш при чтении фильма не поможет, т.к. чтение все равно будет с медленного диска. Вот на запись кеш может помочь.
- на такую хранилку было бы неплохо накатить plex или jellyfin.
- ОС и приложения лучше на ssd ставить. И уже программным рейдом собирать массив из hdd.
- сейчас странная ситуация. Стоимость hdd улетает в космос, а ssd дешевеют. Возможно, уже можно собирать массивы Raid 5 из емких SSD бытовых. Скорость в разы выше, деньги почти те же, надежность выше если учесть что hdd - SMR. Это если данные большую часть времени просто лежат и не перезаписываются постоянно.
Уже посоветовали freenas/truenas - поддержу.
Можно еще навернуть ZFS (она позволит кеширование, дедупликацию), но будет значительно сложнее, требования к железу выше и ломучесть... Наверное оно того не стоит под видосики.
Saboteur, Synology/QNAP NAS не включает в себя аппаратных raid контроллеров. По крайней мере те модели которые мне попадались. И корп версии тоже включают в себя обычно HBA, то есть решение построено на программном рейде.
Но работает из коробки и не нужно ничего выдумывать, настраивать, читать, мучать себя.
inneks, там есть megaraid CLI и megaraid storage manager GUI.
CLI - консольные инструменты. Можно при большом желании ограничиться этим. Но графический интерфейс конечно визуально удобнее.
В readme указаны требования для установки. Версия java тоже должна быть указана.
Уж имя прежнее точно не стоит оставлять. Можно потом огрести всяких неудобств в виде останков от старого DC в каталоге и непонятно будет это от старого или от нового.
Если по варианту 2, то убедитесь что есть прям самые новые и хорошие бэкапы DC и что их можно быстро развернуть если что. Так-то вероятность потерять единственный DC за несколько часов что поднимается новый - крайне низкая.
ответ на вопрос "зачем?" вполне очевиден. Там лежат бэкапы, задача которых спасти данные. Если бэкапы будут доступны для ОС в момент работы шифровальщика, то данные не спасти.
Тут ниже уже написали, но хотелось бы еще раз указать. Выставлять наружу rdp опасно. Количество случаев когда по rdp открытым наружу вламывались и наносили ущерб сложно подсчитать - очень много.
Пробуйте прикрутить хотя бы:
vpn server - даже в домашних роутерах есть.
port knocking - есть в некоторых роутерах
постоянные последние апдейты на ОС
ts gateway - но это уже не про домашний вариант
Посмотрите загрузку через диспетчер задач и через монитор производительности. Нагрузку на каждый из дисков во время копирования, нагрузку на CPU.
Вероятность того что сеть загружают настолько что для rdp не хватает пропускной способности крайне низка.
по корпусам тогда разбивку можно не делать.
Для NVR я бы выделил больше одной сети, т.к. 200 это уже близко к 250 шт.
Если серверов уже 9, то можно в отдельную подсеть.
Выделив ИБ и руководство вы на уровне сетей сможете предоставить им доступ, а остальным закрыть.
Под телефонию зарезервировать подсеть сразу.
Если у вас много hyper-v серверов, сложная структура vlan'ов, со вложенностью как в матрешке, вот тогда вам нужна данная функция на нескольких выделенных hyper-v серверах.
самое самое простое что можно придумать и быстро сделать это зайти в папку пользователи и посмотреть там профили. Будет видно какие пользователи заходили на ПК, а самый последний по дате изменения скорее всего будет тот кто последний заходил. Ничего кроме проводника не нужно открывать в этом случае.
Это можно и с любого другого ПК посмотреть через \\pcname\c$\users - как-то так.
В тех задании прописана неплохая надежность. Raid 0 на 4 дисках дает грубо 12% вероятность выхода из строя массива в год, при вероятности сбоя каждого диска в 3%. Это полное отсутствие надежности. Технически R0 можно сделать на дисках разного объема, это не должно быть проблемой. Да и LVM это по сути R0. И лучше так не делать.
Скорости с такими дисками вообще не получить. Хотя мы же не знаем о каких скоростях идет речь.
Копирование файлов - вероятно речь про копи-паст во время rdp сессии. Небольшие файлы таким образом достаточно легко скопировать на примонтированный в сессию диск или в проводник на своем ПК. Но файлы большого размера будут копироваться медленно и со сбоями. Для таких целей проще яндекс диск или мейл ру облако.
Wrapper как здесь уже все отметили не улучшит ничего, только ухудшит.
я смотрю у carbonio есть красивенький встроенный механизм резервного копирования. https://habr.com/ru/companies/Zextras/articles/678110/
ВМ тоже нужно копировать, но и настроить копирование через сам карбонио наверное стоит. Либо в сетевую шару, либо на отдельный виртуальный диск.
inneks, нет, клонировать не обязательно. https://superuser.com/questions/1476264/can-i-dele...
То есть в оснастке virtualbox выделяем те снепшоты которые больше не нужны и удяляем их. Остается только current state. Это можно сделать и при включенной машине. Поскольку я VB использую крайне редко, я бы сначала сделал полную копию всех файлов ВМ если место позволяет.
Еще момент, при слиянии снепшотов, как правило, требуется много свободного места. Обычно места нужно столько, сколько занимает сам снепшот. Диск вм будет в это время тормозить, не рекомендуется это делать в часы пик.
Могу сделать предположение что для резервного копирования вы не используете специализированное программное обеспечение, а просто копируете файлы виртуальной машины. Это мое предположение номер 1.
Кроме того, перед снятием резервной копии вы останавливаете виртуальную машину. То есть копируете ее в выключенном состоянии. Это предположение номер 2.
Исходя из этих предположений предлагаю не использовать снэпшоты от слова совсем. Механизм снэпшотов используется в случае если требуется скопировать данные без остановки ВМ.
Сейчас ваша задача избавиться от всех снимков (как это правильно в VB сделать я не подскажу, но я бы перед манипуляциями скопировал все все файлики куда-нить) и больше их не использовать.
Что касается самих данных приложения в ВМ. То есть почты. Если она хранится в какой-либо базе данных, то наверное нужно делать бэкап базы данных средствами встроенными в СУБД. Это даст вам большую гибкость в работе с данными. Хотя и бэкап ВМ будет не лишним.