Отгремели (или еще не?) фанфары, аплодисменты и фейерверки по поводу выхода новой версии Windows. И после того, как рассеялся праздничный дым, можно спокойно заглянуть в ближайшее будущее, чтобы узнать, что же оно нам готовит. А готовит оно релиз Veeam Availability Suite 11a.

Вероятно, кто-то из вас, уважаемые читатели, следит за обзорами и анонсами уже не одну неделю - но для тех, у кого не было такой возможности, сегодня я вкратце расскажу о новых фичах Veeam Backup & Replication (а о Veeam ONE, по традиции, в следующем посте). 

Итак, вашему вниманию предлагаются:

  • Поддержка новых платформ Microsoft и VMware

  • Новые возможности для работы с облаками AWS, Microsoft Azure, Google Cloud

  • Интеграция Kasten K10 с репозиториями VBR

  • Мгновенное восстановление Instant Recovery для Nutanix AHV

  • Централизованное управление бэкапами IBM AIX и Oracle Solaris

Поддержка новых платформ

  • Microsoft Windows Server 2022 и Microsoft Windows 10 21H1 поддерживаются в качестве гостевых ОС, в качестве хостов Hyper-V. Их можно использовать для развертывания компонентов Veeam Backup & Replication, а также для бэкапа с использованием агента - в версию 11a входит Veeam Agent for Microsoft Windows 5.0.1.

ВАЖНО! Если вы планируете апгрейдить ваши репозитории на ReFS с Windows Server 2019 на Server 2022 либо хотите монтировать тома ReFS с вашего Windows Server 2019 на свежеустановленный Windows Server 2022, то во избежание проблем с ReFS Microsoft рекомендует сначала сделать вот что:

1. Задизейблить (перевести в состояние read-only) ваш диск/том ReFS.
2. Поставить апдейт, указанный в этой статье KB.
3. Вернуть в полнофункциональный режим ваш диск/том ReFS.

  • Microsoft Windows 11 также готовы поддержать, но пока это касается только пре-релизного билда. Официальная поддержка требует прохождения регрессионного тестирования релизного (GA) билда, о ней будет объявлено дополнительно, stay tuned.

  • Microsoft Azure Stack HCI version 20H2 поддерживается для host-based бэкапов ВМ на Hyper-V.

  • Поддерживаются дистрибутивы RHEL/CentOS 8.4, Ubuntu 21.04, Debian 11, SLES 15 SP3, OpenSUSE Leap 15.3, Fedora 34 - в качестве гостевых ОС, для развертывания компонентов Veeam Backup & Replication, а также для бэкапа с использованием агента - в версию 11а входит Veeam Agent for Linux 5.0.1. Подробнее о том, какие дистрибутивы поддерживаются для какого компонента, можно прочитать в системных требованиях

  • Поддерживается VMware Cloud Director 10.3. Кроме того, в версии v11a можно развернуть Veeam Self-Service Backup Portal в инфраструктуре, где работает несколько серверов VMware Cloud Director.

  • Поддержка VMware VMC 15, включая выполнение операций восстановления ВМ на сетях NSX-T 3.0, которые используют VDS 7.0 вместо свичей N-VDS.

  • VMware vSphere 7.0 U3 также готовы поддержать, но пока это касается только пре-релизного билда. Официальная поддержка требует прохождения регрессионного тестирования релизного (GA) билда, о ней будет объявлено дополнительно.

Новые возможности для работы с облаками AWS, Microsoft Azure, Google Cloud

Вот что ожидается в релизе v11a:

  • Veeam Backup for AWS – нативная защита облачных сервисов и систем: теперь и для Amazon Elastic File System (Amazon EFS), и для Microsoft Azure SQL Databases.

  • Эффективное использование хранилищ: новые возможности для работы с Amazon S3 Glacier и Glacier Deep Archive, Microsoft Azure Archive Storage, Google Cloud Archive позволяют значительно снизить расходы на хранение резервных копий.

  • Больше гибкости и безопасности: благодаря интеграции с AWS Key Management Service (KMS) и Azure Key Vault, а также новой функциональности контроля доступа согласно ролям (Role-Based Access Control) теперь работа станет еще более безопасной, а управление доступом - более гибким.

  • Поддержка Google Cloud Platform (GCP): задачи по защите GCP теперь можно решать непосредственно в консоли Veeam Backup & Replication. Кроме того, теперь можно восстанавливаться в виртуальную машину в GCE из бэкапа на уровне образа, созданного решением Veeam как для виртуальной, так и для физической машины. 

Таким образом, бэкап и восстановление с Veeam теперь поддержаны для всех трех основных облачных платформ.

Интеграция Kasten K10 с репозиториями VBR

 Резервное копирование и восстановление для контейнеров не всегда легко и просто выполнить, если не учитывать их особенности. Грядущая версия Kasten K10 v4.5 будет уметь сохранять бэкапы кластеров Kubernetes, использующих VMware persistent volumes (PV), в репозиторий Veeam Backup & Replication. Все это благодаря тому, что в Kasten K10 есть дополнительные настройки местоположения (location profile), где и можно указать репозиторий Veeam Backup & Replication v11a в качестве целевого. Ну и, конечно, для удобства управления такими бэкапами в консоли Veeam будут работать соответствующие представления.

Мгновенное восстановление Instant Recovery для гипервизора Nutanix AHV

В новейшей версии Veeam Backup for Nutanix AHV v3 реализована любимая многими возможность мгновенного восстановления - теперь и из любого бэкапа Veeam (будь это физическая или виртуальная машина, на земле или в облаке) в виртуальную машину на платформе Nutanix AHV. 

Важно! Требует версии Nutanix AHV 6.0 и выше.

Централизованное управление для защиты IBM AIX и Oracle Solaris

Теперь можно контролировать работу заданий Veeam Agents для IBM AIX и Oracle Solaris из консоли Veeam - для этого задействуются protection-группы, имеющие тип “Computers with pre-installed agents”. Кроме того, можно использовать Veeam Backup Enterprise Manager, чтобы выполнять восстановление отдельных файлов из бэкапов, созданных такими заданиями.

Поддержка Red Hat® Virtualization (RHV) 

Veeam Backup & Replication v11a поддерживает интегрированный бэкап для гипервизора Red Hat Virtualization (RHV) версии 4.4.8 и выше. Те, кто работает с этим гипервизором, смогут эффективно бэкапить свои ВМ-ки с использованием нативного механизма отслеживания измененных блоков. 

И многое, многое другое

Вот неполный список других улучшений и обновлений (полный можно найти здесь):

  • Veeam Continuous Data Protect (CDP): улучшена производительность, понижена нагрузка на CPU в ходе начальной синхронизации, усовершенствован мониторинг и отчеты о проблемах в конвейере репликации, налажена совместимость с рядом реализаций VMware Virtual Volumes (vVOLs), избавились от ограничений на размер журнала I/O для хранилищ на VMware vVOLs и VMware vSAN.

  • Гибкие возможности для объектных хранилищ: чтобы уменьшить число объектов, можно настроить задания бэкапа на работу с блоками по 8 MB. Для отображения соответствующей опции надо создать значение UIShowLegacyBlockSize (DWORD, 1) в ключе реестра ‘HKLM\SOFTWARE\Veeam\Veeam Backup and Replication’ на сервере VBR. 

Примечание: Помните, что при этом увеличится размер инкрементальных бэкапов. И не забудьте про создание active full backup.

  • Интеграция с VMware vSAN: в планировщике задач теперь можно выставить конкретное пороговое значение для максимального количества открытых снапшотов ВМ на датасторах vSAN. По умолчанию оно равно 32. Задать нужный порог можно с помощью значения VSANMaxSnapshotsNum (DWORD) в ключе реестра ‘HKLM\SOFTWARE\Veeam\Veeam Backup and Replication’ на сервере VBR.

Полный список улучшений и обновлений, как было сказано, можно найти здесь. Если вы настроены на самостоятельное знакомство с новой версией в виде RTM-билда, то он также доступен на этой странице. Это программа носит название Early Availability (предварительной доступности) - но данный билд поддерживается нашей службой Customer Support как обычный релиз. 

Апгрейд поддерживается для Veeam Backup & Replication 9.5 Update 4b (билд 9.5.4.2866) и выше. После апгрейда номер билда изменится на 11.0.1.1261. И, конечно, перед апгрейдом обязательно изучите соответствующий раздел в Release Notes (см. стр.33).

ВАЖНО! Если у вас на том же сервере установлен Veeam Backup for Microsoft Office 365 (VBO365), то до начала установки Veeam Backup & Replication 11a убедитесь, что версия VBO365 у вас 5.0.3.1033 или выше.

Комментарии (9)


  1. den_neo
    12.10.2021 13:48

    Добрый день.
    Не увидел обещанного обновления для бекапов отдельно SQL-баз.
    Очень нужная вещь, которая пока не доступна в VBR.


    1. polarowl Автор
      12.10.2021 22:14

      Насколько я знаю, в 11а эта фича не входит - но ваш голос в пользу ее реализации в будущих версиях учтён коллегами из product management.
      Если же хочется продублировать такой запрос как непосредственно ваш feature request, это можно сделать на форуме, выбрав нужную ветку.


    1. t08
      20.10.2021 16:23

      Unitrends умеет бекапить MS SQL базы отдельно, так же Exchange базы и отдельно почтовые ящики.


  1. FlyingDutchman
    13.10.2021 10:21

    Бэкап Оракловских баз с помощью RMAN + Veeam Plugin так и будет продолжать работать лишь при условии соединения к базе вида "target /" и будет падать при "target sys@<db_service>"? Мы так и не смогли победить этот баг с этой дополнительной, непонятной (и ненужной) callback сессией, которую Veeam Plugin пытается установить с Оракловской базой в процессе бэкапа. И Veeam Support не помог, разве что пытался убедить нас перестать использовать TNS-соединение и перейти на локальный коннект к базе. В итоге пришлось отказаться от Veeam.


    1. sysmetic
      22.10.2021 11:30

      Есть две причины, по которым это соединение нужно:

      1) Сессия соединения плагин-менеджера к базе данных нужна, чтобы собрать метаданные базы, потом записать их в метаданные бекапа, а затем, например, иметь возможность нормально восстанавливать через VEOR.
      2) мы подключаемся к базе, чтобы мониторить прогресс-бар РМАНа.

      То есть это часть дизайна нашего продукта, а не баг, и это описано в документации: https://helpcenter.veeam.com/docs/backup/plugins/rman_plugin_permissions.html?ver=110


      1. FlyingDutchman
        22.10.2021 11:38

        Если эта часть дизайна не работает или работает лишь при определенных условиях, зачастую несовместимых с клиентской архитектурой или безопасностью - то это всё же баг, а не фича. Ну или недоделка, если это звучит лучше для вас.

        Вернемся к разговору когда научитесь поддерживать соединения через TNS, что является стандартом для Оракловских соединений (локальные соединения "/" как раз являются частностью). Но очень слабо верится, что это получится, учитывая нынешнюю архитектуру Оракловского плагина.


        1. PetrM1989
          07.11.2021 16:43

          Здравствуйте!

          Очень интересный фидбэк. А есть ли возможность уточнить почему локальные соединения "/" являются частностью? Дело в том, что я не очень часто встречал аналогичные вопросы от других клиентов и возможно чего-то недопонимаю, буду очень признателен, если дадите больше деталей :) Если какая-то есть сслка на бест практисес и т.д., то буду признателен втройне!)

          Ну и конечно, было бы очень здорово понять чуть глубже чем именно вас не устраивет текущая архитектура плагина? Я так понимаю, что дело все в том же локальном соединении? Если да, то по какой именно причине в вашей инфраструктуре это запрещено?


          1. FlyingDutchman
            07.11.2021 21:40

            Всё очень подробно расписано в одном из тикетов, созданном в VEEAM Support, не вижу смысла тащить сюда многостраничные выкладки.

            Наверное, когда есть один хост с одной базой - то локальный коннект будет работать на ура. Но когда количество баз данных исчисляется тысячами, то backup стратегия отходит от локальных коннектов, дрейфуя в сторону централизованных скрипт-серверов, которые используют удаленные соединения к базам данных.

            Да и просто бэкапить RAC базы с помощью локального коннекта - это очень так себе затея. Представьте, что у вас есть RAC бд с 8ю инстансами, запущенными на разных хостах одного Exadata кластера. Подключаясь к каждому инстансу локально, вы в итоге сбэкапите одну и ту же базу 8 раз. А если у вас сотни таких баз? Напрасная трата ресурсов и дискового пространства. А так - на одном из инстансов запущен сервис со специальным кодовым именем, к которому RMAN присоединяется, используя TNSNAMES. База бэкапится всего один раз, плюс есть необходимая гибкость в оперировании ресурсами бд, хоста и кластера - можно держать бэкап-сервис запущенным на наименее нагруженном инстансе/хосте и легко отключать/переносить его при возникающей необходимости.


            1. PetrM1989
              30.11.2021 00:24

              Спасибо!

              Аргумент про RAC понятен вполне. По идее скрипт-сервер может вызвать скрипт удаленно, а сам скрпт уже отработает на сервере с базой, используя локальный конект. Но описанную проблему с RAC это опять же не решит вообще. Возьмем на заметку ваш реквест, большое спасибо!

              И еще пара вопросов:

              1) Можете, пожалуйста, дать номер тикета?

              2) (если возможно) как-то расшарить примеры скриптов, которые вы используете.

              Заранее Спасибо!