Hyper-v. Слияние снапшота с объемным исходным диском

Добрый день.
Столкнулся с одной проблемой.

Вводные: есть гипервизор на базе winserv 2012, на нем есть raid5 общей емкостью 14.5 Tb. (сама ОС стоит на отдельном зеркале рядом)
На данном рейде крутится виртуальная машина, тоже на базе winserv2012, используется как боевой терминальный сервер для 60+ пользователей.
Виртуалка фиксированная - ей назначена выделенная память, процессорные ядра, собран диск фиксированного размера в 10 Tb.

Проблема заключается в том, что в один день на этом сервере был сделан снапшот (пользователь поймал шифровалку, решил сделать перестраховку на случай если что-то пойдет не так)
Зверя вычистил, учетную запись человеку пересоздал.. Но по запарке забыл удалить снапшот (т.е. принять таким образом изменения)
В итоге, спохватился только через 20+ дней, к этому моменту созданный под снапшот динамический диск уже вырос до 270гб и продолжает расти (естественно)

В чем мои опасения:
1) На просторах интернета часто встречаются темы, что у людей напрочь повисал процесс слияния контрольной точки с основным диском, причиной тому была нехватка места там, где хранится машина и ее контрольные точки. Никакой однозначной информации на этот счет я не нашел, неясно по какому принципу нужно рассчитывать свободное место. На "авось" это делать не хочется, как раз-таки из-за возможного сбоя и из-за пункта 2:

2) Бэкап самой машины целиком сделать некуда.
М-да, сейчас уже становится понятно, что назначать на машину сразу большое количество дискового пространства было ошибкой - т.к. сейчас по сути занято на виртуалке от силы на 1Tb из десяти выделенных.
Соответственно, в текущем формате событий сделать экспорт или репликацию машины и пробовать уже на копии не получится.
Раздумывал над вариантом уменьшить диск... Но, вот незадача - из-за снапшота этого сделать нельзя, MS в своей документации это явно запрещает, предупреждая о безвозвратном повреждении ВМ и контрольных точек. Менять размер фиксированного диска допускается только для машин без снимков состояния.

3) Нет понимания длительности процесса.
Не нашел упоминаний о том, насколько долгим вообще может быть процесс слияния дисков в ВМ, а в особенности - такого размера. Просто "долго" или "зависит от конфигурации сервера"
Понятно, что конкретных сроков тут никто не скажет, просто хочется иметь возможность как-то косвенно оценить этот процесс. Причина опасения - сервер боевой, если простой в 2 выходных выбить будет достаточно просто, то в 3-4 дня уже нереально.

В итоге вот, сижу с бомбой замедленного действия и не могу принять решение.
Из вариантов которые уже рассматривал:
-на "авось" запустить слияние в пятницу вечером, истово молиться чтобы все прошло хорошо, без ошибок и вовремя. Но на это лучше не рассчитывать. Практика показывает, что "не так" может пойти вообще что угодно.
-выбивать сервер с дисковой конфигурацией превышающей имеющийся raid (вопрос насколько превышающей остается), минимально настраивать его в гипервизор и делать экспорт. Объединять уже там. Минусы - дорого, долго. Плюсы - надежно.
-Делать откат (т.е. применить контрольную точку) и потерять работу за 20+ дней целой толпы пользователей. И заново лечить вирус. Не самая хорошая идея.

В общем, прошу помощи.

0

М-да, сейчас уже становится понятно, что назначать на машину сразу большое количество дискового пространства было ошибкой - т.к. сейчас по сути занято на виртуалке от силы на 1Tb из десяти выделенных.
Соответственно, в текущем формате событий сделать экспорт или репликацию машины и пробовать уже на копии не получится.

- В виртуалке diskmgmt.msc - сжимаете диск. В свойстах hyper-v в виртуальной машине сжимаете. Бэкап. Тест.

0

pEntity, согласно данным от MS и статьям, на которые натыкался, данная процедура невозможна (я про сжатие диска), если у виртуальной машины есть контрольная точка.

Я об этом писал в оригинальном сообщении.

0

В поиске случайно нашёл эту тему. Очень интересно чем у ТС закончилось.
Жаль в теме больше нет вариантов, советов или решений.

0