@lostinfuture27 окт 2014 в 08:09

VMware сломала механизм CBT для резервного копирования виртуальных машин

1 мин

17K

Виртуализация *

+10

Комментарии 30

@larrabee 27 окт 2014 в 10:34

Я правильно понял, что с 2009 года могли создаваться невалидные резервные копии при использовании механизма CBT (который использует подавляющее большинство ПО), а заметили это только сейчас?

@lostinfuture 27 окт 2014 в 10:39

К сожалению, информации о том с какого времени существует проблема у меня нет.

@blind_oracle 27 окт 2014 в 10:51

Временное решение — полное отключение механизма CBT для всех виртуальных машин.

Как-то не согласуется с

To work around this issue, disable and then enable Change Block Tracking (CBT) on the virtual machine.

@lostinfuture 27 окт 2014 в 10:57

Прошу прощения — упустил. Исправлю в тексте.

@blind_oracle 27 окт 2014 в 12:38

Интересно, как проверить валидность бэкапов в Veeam?

@lostinfuture 27 окт 2014 в 12:58

Для этого есть технология SureBackup

@blind_oracle 27 окт 2014 в 13:07

Это не совсем то.
Оно просто запускает виртуалку в изолированном окружении и проверяет работу неких служб на ней.
Это ни разу не гарантирует сохранность данных — у меня, допустим, сервер СУБД в котором ОС и приложения занимают 1% объема ВМ.
Остальное — БД. В результате есть большой шанс что всё запустится, но на деле данные будут испорчены.

@lostinfuture 27 окт 2014 в 13:10

Я думаю что если бэкап будет поврежденным то виртуалка вообще вряд ли запустится… хотя может быть я и ошибаюсь

@blind_oracle 27 окт 2014 в 13:20

Ну почему же, всё зависит от того насколько глобально лажает эта функция.

Если она выдаёт просто избыточные данные — мол показывает что изменились некие блоки, хотя на деле они не менялись — не сломается вообще ничего, просто бэкапы станут толще.

Если наоборот — то тут всё уже зависит от конкретной ситуации. Если область с ОС попала в ошибочную область — то ВМ не запустится. Если не попала — то вполне может запуститься и пройти тесты.

@lostinfuture 27 окт 2014 в 13:25

Да, в общем пока вопросов больше чем ответов — радует что сузился радиус машин находящихся под риском.

@TheRealGostev 27 окт 2014 в 13:01

Привет, я автор сей новостной рассылки Veeam, взорвавшей сегодня мир судя по Twitter :)

Спешу сообщить, что перевод KB в посту выше неверен. Под риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB. То есть не так всё плохо. Увеличением диска чаще балуются мелкие клиенты, так как у большинства крупных используются стандартизированные типоразмеры дисков.

Комментировать более сегодня не смогу, так как в самолётах до вечера. Спасибо за внимание!

@lostinfuture 27 окт 2014 в 13:04

Благодарю за уточнение, перенес в новость.

@navion 27 окт 2014 в 17:39

Ну да, мелкие не покупают Veeam, так что хер бы с ними.

@maotm 28 окт 2014 в 05:34

Не совсем понятно, о каком увеличении идет речь: о thin-дисках, скажем, размером 150Гб, но реально занимающем изначально меньший объем, или если мы расширяем размер диска со 120 до 150Гб, к примеру?

Update: «перешагнуть» свидетельствует в пользу 1-го предположения, но все же…

@navion 28 окт 2014 в 08:52

Про тонкие диски и рост в статье ни слова, написано лишь про расширение (extending).
А 'extending' в терминологии VMware означает увеличение диска администратором (vmkfstools -X).

@TheRealGostev 29 окт 2014 в 12:27

Привет всем. Мы продолжаем исследовать данную багу. Эмпирическим способом выяснили, что начальный и конечный размер диска значения не имеет. Важен размер увеличения диска: проблема только если диск увеличивается больше, чем на 128GB. Так что можно поправить пост ещё раз.
Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.

@Fanta 29 окт 2014 в 19:18

Антон, я правильно понимаю, что в случае увеличения диска на 128+ Гб поможет (до следующего такого увеличения) «передергивание» СВТ?

@TheRealGostev 29 окт 2014 в 20:13

Да, правильно!

@navion 29 окт 2014 в 19:22

В KB жирным выделили "strictly above 128 GB".

@TheRealGostev 29 окт 2014 в 20:30

В-общем, с многократными увеличениями понятнее не стало. Взяли на 175GB диск, увеличили на 45GB — нормально. Ещё на 45GB увеличили — CBT сломался (хотя в сумме всего на 90GB в два присеста было увеличение). В общем, без ~~поллитры~~ сорс кода не разобраться, а закономерности корраптов выводить исходя из тестов — дело не благодарное в такой точной науке, как бакап. Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.

Также тесты подтвердили, что резет CBT достаточен, то есть полный бакап не нужен (по крайней мере в случае с Veeam B&R). Бакапы пролечиваются на первом проходе сами по себе, благодаря тому, что джоба физически весь сорсовый диск обсчитывает в отсутствии CBT, и довозит инкрементом всё, что возилось из-за косяка.

@Fanta 29 окт 2014 в 20:42

Спасибо за инфо!

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

а что по срокам? Для v7 будет доступен?

@TheRealGostev 30 окт 2014 в 12:56

1-2 недели, да для v7 будет доступен.

@maotm 12 ноя 2014 в 05:22

Значит, в 8 версии workaround есть, а как насчет 7? Периодически проверяю страницу патчей, но все также глухо.

@TheRealGostev 12 ноя 2014 в 21:32

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

@Fanta 6 ноя 2014 в 14:54

Антон, сегодня стала доступна 8я версия — она уже с «фиксом» или как?

@TheRealGostev 12 ноя 2014 в 00:50

Да, успели воткнуть в последний момент. Теперь будем детектить изменения конфигурации дисков, и резетить CBT автоматически. Но уже побитое CBT этот функционал не исправит, поэтому в целях профилактики рекомендуем скриптом зарезетить CBT на всех существующих VM однократно перед установкой v8 (если, конечно, этого уже не было сделано ранее).

@navion 5 дек 2014 в 19:20

Вышел ESXi 5.1 U3 с исправлением для CBT:

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

@maotm 6 дек 2014 в 18:40

В связи с такой новостью, интересно, дождемся ли мы патча на Veeam 7 B&R?

@TheRealGostev 9 дек 2014 в 14:17

Ой, а он уже был зарилижен несколько недель назад, см. www.veeam.com/KB1940

@maotm 9 дек 2014 в 16:32

Спасибо! Просто ожидал увидеть новость об этом в этой теме.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий