Почему размер резервных копии Hyper-v больше фактического изменения данных внутри ВМ?

Question

[x2sp]

Добрый день.

Коллеги, используем Windows Server 2012 r2 в качестве гипервизоров в нашей инфраструктуре.
Для резервного копирования используем Arcserve UDP.

Заметили, что при без агентом резервном копировании раз в 15 минут размер каждого бекапа очень большой (более 15гб). Хотя метрики забикса не показывают таких изменений внутри машины (около 500 мб учитывая перезапись данных).

Свап в машине (вм) не используется из за достаточного кол-ва оперативной памяти.

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


Можно заметить, что с момента полного бекапа прошли сутки и было найдено 53 гб изменений в рамках VHD файла.

Но на самом носите в этот день почти не было никаких изменений:

Comments

[ambisinister One]

По мне - подкачку надо создавать в любом случае. Тем более, используя гипервизор.

[x2sp]

ambisinister One, ответ не по делу. Мы обсуждаем размер резервных копий, а не настройки виртуальных машин.

[ambisinister One]

x2sp, Я сомневаюсь, что за 2 минуты Вы успели проанализировать мой ответ.
)

[DevMan]

x2sp, ambisinister One, это вообще комент.

[DevMan]

x2sp, пожаловаться сил хватило, а понять написанное?
для тех, кто на бронетанке: это комментарии, не ответы.

[Alexey Dmitriev]

Инкремент? Если да инкремент к чему, сколько промежуточных копий?
Что находится внутри инкрементных копий - смотрели?
Может у вас база данных в одном файле на 50 GB - и конечно ее будет каждый раз перезаписывать полностью-несмотря на то что покластерно к ней 500MB в день добавляется.

[x2sp]

Alexey Dmitriev, мы говорим о блочном резервном копировании с гипервизора.

Принцип работы без агентного копирования Arcserve аналогичен другим вендорам - Veeam,Symantec итд

Поэтому посмотреть, что внутри является проблемой, так как это не файлы, а изменённые блоки внутри машины. (Change Block Tracking)

Так как в 2012 r2 не было MS драйвера CBT, каждый вендор использовал свой. К сожалению размер отслеживаемого блока драйвером очень огромный и имеет размер 4 мегабайта. (ответ саппорта)

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

P.S. Вопрос по инкрементам не понимаю.

[Alexey Dmitriev]

x2sp, причем тут чекпойнты? Вы бекапите машины с имеющимися снепшотами\чекпойнтами?

[Saboteur]

Шифрование на машине используется?

[x2sp]

Alexey Dmitriev, в рамках резервного копирования (далее р.к.) , как было написано выше, используется механизм CBT.

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

В момент старта р.к. внутри машины происходят процедуры для создания консистентной копии - шринк логов баз данных итд.
Далее создается чекпойнт ВМ для того, что можно было сохранить состояние машины и передать только измененные блоки внутри vhdx файла за прошедшие 15 минут.
По окончанию копированию блоков, их сверки на дедупликацию и выполнение сжатия для сохранения в датацентр, чекпойнт удаляется и происходит сливание его с vhdx файлом.

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

С момента, как р.к. создает чекпойнт (или если сделать его вручную) он очень быстро разрастается в объеме. И размер прошлого чекпойна до момента слияния очень похож на размер переданных блоков в рамках следующего р.к.

Т.к. в этом промежутке мы не видим, что внутри происходит какая либо активность (500мб) за 15 минут, то совершенно не понятно откуда в рамках копии он находит 15-30гб измененных блоков.

P.S. Как было ранее сказан своп в данной машине не используется.

[x2sp]

Saboteur, нет.
Дополнительная информация выше

[Alexey Dmitriev]

x2sp, сделайте полный и инкрементный бекапы машины изнутри и посмотрите что будет лежать в инкрементной копии.

[x2sp]

Alexey Dmitriev, агентный бекап показывает объем данных равный измененным - 500мб. Но данный вариант является проблемным, так как агентный бекап подразумеваем восстановление через bmr (bare metal recovery), что требует значительно больше времени.

Как я понимаю, мы имеем следующую картину:

1) В рамках первой р.к. создается avhd файл в котором происходят какие то изменения

2) По окончанию р.к. идет слияние снимка в vhd и cbt отмечает данные блоки как измененные, что в принципе верно.

Вопрос тут в сторону Hyper-v, что он пишет в vhdx за это время и как можно повлиять на его размер, если фактических данных в машине не меняется.

Ниже прошлый скриншот с агентным бекапом но включенным свопом:

[x2sp]

Alexey Dmitriev, ниже безагентный:


Т.е. видно что разница бывает в 10 - 30 раз больше при безагентном бекапе.

[Alexey Dmitriev]

x2sp, сделать бекапы со стороны hyper-v с помощью например veeam community пробовали? Если будет разница в размере бекапов - значит проблемы именно с arcserve