В VMware 6.5 виртуальные машины работают с файлами CTK Delta. Может ли это вызвать несогласованность снимков на уровне хранилища?
Я пока не могу комментировать, но я хотел бы добавить к ответу Стугги.
Вы спрашиваете о снимках уровня хранилища. Обычно это происходит на уровне LUN, и на самом деле они не заботятся о содержимом, которое может быть VMFS, NTFS или другой файловой системой ... они происходят на уровне блоков. Таким образом, моментальные снимки уровня хранилища не будут противоречивыми - в зависимости от того, что вы действительно спрашиваете.
Если вы, с другой стороны, спросите о снимках уровня хранилища в сочетании с решением для резервного копирования, это совсем другая история.
На самом деле есть 2 сценария:
1) Вы используете моментальные снимки уровня хранилища только для этого ... вы можете вернуться к моментальному снимку уровня хранилища и быть в определенный момент времени на уровне блоков (что вы редко хотели бы делать для VMFS LUN). В этом случае у вас не возникнет проблем с несогласованностью, однако полезность снимка более или менее ограничена либо полным сценарием аварийного восстановления, либо монтированием снимка и восстановлением отдельных файлов.
2) Вы используете моментальный снимок на уровне хранилища вместе с продуктом для резервного копирования (например, Veeam).
В этом случае - в первую очередь для правильной работы - хранилище должно поддерживаться, а решение должно быть правильно настроено.
Если это так, то у вас тоже нет проблем, потому что правильная реализация решения для резервного копирования требует, чтобы программное обеспечение резервного копирования запрашивало у Vmware создание моментального снимка всех виртуальных машин на LUN, для которых должен быть сделан моментальный снимок уровня хранилища, после чего решение для резервного копирования запрашивает подсистему хранения для создания моментального снимка уровня хранения. Это когда Vmware создает моментальный снимок, в файлы CTK записывается новый CBT ChangeId, и поэтому вся информация, необходимая для выполнения инкрементного резервного копирования из моментального снимка уровня хранения, будет присутствовать.
Это просто краткое изложение, но если вы хотите получить более точный ответ, обновите свой вопрос следующей информацией:
Файлы CTK содержат информацию о том, был ли изменен блок в VMDK (файл, содержащий фактический виртуальный диск). Это не то же самое, что файл дельты моментального снимка, который содержит фактические данные блоков, которые были изменены с момента создания моментального снимка.
Файлы CTK - это то, что позволяет VMware Changed Block Tracking, которое программное обеспечение резервного копирования использует для отслеживания того, какие блоки были изменены с момента последнего создания резервной копии, что делает инкрементное резервное копирование экспоненциально быстрее, поскольку им не нужно сравнивать блок VMDK по block до последней резервной копии, а вместо этого может просто мгновенно создать резервную копию блоков, которые помечены как измененные в файле CTK.
Как правило, эти файлы не являются проблемой, поскольку они изначально не могут вырасти очень большими (максимальный размер - это небольшой порядковый номер, умноженный на количество блоков в родительском VMDK).
Однако существует вероятность того, что эти файлы станут потерянными, что может вызвать проблемы с инкрементным резервным копированием. Я лично никогда не видел этого в производственной среде, но вы можете исправить это, выполнив следующие действия: https://kb.vmware.com/s/article/2139574