Смотря чем вы бэкапите.
Если вы просто файлы вм копируете самостоятельно, то изначальный файл основа у вас уже есть и она не меняется, ее можно просто хранить в бэкапах. А вот измененные файлы с дельтой нужно копировать.
Но обычно механизм такой - удаляются все снимки, ждем завершения слияния файлов снимков с основным хранилищем. Потом запускаем бэкап, в ходе которого создается новый снимок и делается копия только основного файла - без новых данных в снимке. Если мы запустили процедуру в 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. Кажется где-то были такие сервера, сегодня потестирую что там с явой.
Ответ ищется в документации Fujitsu, чаще всего можно импортировать рейд массив даже созданный на другом аналогичном сервере или сервере с младшей версией контроллера.
Но бэкап лишним не будет.
Shandy, технически часто так делаю если система не поддерживает jbod, а прокинуть диски нужно для создания программного рейда внутри ОС. Так что в этом ничего необычного.
Если вы просто файлы вм копируете самостоятельно, то изначальный файл основа у вас уже есть и она не меняется, ее можно просто хранить в бэкапах. А вот измененные файлы с дельтой нужно копировать.
Но обычно механизм такой - удаляются все снимки, ждем завершения слияния файлов снимков с основным хранилищем. Потом запускаем бэкап, в ходе которого создается новый снимок и делается копия только основного файла - без новых данных в снимке. Если мы запустили процедуру в 17-00, а закончили в 19-00, то все новые данные (скажем в 17-15 пришло письмо) уже не попадают в нашу копию, они попадут в следующую. По окончании бэкапа удаляем снимок, дожидаемся слияния.
Ну и бэкапы иногда можно проверять - восстанавливать куда-нить и запускать.