Коротко
- Динамический VHDX занимал 317,6 ГБ, хотя внутри гостя использовалось 56 ГБ из 498. Файл растёт при записи, но не уменьшается сам при удалении — это его свойство, а не поломка.
- Проверить свой диск можно двумя командами:
Get-VHDна хосте Hyper-V иdf -h /в госте. fstrim+Optimize-VHD -Mode Fullвернули 89 ГБ (317,6 → 228,9), но дальше файл перестал уменьшаться.- Точный результат дал клон на новый образ: 317,6 → 38,5 ГБ, простой около 5 минут, после старта — 71 клиентское подключение 1С.
- Переезжать на другой сервер не пришлось: всё сделано на том же хосте. Не уверены, что у вас с дисками? Проверим бесплатно за 1 рабочий день.
Что случилось: 317 ГБ при 56 ГБ данных
К нам пришли с типичной картиной: сервер 1С:Предприятие (Debian 12, Hyper-V Gen2) в какой-то момент перестал помещаться в хранилище. В госте использовалось 56 ГБ из 498 — 12%, то есть система была почти пустой. А файл виртуального диска на диске хоста весил 317,6 ГБ.
Между этими двумя числами — вся суть проблемы. Владелец видит в df -h свободные сотни гигабайтов и искренне не понимает, куда хост «тратит» место. Тем временем на физическом диске заканчивается пространство, и по мере его исчерпания виртуальная машина начинает получать ошибки записи — вплоть до аварийной остановки.
При этом бэкапы раздувшегося образа тоже весят сотни гигабайтов, а ежедневная копия всей ВМ занимает вдвое больше нужного.
Что у нас было на входе:
| Показатель | Значение |
|---|---|
| Гость | Debian 12, Hyper-V Gen2 (UEFI) |
| Нагрузка | сервер 1С, ~60 пользователей на двух базах |
| Виртуальный диск | 500 ГБ, динамический VHDX |
| Занято в госте | 56 ГБ из 498 ГБ (12%) |
| Файл VHDX на хосте | 317,6 ГБ |
| TRIM/UNMAP пробрасывается | да, гранулярность 32 МБ |
Отдельно проверили главное: данные в госте целые и помещаются в разумный размер. Проблема была исключительно в образе диска, а не в данных.
Проверим образы ВМ против занятого места и скажем, сколько гигабайтов можно вернуть. Бесплатно, за 1 рабочий день.
Почему VHDX раздувается и не уменьшается обратно
Динамический виртуальный диск в Hyper-V устроен по принципу «страница за страницей»: в файле образа лежат только блоки, в которые когда-то писали. Гостевая система выделила блок — гипервизор приписал его в файл. Файл вырос.
Обратного автоматического хода нет. Гость удалил файлы, освободил сотни гигабайтов — но хост об этом не знает, пока ему явно не сообщат. Сообщить можно двумя путями:
- TRIM/UNMAP — гость сам говорит «эти блоки мне больше не нужны»;
Optimize-VHD— хост сам просканировал файл и выбросил нулевые блоки.
Если не делать ни того, ни другое, файл будет только расти: каждая запись в лог 1С, каждый временный файл, каждое обновление пакета оставляют след. Через пару лет эксплуатации 500-гигабайтный диск, на котором реально занято 50 ГБ, закономерно весит 300+.
Важно: это не вирус и не повреждение. Данные в порядке, гость работает. Проблема — в месте на хранилище, и её надо решать до того, как диск закончится.
Для вашего администратора: как это выглядит в цифрах
Признак раздутого образа — расхождение трёх чисел: FileSize в Get-VHD, занятое по df -h в госте и свободное место на физическом диске хоста. Если первое в разы больше второго, виноваты не данные, а неотданные блоки: проверьте, включён ли UNMAP на контроллере (fsutil behavior query DisableDeleteNotify в госте) и запускается ли fstrim по расписанию (systemctl status fstrim.timer).
Как проверить свой диск за минуту
На хосте Hyper-V (PowerShell):
Для вашего администратора: проверка размера
Get-VHD -Path 'D:\VM\Debi\Debi.vhdx' |
Select-Object VhdType, FileSize, SizeVhdType = Dynamic, FileSize = 317,6 ГБ, Size = 500 ГБ — это и есть раздутый диск: логический размер против реального файла.
В госте:
Для вашего администратора: проверка в госте
df -h /
sudo fstrim -v /df показывает занято внутри системы, fstrim -v — сколько блоков гость готов отдать обратно. Если вторая команда отчитывается о сотнях гигабайтов, мусор накопился именно в образе.
Дальше сверяем просто: FileSize на хосте должен быть примерно равен занятому в госте плюс служебный запас в 5–10%. Разрыв в разы говорит о том, что пришло время разбираться.
Что пробовали и что это дало
Честно, по шагам — потому что половина статей в интернете заканчивается словами «просто запустите Optimize-VHD», а реальность интереснее.
Шаг 1. Уборка в госте и fstrim
Удалили оставшийся бэкап реестра 1С (17 ГБ, живой реестр на месте), запустили fstrim -v /:
| Операция | Результат |
|---|---|
fstrim -v / (первый прогон) | освобождено 254,5 GiB за ~1 секунду |
| удаление старого бэкапа | занято 56 → 39 ГБ |
fstrim -v / (второй прогон) | освобождено ещё 15,1 GiB |
Итого гость отдал хосту около 270 GiB блоков. Дальше файл должен был уменьшиться — но сам он, разумеется, не уменьшился: для этого нужен второй шаг.
Шаг 2. Optimize-VHD -Mode Full
Первые попытки на работающей ВМ не давали эффекта — это ожидаемо: оптимизация требует выключенной ВМ или отсоединённого диска. Отсоединили диск от контроллера, запустили полное сканирование:
Для вашего администратора: лог компактизации
OPTIMIZE_START (detached, Mode Full) -> OPTIMIZE_DONE seconds=357
SIZE_BEFORE_GB=228.941 SIZE_AFTER_GB=228.941 SAVED_GB=0357 секунд сканирования, экономия — ноль. Файл уже ужался до 228,9 ГБ и дальше упорно не двигался: гипервизор считал оставшиеся блоки занятыми, и ни один штатный приём их не отдавал.
Вывод из практики: на месте, штатными средствами, мы вернули 89 ГБ из 279 возможных. Дальше файл не шёл. Искать причины в сотнях параметров стало бессмысленно — начали с чистого листа.
Разберёмся: проверим образы ВМ, TRIM, место на дисках и покажем, что с этим делать. Бесплатно за 1 рабочий день.
Как решить правильно: клон на новый образ
Самый предсказуемый способ получить диск нужного размера — не чинить старый файл, а собрать новый и перенести на него систему. Это не миграция на другой сервер: тот же хост, та же ВМ, другой файл диска.
Порядок такой:
- Создать новый dynamic VHDX того же размера (500 ГБ) и подключить его к ВМ вторым диском — гость увидит пустой
/dev/sdb, работа не прерывается. - Разметить и отформатировать с новыми GUID: GPT, EFI,
/boot, LVM. Копировать старую разметку с идентификаторами нельзя — PARTUUID совпадут, и systemd начнёт путаться при загрузке. - Скопировать данные живой системой через
rsync— с исключением виртуальных файлов (/dev,/proc,/sys,/run), без которых монтирование в chroot не поднимется. - Переписать
fstab, пересобрать initramfs и GRUB на новые UUID — самый ответственный шаг: пропущенный здесь пункт даёт систему, которая не загружается. - Дельта-синхронизация в окно простоя: останавливаем 1С, догоняем изменения, выключаем ВМ.
- Меняем диск местами в настройках ВМ (старый отключаем, новый ставим на тот же контроллер), включаем и проверяем.
В нашем случае итог был таким:
| До | После | |
|---|---|---|
| Файл VHDX | 317,6 ГБ | 38,5 ГБ |
| Занято в госте | 39 ГБ | 39 ГБ |
| Простой | — | около 5 минут |
| Сессий после старта | — | 71 подключение 1С |
Старый образ не удаляли — он остался как бэкап на случай, если в течение нескольких дней проявится что-то непредвиденное. После стабильной работы его удаляют, и экономия становится окончательной: 279 ГБ.
Для вашего администратора: ключевые команды
# хост: размер и тип диска
Get-VHD -Path 'D:\VM\Debi\Debi.vhdx' | Select VhdType, FileSize, Size
# хост: компактизация (ВМ выключена или диск отсоединён)
Optimize-VHD -Path 'D:\VM\Debi\Debi.vhdx' -Mode Full
# хост: подключение нового образа вторым диском
New-VHD -Path 'D:\VM\Debi\Debi_new.vhdx' -SizeBytes 500GB -Dynamic
Add-VMHardDiskDrive -VMName Debi -Path 'D:\VM\Debi\Debi_new.vhdx'# гость: проверка и освобождение блоков
df -h /
sudo fstrim -v /
# гость: клон (новый диск уже смонтирован в /mnt/new)
sudo rsync -aHAX --numeric-ids --delete \
--exclude=/dev --exclude=/proc --exclude=/sys --exclude=/run \
/ /mnt/new/После клона обязательно: новые UUID в /etc/fstab, update-initramfs -u, update-grub, grub-install — в chroot к новой системе, с примонтированными /dev, /proc, /sys.
Как проверить после переключения
Список короткий, но пропускать пункты нельзя:
findmnt /показывает новый UUID — система реально загрузилась с нового диска;journalctl -b -p errпуст — ошибок монтирования и инициализации нет;systemctl status srv1cv8…,nginx,apache2— все в состоянии active;- клиентские сессии 1С поднимаются, соединения с СУБД уходят на нужные адреса;
Get-VHDна хосте показывает ожидаемыйFileSize.
Если что-то пошло не так — откат делается за минуты: выключить ВМ, вернуть старый диск на тот же контроллер, включить. Именно поэтому старый образ не удаляют сразу. Про саму процедуру восстановления читайте в правиле 3-2-1 для бэкапов.
Сколько стоит
Ориентировочные цены на октябрь 2026 года. Точную стоимость называем после бесплатной оценки: размер хранилища, количество ВМ, что именно раздулось.
| Работа | Ориентир цены |
|---|---|
| Диагностика хранилища и виртуальных машин | бесплатно, 1 рабочий день |
| Компактизация VHDX в согласованное окно (1 ВМ) | от 150 до 400 BYN |
| Перенос ВМ на новый диск с клонированием | от 350 до 900 BYN |
| Перенос ВМ на новый хост под ключ | от 650 до 2 500 BYN |
| Абонентское обслуживание: мониторинг, бэкапы, обновления | от 400 до 800 BYN/мес |
FAQ
Это опасно? Можно ли потерять данные?
Само по себе раздувание файла диска не портит данные — гость работает как обычно, пока хосту хватает места. Опасны неосторожные действия: оптимизация без бэкапа, удаление «ненужных» файлов в госте, мгновенное удаление старого образа после переключения. Мы работаем только после бэкапа и оставляем старый диск как откат.
Почему нельзя просто нажать «Уменьшить диск»?
Потому что Hyper-V не умеет уменьшать динамический VHDX на лету: диск расширяется автоматически, а сжимается только вручную через Optimize-VHD при выключенной ВМ или отсоединённом носителе. И даже тогда результат непредсказуем — как в нашем случае: 89 ГБ вместо ожидаемых 270.
Сколько раз можно это делать?
Сколько угодно — операция не меняет данные гостя. Но каждый раз это лечение симптома. Если после компактизации не настроены регулярный fstrim и контроль места, диск раздуется снова за несколько месяцев. Профилактика: включённый fstrim.timer, мониторинг занятого места и редкий, но обязательный Optimize-VHD.
Поможет ли переезд на другой сервер?
Нет. Проблема не в сервере, а в файле образа — на новом хосте он таким же останется. Миграция оправдана по другим причинам: нехватка процессорной мощности, памяти, дисковая подсистема, замена устаревшего оборудования. А если сервер 1С просто медленный, смотрите 7 причин, почему тормозит сервер 1С.
Что делать, если места почти не осталось?
Сначала — срочная копия важных данных (обычно реестр 1С и базы), затем fstrim и Optimize-VHD, и параллельно подготовка нового образа. Не откладывайте: когда хранилище заканчивается, ВМ может встать на запись в любой момент, а восстановление с бэкапа — это уже часы, а не минуты.
Проверим образы ВМ, ужмём что можно и перенесём данные на чистый диск — с бэкапом и окном простоя под ваш график.
Что мы сделаем
- Проверим бесплатно — размер образов против занятого в госте, TRIM, место на хранилище. 1 рабочий день.
- Составим план — что ужимать, что клонировать, когда можно выключать ВМ. Цена фиксируется до старта.
- Сделаем в согласованное окно — с бэкапом и старым диском на случай отката.
- Останемся на связи — по желанию: мониторинг, бэкапы и обновления по абонементу.
Если диск заканчивается регулярно — стоит посмотреть на всю инфраструктуру целиком: администрирование серверов. Напишите: info@itseo.by · Telegram