Все уже написали. То что вы построили называется "вложенная виртуализация". Виртуализация внутри виртуализации. Она нужна только для собирания на коленке тестовых сред.
Непосредственно на хосте можно поднять hyper-v (нормально работает только на серверной ос, но в теории быстрее) либо virtualbox (медленный, но гибкий). И в нем поднимать уже нужные виртуалки без вложенности.
Вы импортозамещение планируете? Тогда может сразу на astra поднять dhcp и перевести полностью туда сервис?
Кроме того, если планируете импортозаместить стек Active Directory, dns, dhcp, то стоит посмотреть в сторону продукта от астры ALD pro. Он и установку по pxe в том числе решает из коробки. Хотя и без него все решаемо.
Но вообще если просто проблему нужно решить - на ws вполне можно прописать нужные параметры в dhcp.
Ремарка по поводу журнала транзакций - надеюсь вы его бэкапите. Как-то великоват.
А по существу мне сказать нечего. Либо не идет сжатие по каким-то причинам. Либо запись ручного бэкапа идет в тот же файл где уже лежит предыдущая копия, либо идет бэкап и базы и логов в один файлик (руками так вроде можно сделать, но я не пробовал). Это все варианты которые в голову пришли. Как именно через "вручную", с какими параметрами - неизвестно.
Наличие сжатия можно проверить 7-zip на готовом архиве, если сжимается хорошо, значит было без сжатия. Если не сильно, значит не было сжатия.
tukreb, не работаю в датацентре. Регулярно встречаю ситуации где R5 нормально совершенно отрабатывает. Еще раз - Raidz1 который вы предложили это тот же raid 5 только в профиль. Если будете моим директором - буду использовать то что вы скажете, без проблем.
buddh1st, не могу сказать наверняка, нет под рукой dpm. По идее даже форматировать не надо, надо просто удалить из dpm этот пул и пересоздать его заново. Это если никакие бэкапы там не нужны.
И я могу ошибаться, но нужно бы запустить сами бэкапы. Возможно DPM просто сделал преалокацию и учел что джобы будут занимать указанное место, поэтому вы видите что места нет. Но на самом деле бэкапы могут идти, vhd по мере наполнения данными будет расти.
Подключить новую (временную) емкость, мигрировать dpm пул, разобраться со старой емкостью (что угодно, хоть уформатироваться всласть), мигрировать обратно.
Ну очень интересный стиль ответов на ответы. Аж зачитался, потом увидел нервность и токсичность.
Я бы рассмотрел варианты:
- QNAP говорят умеет на некоторых железках подключать дочерние NAS к себе. Насчет iscsi не уверен, но вроде возможность сама по себе была заявлена. (я бы не доверил) Да и чем это поможет непонятно если нет снэпшотов.
- Поначалу подумал на штатные средства типа DFS или штатных sds, но понял что речь не о переезде с одной хранилки на другую, а о резервном копировании.
- В итоге получаем правильный вопрос - какие использовать средства резервного копирования? (не имеет значения das/nas/san и вот эта вся ситуация с qnap, unraid)
Мильон вариантов для бэкапов файлопомойки. Duplicatti, Cobian, aomei, acronis...
А можно еще замутить вариант более устойчивый к вирусам, шифровальщикам и т.п. Выделенную железяку в виде относительно старого пк, к которой и подключить UNRAID. (ну или заменить unraid на truenas какой нить) и настроить bacula/bareos. Оно будет забирать данные с вин и перемещать их к себе на хранилку. С основной системы будет сложнее добраться до резервных копий. Хотя если на unraid снепшоты, то это частично решает проблему.
Тривиально конечно, но может дело в "сжимать резервные копии"? Почему бы сразу не указать вместо default - сжимать. И в ручном режиме тоже убедиться что стоит пункт "сжимать".
Ночной должен отрабатывать, даже если минуту назад уже был бэкап. Обычно есть ошибки в журнале по которым можно понять что произошло.
tukreb, думаю это называется holywar и к делу не относится. Не всем и не всегда нужны SDS, не всем и не всегда нужны ZFS и raidz.
Выход из строя в raidz1 двух и более дисков точно так же карается потерей данных емнип. Это не более чем маркетинг, тот же рейд разных уровней, только с буквой Z.
tukreb, для бэкапов норм вариант. Хотя лучше R6 конечно.
Но тут и R6 бы не помог - диски отвалились (слово диски подразумевает количество более 1). В R6 если отвалится более 2х, та же картина будет.
DPM у вас ReFS использует? Если да, то может тут есть проблемы?
Он по умолчанию использовать дедупликацию должен, и наиболее вероятно еще какие-то снепшоты. Тогда удаление не приведет автоматически к удалению всех тех старых копий.
Кстати да - дедупликация очень чувствительна к любым потерям данных. Теряются какие-то 4кб и все затронутые копии на помойку.
Если dpm позволяет - перенести данные на другое временное хранилище, это пересобрать.
1. Да, SSD очень нужен. Как все написали выше.
2. Нужно убедиться что 1G есть скорость хотя бы с сервера до коммутатора.
3. Если очень хочется, то веб публикация либо rdp.
4. Средствами 1с реиндексация баз бывает не лишней и делается совершенно бесплатно. (обязательно бэкапы)
Вы случайно не пытаетесь утащить с любимой работы ценные данные таким незамысловатым способом?
В вин сервер есть iis6/smtp relay, устанавливается как роль, то есть можно сказать что часть ос. Оно умеет принимать нешифрованные соединения без всяких там паролей и пересылать уже на нормальные сервера. Возможно в десктопной тоже есть, надо смотреть.
да, hotspare это хорошая идея. И диски под ОС 2 шт небольшой емкости тоже хорошая идея.
То есть поставить пару ssd в R1
11 дисков в R6, R60 в зависимости от потребности в скорости
1 диск под резерв.
1. Не брать на себя лишние обязанности. Не подписывать никаких лишних инструкций, приказов и т.п.
2. Пусть штрафуют директора, тогда:
- сразу появится интерес у руководства к тому чтобы исправить ситуацию.
- появится возможность обращаться к ИТ специалистам которые построят инфраструктуру и вам останется только за ней следить.
- а чтобы лучше следилось, появится возможность обучения по применяемым вами ПО и железкам.
Это печально, но оно вот так работает. Пока директор уверен что все можно повесить на вас, у него нет никакого интереса что-то менять.