Есть у VMware такая хорошая и полезная штука Changed Block Tracking - отслеживает она измененные блоки дисков VM и делает правильные маленькие бэкапы быстро и эффективно.
Появилась штука CBT достаточно давно, и у Михаила Михеева информация в блоге аж от 28 декабря 2009 года. Описано там как включать и отключать эту штуку.
Естественно, это штукой на благо использует "собственное" средство резервного копирования VMware VDP. VDP я активно пользуюсь, однако в последнее время стал замечать, что бэкапы делаются долго, а их размеры для некоторых VM равны полным копиям VM. Стал грешить на CBT, проверил для VM ключик ctkEnabled на true - все в порядке. Стал искать другие закономерности в "неправильных" VM с "неправильными" бэкапами и оказалось, что всему виной Storage vMotion в моем случае под личиной SDRS.
Самое печальное, что после Storage vMotion CBT перестает работать вообще: и на первом бэкапе (что логично) и на всех последующих. Т.е. если Вы сделали первый бэкап с помощью VDP и включенным для VM CBT, потом случился Storage vMotion, то все последующие бэкапы даже в отсутствии Storage vMotion совершенно не интересуются измененными блоками. Восстановление с использованием CBT тоже становится невозможным.
Как с этим бороться:
Для начала надо понять, что нам важнее бэкап с использованием CBT или Storage vMotion.
- Если выбором будет Storage vMotion - ключик ctkEnabled=false и забыли про все плюшки CBT.
- Если беда уже случилось, и мы хотим спасти овец (использовать CBT) делаем так:
1. выключаем VM
2. удаляем все снапшоты для VM
3. отключаем CBT - ctkEnabled=false
4. удаляем *-ctk.vmdk (все *-ctk.vmdk они создаются для каждого диска VM, для которого включен CBT)
5. включаем CBT - ctkEnabled=true
6. включаем VM
7. забываем о Storage vMotion и SDRS ;(
p.s> CBT использем в том числе и Veeam, к сожалению его нет под рукой, так что проверить как такая ситуация обрабатывается Veeam (происходит ли обнуление *-ctk.vmdk после Storage vMotion) нет возможности.
