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

    Как стало известно из KB (2090639) в гипервизорах VMware ESXi версий начиная с 4.х и до актуальной при обращении командой QueryChangedDiskAreas для запроса информации о занятых дисковых секторах виртуальных дисков возвращаемое значение может быть неправильным или отсутствовать вовсе. Под риском находятся все ВМ размер vmdk диска которых превышает был менее 128 GB и в последствии увеличен. Чем это чревато — все утилиты бэкапа которые используют этот механизм (к примеру Veeam) могут создать невалидные резервные копии. Временное решение — отключить и заново включить механизм CBT для всех виртуальных машин.
    Для получения актуальной информации по теме подпишитесь на KB указанный в начале.

    P.S в новостной рассылке Veeam есть ссылка на скрипт PowerShell для отключения СBT на всех виртуальных машинах.

    Что такое CBT:Changed Block Tracking (CBT) is a VMware feature that helps perform incremental backups. VMware Data Recovery uses this technology and so can developers of backup and recovery software.

    upd: Как уточнил автор взбудоражевшей всех рассылки TheRealGostevПод риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB

    upd2: TheRealGostev продолжает исследовать проблему и публиковать новые данные и уточнения

    Проверьте бэкапы ваших виртуалок!
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 30

      0
      Я правильно понял, что с 2009 года могли создаваться невалидные резервные копии при использовании механизма CBT (который использует подавляющее большинство ПО), а заметили это только сейчас?
        0
        К сожалению, информации о том с какого времени существует проблема у меня нет.
        +1
        Временное решение — полное отключение механизма CBT для всех виртуальных машин.

        Как-то не согласуется с
        To work around this issue, disable and then enable Change Block Tracking (CBT) on the virtual machine.
          0
          Прошу прощения — упустил. Исправлю в тексте.
          0
          Интересно, как проверить валидность бэкапов в Veeam?
            0
            Для этого есть технология SureBackup
              0
              Это не совсем то.
              Оно просто запускает виртуалку в изолированном окружении и проверяет работу неких служб на ней.
              Это ни разу не гарантирует сохранность данных — у меня, допустим, сервер СУБД в котором ОС и приложения занимают 1% объема ВМ.
              Остальное — БД. В результате есть большой шанс что всё запустится, но на деле данные будут испорчены.
                0
                Я думаю что если бэкап будет поврежденным то виртуалка вообще вряд ли запустится… хотя может быть я и ошибаюсь
                  0
                  Ну почему же, всё зависит от того насколько глобально лажает эта функция.

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

                  Если наоборот — то тут всё уже зависит от конкретной ситуации. Если область с ОС попала в ошибочную область — то ВМ не запустится. Если не попала — то вполне может запуститься и пройти тесты.
                    0
                    Да, в общем пока вопросов больше чем ответов — радует что сузился радиус машин находящихся под риском.
            +4
            Привет, я автор сей новостной рассылки Veeam, взорвавшей сегодня мир судя по Twitter :)

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

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

                Update: «перешагнуть» свидетельствует в пользу 1-го предположения, но все же…
                  0
                  Про тонкие диски и рост в статье ни слова, написано лишь про расширение (extending).
                  А 'extending' в терминологии VMware означает увеличение диска администратором (vmkfstools -X).
                  +3
                  Привет всем. Мы продолжаем исследовать данную багу. Эмпирическим способом выяснили, что начальный и конечный размер диска значения не имеет. Важен размер увеличения диска: проблема только если диск увеличивается больше, чем на 128GB. Так что можно поправить пост ещё раз.
                  Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
                  Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.
                    0
                    Антон, я правильно понимаю, что в случае увеличения диска на 128+ Гб поможет (до следующего такого увеличения) «передергивание» СВТ?
                    0
                    В KB жирным выделили "strictly above 128 GB".
                      +1
                      В-общем, с многократными увеличениями понятнее не стало. Взяли на 175GB диск, увеличили на 45GB — нормально. Ещё на 45GB увеличили — CBT сломался (хотя в сумме всего на 90GB в два присеста было увеличение). В общем, без поллитры сорс кода не разобраться, а закономерности корраптов выводить исходя из тестов — дело не благодарное в такой точной науке, как бакап. Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.

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

                        Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.
                        а что по срокам? Для v7 будет доступен?
                      +1
                      1-2 недели, да для v7 будет доступен.
                        0
                        Значит, в 8 версии workaround есть, а как насчет 7? Периодически проверяю страницу патчей, но все также глухо.
                          0
                          В v7 это оказалось намного сложнее прикрутить (старая архитектура), так что хотфикс для неё займёт больше времени, чем ожидалось.
                        0
                        Антон, сегодня стала доступна 8я версия — она уже с «фиксом» или как?
                          0
                          Да, успели воткнуть в последний момент. Теперь будем детектить изменения конфигурации дисков, и резетить CBT автоматически. Но уже побитое CBT этот функционал не исправит, поэтому в целях профилактики рекомендуем скриптом зарезетить CBT на всех существующих VM однократно перед установкой v8 (если, конечно, этого уже не было сделано ранее).
                          +1
                          Вышел 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
                            0
                            В связи с такой новостью, интересно, дождемся ли мы патча на Veeam 7 B&R?
                              0
                              Ой, а он уже был зарилижен несколько недель назад, см. www.veeam.com/KB1940
                                0
                                Спасибо! Просто ожидал увидеть новость об этом в этой теме.

                          Only users with full accounts can post comments. Log in, please.