Копирование файлов - вероятно речь про копи-паст во время 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 они продолжат работать.
А вскрыли именно жесткий диск или dvd привод? Считывающая головка это та что магнитная в жестком диске над поверхностью болтается или та что с линзой в приводе?
Просто есть вероятность что вы описали терминами не совсем корректными то что произвели.
Поиск в аутлуке это отдельная тема для научных работ )
Например, если есть exchange, то сам exchange периодически делает поиск и предоставляет данные в outlook.
Есть еще в винде встроенный search, и вот эта штука ходит по всему компу и индексирует все. В идеале можно просто виндовым поиском задать запрос и получить список в котором и письма и документы с интересующей фразой.
Но если проблемы возникают с этой индексацией, то и поиск в outlook страдает.
tictac17, хранилка не в смысле NAS, а в смысле storage в терминах бакулы или veeam. Оно, кстати, может быть и на винде теоритически. То есть на одном из компов. Но в этом случае от заражения не спасет.
На 2-3 сотрудника согласен - не вариант.
А чем таким интересно занимаются сотрудники что по несколько гигов данных генерируют за день?
С бакулой на самом деле все не так сложно. Но хранить файлы в единственном экземпляре (дедупликацию) она не умеет. Это только если в качестве файловой системы хранения использовать что-то с дедупликацией, а бакулу заставлять разжимать данные по получении.
В том же veeam/bacula/bareos есть вариант бэкапить данные на хранилку которая в самом офисе. А по ночам делать миграцию или синхронизацию полученных бэкапов. Заражение офисной сети не должно затронуть офисную хранилку, а вот пожар/потоп затронет.
Еще один вариант это перенаправляемые папки. Если у пользователя на компе все его окружение (рабочий стол, документы) будет на самом деле храниться на сервере, то и бэкапить данные нужно будет только с сервака.
не надо ему smb, там при подключении через java консоль можно примонтировать диски без всяких smb шар. Потому что шары это всякие там согласования версий (1,2,3), закрытие уязвимостей и т.п. И все это незаметно для глаза.
KVM Console там не html5, а java ведь? Чуть постарее просто найти JRE. Кажется где-то были такие сервера, сегодня потестирую что там с явой.
Wrapper как здесь уже все отметили не улучшит ничего, только ухудшит.