Comments 30
Я правильно понял, что с 2009 года могли создаваться невалидные резервные копии при использовании механизма CBT (который использует подавляющее большинство ПО), а заметили это только сейчас?
Временное решение — полное отключение механизма CBT для всех виртуальных машин.
Как-то не согласуется с
To work around this issue, disable and then enable Change Block Tracking (CBT) on the virtual machine.
Интересно, как проверить валидность бэкапов в Veeam?
Для этого есть технология SureBackup
Это не совсем то.
Оно просто запускает виртуалку в изолированном окружении и проверяет работу неких служб на ней.
Это ни разу не гарантирует сохранность данных — у меня, допустим, сервер СУБД в котором ОС и приложения занимают 1% объема ВМ.
Остальное — БД. В результате есть большой шанс что всё запустится, но на деле данные будут испорчены.
Оно просто запускает виртуалку в изолированном окружении и проверяет работу неких служб на ней.
Это ни разу не гарантирует сохранность данных — у меня, допустим, сервер СУБД в котором ОС и приложения занимают 1% объема ВМ.
Остальное — БД. В результате есть большой шанс что всё запустится, но на деле данные будут испорчены.
Я думаю что если бэкап будет поврежденным то виртуалка вообще вряд ли запустится… хотя может быть я и ошибаюсь
Ну почему же, всё зависит от того насколько глобально лажает эта функция.
Если она выдаёт просто избыточные данные — мол показывает что изменились некие блоки, хотя на деле они не менялись — не сломается вообще ничего, просто бэкапы станут толще.
Если наоборот — то тут всё уже зависит от конкретной ситуации. Если область с ОС попала в ошибочную область — то ВМ не запустится. Если не попала — то вполне может запуститься и пройти тесты.
Если она выдаёт просто избыточные данные — мол показывает что изменились некие блоки, хотя на деле они не менялись — не сломается вообще ничего, просто бэкапы станут толще.
Если наоборот — то тут всё уже зависит от конкретной ситуации. Если область с ОС попала в ошибочную область — то ВМ не запустится. Если не попала — то вполне может запуститься и пройти тесты.
Привет, я автор сей новостной рассылки Veeam, взорвавшей сегодня мир судя по Twitter :)
Спешу сообщить, что перевод KB в посту выше неверен. Под риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB. То есть не так всё плохо. Увеличением диска чаще балуются мелкие клиенты, так как у большинства крупных используются стандартизированные типоразмеры дисков.
Комментировать более сегодня не смогу, так как в самолётах до вечера. Спасибо за внимание!
Спешу сообщить, что перевод KB в посту выше неверен. Под риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB. То есть не так всё плохо. Увеличением диска чаще балуются мелкие клиенты, так как у большинства крупных используются стандартизированные типоразмеры дисков.
Комментировать более сегодня не смогу, так как в самолётах до вечера. Спасибо за внимание!
Не совсем понятно, о каком увеличении идет речь: о thin-дисках, скажем, размером 150Гб, но реально занимающем изначально меньший объем, или если мы расширяем размер диска со 120 до 150Гб, к примеру?
Update: «перешагнуть» свидетельствует в пользу 1-го предположения, но все же…
Update: «перешагнуть» свидетельствует в пользу 1-го предположения, но все же…
Про тонкие диски и рост в статье ни слова, написано лишь про расширение (extending).
А 'extending' в терминологии VMware означает увеличение диска администратором (vmkfstools -X).
А 'extending' в терминологии VMware означает увеличение диска администратором (vmkfstools -X).
Привет всем. Мы продолжаем исследовать данную багу. Эмпирическим способом выяснили, что начальный и конечный размер диска значения не имеет. Важен размер увеличения диска: проблема только если диск увеличивается больше, чем на 128GB. Так что можно поправить пост ещё раз.
Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.
Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.
Антон, я правильно понимаю, что в случае увеличения диска на 128+ Гб поможет (до следующего такого увеличения) «передергивание» СВТ?
В KB жирным выделили "strictly above 128 GB".
В-общем, с многократными увеличениями понятнее не стало. Взяли на 175GB диск, увеличили на 45GB — нормально. Ещё на 45GB увеличили — CBT сломался (хотя в сумме всего на 90GB в два присеста было увеличение). В общем, без поллитры сорс кода не разобраться, а закономерности корраптов выводить исходя из тестов — дело не благодарное в такой точной науке, как бакап. Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.
Также тесты подтвердили, что резет CBT достаточен, то есть полный бакап не нужен (по крайней мере в случае с Veeam B&R). Бакапы пролечиваются на первом проходе сами по себе, благодаря тому, что джоба физически весь сорсовый диск обсчитывает в отсутствии CBT, и довозит инкрементом всё, что возилось из-за косяка.
Также тесты подтвердили, что резет CBT достаточен, то есть полный бакап не нужен (по крайней мере в случае с Veeam B&R). Бакапы пролечиваются на первом проходе сами по себе, благодаря тому, что джоба физически весь сорсовый диск обсчитывает в отсутствии CBT, и довозит инкрементом всё, что возилось из-за косяка.
1-2 недели, да для v7 будет доступен.
Антон, сегодня стала доступна 8я версия — она уже с «фиксом» или как?
Да, успели воткнуть в последний момент. Теперь будем детектить изменения конфигурации дисков, и резетить CBT автоматически. Но уже побитое CBT этот функционал не исправит, поэтому в целях профилактики рекомендуем скриптом зарезетить CBT на всех существующих VM однократно перед установкой v8 (если, конечно, этого уже не было сделано ранее).
Вышел ESXi 5.1 U3 с исправлением для CBT:
www.vmware.com/support/vsphere5/doc/vsphere-esxi-51u3-release-notes.html
When you use backup software, the list of allocated disk sectors returned might be incorrect and the incremental backups might appear to be corrupt or missing
When you use backup software that uses the Virtual Disk Development Kit (VDDK) API call QueryChangedDiskAreas(), the list of allocated disk sectors returned might be incorrect and the incremental backups might appear to be corrupt or missing. A message similar to the following is written to vmware.log:
DISKLIB-CTK: Resized change tracking block size from XXX to YYY
For more information, see KB 2090639.
This issue is resolved in this release.
www.vmware.com/support/vsphere5/doc/vsphere-esxi-51u3-release-notes.html
В связи с такой новостью, интересно, дождемся ли мы патча на Veeam 7 B&R?
Ой, а он уже был зарилижен несколько недель назад, см. www.veeam.com/KB1940
Sign up to leave a comment.
VMware сломала механизм CBT для резервного копирования виртуальных машин