сейчас гляну

вот вообще неправильные выводы. в одном случае вам информацию даёт одно решение от одного вендора, в другом случае информация даётся о совершенно другом от другого вендора

я бы ещё добавил что они технологически очень разные

что там вара натрекала в своих изменениях, а что там винда у себя

это попытка сравнить кислое с тёплым

снапшот, да, далается разными средствами.
но ведь инфа в них примерно одинаковая, это не jpg  с потерей данных

ну да, очень "примерно"

мне кажется вам нужно изначально теорию про ВМки изучить

да с чего ради она там одинаковая?

в случае бекапа из нутри, это просто всс снимок, в который попадает что-то, что считается изменённым по версии винды

во втором случае, это снапшот на сторе есх, в котором что-то изменилось по версии вары

при том что внутри, по версии винды, запросто могло ничего не поменяться

Ну да, наверно вы правы.
У винды и ее VSS сервиса больше данных об изменениях, а для гипервизора VM в большей степени черный ящик и она может сохранять то что только кажется (с точки зрения гипервизора) изменным, при этом еще и перестраховываясь...

Спасибо!

самое простое.  на файловом уровне , к примеру, виртальная память не бэкапится.   многие жестко залоченные файлы тоже (и VSS не поможет).  снэпшоты забирают все изменения на блоках

Кстати да, про содержимое RAM VM  я не подумал

в ней дело похоже, по разнице размера как раз близко к объему занятой RAM

В свое время тестировал дедуп от Нетбэкапа.
Новая установка, чистый пул дедупликации.

Первый проход - бэкап вм целиком.
Второй проход - бэкап директивой all_local_drives изнутри агентом.

Не помню результат первого прохода, но агентский бэкап показал эффективность дедупа - 99%.

Так что либо изменения реально серьезные с момента смены схемы бэкапа выше, либо действительно у Вима алгоритмы сжатия отличаются в разных случаях.

Апдейт: прочитал про память)

отличаются не алгоритмы сжатия, а алгоритмы работы с ВМ и гостевой ФС