ответ на вопрос "зачем?" вполне очевиден. Там лежат бэкапы, задача которых спасти данные. Если бэкапы будут доступны для ОС в момент работы шифровальщика, то данные не спасти.
Тут ниже уже написали, но хотелось бы еще раз указать. Выставлять наружу 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 сделать я не подскажу, но я бы перед манипуляциями скопировал все все файлики куда-нить) и больше их не использовать.
Что касается самих данных приложения в ВМ. То есть почты. Если она хранится в какой-либо базе данных, то наверное нужно делать бэкап базы данных средствами встроенными в СУБД. Это даст вам большую гибкость в работе с данными. Хотя и бэкап ВМ будет не лишним.
Смотря чем вы бэкапите.
Если вы просто файлы вм копируете самостоятельно, то изначальный файл основа у вас уже есть и она не меняется, ее можно просто хранить в бэкапах. А вот измененные файлы с дельтой нужно копировать.
Но обычно механизм такой - удаляются все снимки, ждем завершения слияния файлов снимков с основным хранилищем. Потом запускаем бэкап, в ходе которого создается новый снимок и делается копия только основного файла - без новых данных в снимке. Если мы запустили процедуру в 17-00, а закончили в 19-00, то все новые данные (скажем в 17-15 пришло письмо) уже не попадают в нашу копию, они попадут в следующую. По окончании бэкапа удаляем снимок, дожидаемся слияния.
Ну и бэкапы иногда можно проверять - восстанавливать куда-нить и запускать.
hint000, это ж всего лишь 2tb. Зачем так сразу. С 10tb raid5 было бы стремно, а на 2 тб нормальные шансы на ребилд в приемлемое время.
Кеширование в память идет энергозависимое (если ram не энергонезависимый применяется), а с ssd будет энергонезависимое решение.
Схема рабочая, на большинстве СХД применяется кеширование на ssd. На некоторых raid контроллерах тоже. Тут только один косяк в схеме - ssd в единственном экземпляре, без рейда. Да и 250гб достаточно быстро забивается при таком массиве если нагрузка есть.
Насчет драйверов для NIC - они должны просто быть, могут быть дефолтные (те что win сама ставит), без всяких дополнительных красивых интерфейсов управления. Никаких vlan в настройках самих адаптеров указывать не надо.
"после установки на гейт vlan 2 пошел" - а что за гейт? У вас есть отдельно выделенный сервер hyper-v с ролью network gateway?
Для начала забудьте про team. Разберитесь с базовым вариантом.
1. Создаете обычный вирт коммутатор в Hyper-v. Он что в 19, что в 22 одинаково создается.
В этом же месте если хосту нужен доступ к untagged (dafault vlan), то не выбираем галкой влан. Если нужен vlan 2 или что там у вас - галку и ставим 2. При этой настройке ваш сетевой порт сервера как бы отсоединяется от самого хоста физического и пробрасывается в виртуальный коммутатор. Он становится одним из портов вирт коммутатора. Можно даже хосту с него вообще не предоставлять доступ к этому адаптеру если у вас другие для самой ОС есть.
Теперь все пакеты (тегированные, не тегированные) приходят в вирт коммутатор. Даже если он лампочками не моргает, нет веб интерфейса с настройками- он все равно есть.
2. Теперь, к вирт коммутатору подключаем вирт машины. Создаем у них vnic и втыкаем в вирт коммутатор. Указав при этом если мы хотим чтобы vnic был воткнут в тегированный vlan. если не указать - будет в дефолтном (В вашем случае в 1).
Вопрос - а хосту на самом деле нужны несколько сетевых интерфейсов в разных вланах?
Может хосту достаточно одного влана, а вот виртуалкам - хоть 2, хоть 100?
В таком случае в hyper-v оснастке поднимаете virtual switch прямо через гуй. Выделяете для хоста вирт интерфейс для управления (там можно указать влан). А далее для каждой из vnic виртуалок назначаете нужный влан.
То есть со стороны hyper-v у вас по сути такой же управляемый коммутатор как и tplink, они смотрят друг на друга транковыми портами. А на виртуалку из виртуального коммутатора будет уже смотреть access порт с прямо указанным вланом.
Технически можно создать на хосте несколько таких вирт адаптеров с разными вланами, но это не через гуй, это ps. Собственно так оно в System center и работает, но четких инструкций мне не попадалось как это сделать на standalome Hyper-v хосте.
По сути это просто полка куда диски вставляют. Эту полку по sas интерфейсу подключаете к или jbod контроллеру c external потрами, который воткнут в какой-то сервер. Выглядит вот так.
3.5 диски в корзины 2,5 не воткнуть, или я не понял.
По совместимости. Скорее всего заработает с любыми контроллерами / серверами. Но это ж hp, тут сложно быть уверенным в совместимости.
даже без AD можно подключить принтер к ПК и расшаривать его оттуда. Правда может переехать ПК и тогда клиентов придется перенастраивать.
Есть вариант работы по hostname, если роутер имеет в себе dns сервер, то можно принтеру присвоить определенное имя и подключать эти принтеры по имени. Тогда при смене ip они продолжат работать.
