Вышла новая версия Veeam Backup & Replication v8 (платная и бесплатная редакции)


    На прошлой неделе вышла новая версия Veeam Backup & Replication v8, и в данной статье я опишу новые функциональные возможности, которые в ней появились, а также что из этого нового функционала доступно в бесплатной редакции продукта.

    Поддержка аппаратных снапшотов NetApp


    В Veeam Backup & Replication v8.0 стало возможным создание резервных копий и реплик виртуальных машин на основе аппаратных снимков СХД NetApp. Аналогичный подход уже был реализован в предыдущих версиях для таких сорсных систем хранения, как HP StoreServ (3PAR), HP StoreVirtual (LeftHand / P4000) и HP StoreVirtual VSA.


    Напомню о преимуществах аппаратных снапшотов СХД. Технология аппаратных снимков дисков уже давно обозначается экспертами как технология, способная кардинально снизить RPO (максимальное время, в течение которого новые или измененные данные остаются незащищенными от сбоя, то есть не продублированными в резервную копию). Суть технологии заключается в том, что СХД самостоятельно, с настраиваемой периодичностью, создает снимки своих дисков. Поскольку разработчики СХД лучше кого бы то ни было знают устройство своих дисков на низком уровне, то, очевидно, что и создание снимков таких дисков они могут сделать с максимальным уровнем эффективности и производительности – то есть с наименьшим воздействием на продуктивную систему. Поэтому аппаратные снапшоты – хороший источник резервных копий.

    Вместе с тем, сами по себе, аппаратные снапшоты не могут рассматриваться как надежный способ защиты данных от сбоев, прежде всего потому, что снапшоты располагаются на том же СХД, который они “резервируют”. В случае сбоя на СХД, с высокой вероятностью произойдет разрушение как оригинальных данных, так и их снапшотов. Для того, чтобы обеспечить надлежащую надежность защиты данных от сбоев, необходимо перемещать резервные копии данных в другое расположение относительно их исходного места хранения.

    Кроме того, у снапшотов есть еще ряд недостатков:
    • аппаратные снапшоты используют полезную емкость оригинального диска, и их суммарный максимальный размер диктуется не только требованиями защиты данных, но «контр»-требованиями бизнес приложений продуктивной системы. Следовательно, второй актуальной задачей является своевременное удаление старых снапшотов. Более того, из-за особенностей применяемых алгоритмов, наличие большого количества старых снапшотов в ряде случаев может замедлять или даже приводить к сбоям в работе некоторых приложений, данные которых располагаются на СХД. Veeam Backup & Replication позволяет просто решить и эту задачу, так как «держит снапшот» на СХД только до тех пор, пока его данные не перемещены в резервную копию, после чего снапшот автоматически удаляется.
    • процедура восстановления из аппаратного снапшота не гранулярна (при необходимости восстановить отдельный файл на хранилище, в результате восстановления диска из аппаратного снимка, все хранилище целиком “перемещается в прошлое” и последние изменения на диске теряются),
    • аппаратный снапшот может оказаться уровня «crash-consistent» — в виду того, что СХД может иметь ограничения по Application Aware резервному копированию, и оно может создавать резервную копию без предварительного сброса буферов приложений в памяти на диск, так как в общем случае аппаратура СХД не имеет полной информации о характере данных (о типе операционной системы, о типе дисков: виртуальные или физические диски, о виде приложений и т.д.), хранящихся на нем.

    Как следствие из вышеперечисленного, вполне разумно объединить функционал продукта резервного копирования и функционал аппаратных снапшотов, встроенный в распространенные СХД, так как они хорошо дополняют друг друга.

    Подробнее о поддержку NetApp можно прочитать в нашей статье на Хабре «Поддержка аппаратных снапшотов СХД NetApp в Veeam Backup & Replication v8»

    Поддержка EMC Data Domain Boost


    Благодаря интеграции Veeam Backup & Replication v8 и EMC Data Domain Boost значительно ускорился процесс построения полных синтетических резервных копий (когда каждая новая инкрементальная или дифференциальная копии сразу же используются для перепостроения полной копии данных в хранилище, что значительно уменьшает время восстановления), а также процесс резервного копирования в целом. Это стало возможным за счет продвинутого функционала дедупликации EMC Data Domain Boost:
    • во-первых, процесс резервного копирования ускоряется за счет применения технологии дедупликации на обеих сторонах при передаче данных через сеть (количество физически передаваемых данных существенно уменьшается),
    • во-вторых, построение полных синтетических резервных копий в хранилище с включенной встроенной дедупликацией происходит быстрее, так как данные на диске перемещаются логически, но не физически.

    Например, в одном проведенном нами эксперименте по созданию полной синтетической копии тестовой виртуальной машины, время, затраченное на выполнение задания, составило менее 11,5 минут при запуске с EMC Data Domain Boost, и почти 3 часа при запуске задания с выключенной дедупликацией. Разница в скорости составила около 15 раз!


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

    И даже, если вы предпочитаете обычный полный бэкап синтетическому, вы получите выигрыш за счет дедупликации сетевого трафика: блоки данных, которые уже ранее передавались на сторону хранилища, в дальнейших полных копиях повторно передаваться через сеть не будут. Это хорошо видно на двух картинках ниже (они отражают загрузку сети при построении первой инкрементальной копии). На картинке слева дедупликация трафика включена (EMC Data Domain Boost), а на правой — выключена.


    Что лучше: синтетический или обычный полный бэкап?

    Поскольку EMC Data Domain обладает отличной встроенной дедупликацией, то создание множества полных копий не приводит к перерасходу дискового пространства, так как повторяющиеся блоки (а их большинство) разных полных резервных копий хранятся в единственном экземпляре. При этом наличие полной резервной копии позволяет минимизировать время восстановления данных после сбоя (RTO), ибо не нужно искать последнюю версию данных по многочисленным инкрементальным копиям.

    С точки зрения восстановления последнего состояния системы синтетическая копия и обычная полная копия одинаковы. Однако возможны ситуации, когда нужно откатиться на большее время в прошлое (скажем, когда в бэкап попал поврежденный файл, или повреждена сама резервная копия) — и тогда вариант цепочки полных копий обладает неоспоримым преимуществом перед вариантом с синтетической копией.

    Поэтому, отвечая на вопрос «Что лучше?», можно утверждать, что в случае с EMC Data Domain с включенной дедупликацией можно отдать предпочтение цепочке полных резервных копий (если, конечно, нет противопоказаний с точки зрения нагрузки на виртуальную инфраструктуру, так как полный проход потребляет значительно больше ресурсов, чем инкрементальный).

    Настройка EMC Data Domain Boost в Veeam Backup & Replication v8

    В мастере создания репозитория появится шаг настройки EMC Data Domain в качестве целевого хранилища.


    При записи бэкапов на EMC Data Domain есть возможность использовать опцию «Fibre Channel», что позволяет снять нагрузку с LAN.

    Новинки в серии инструментов Veeam Explorers


    Серия инструментов для гранулярного восстановления объектов приложений Veeam Explorers снова расширяется – в новой версии доступны Veeam Explorer for Microsoft Active Directory и Veeam Explorer for Microsoft SQL Server, а также дополненный новыми возможностями Veeam Explorer for Microsoft Exchange. Последний теперь умеет восстанавливать объекты после так называемого жёсткого удаления (hard deletion). То есть, например, теперь можно восстановить те письма, которые пользователь удалил “без возможности восстановления” (через SHIFT+DEL в Outlook).

    Администраторы баз данных смогут восстанавливать базы из резервной копии SQL сервера, не поднимая его, а администратору Active Directory для восстановления учетной записи компьютера из OU нужно будет всего лишь указать, какой резервной копией домен-контроллера надо воспользоваться, или же ввести путь к файлу базы NTDS.DIT. Особо отмечу, что инструменты серии Veeam Explorers доступны во всех редакциях, включая бесплатную “Free Edition”.

    Подробнее о новых инструментах семейства Veeam Explorers и их возможностях можно узнать из статьи на Хабре «Что будет нового в Veeam Backup & Replication v8: Veeam Explorer for Active Directory и Veeam Explorer for Microsoft SQL Server».

    Поддержка облачных хранилищ с помощью Veeam Cloud Connect


    Veeam Cloud Connect – это новый компонент решения Veeam Backup & Replication, который, как ожидается, поможет пользователям быстро и безопасно, используя SSL, осуществлять передачу данных сервис-провайдерам, не прибегая к VPN. Возможности, которые предоставляют сервис-провайдеры и Veeam Cloud Connect, избавляют от необходимости дополнительных трат на создание удаленной площадки и выделенных репозиториев для хранения резервных копий.

    Новые возможности репликации


    В версии Veeam Backup & Replication v8 доступны следующие новые возможности репликации:
    • WAN-акселерация в процессе репликации (ранее WAN-акселерация работала только в режиме создания и передачи резервных копий, а в процессе репликации не применялась);
    • планирование переключения на реплику — можно создать сценарий для процесса переключения, то есть сгруппировать виртуальные машины, которые будут участвовать в переключении, задать для них порядок запуска, настроить таймер запуска и другие параметры;
    • плановое переключение реплик (не путать с планированием, т.е. с созданием сценария) – теперь можно задать время, когда исходная виртуальная машина должна быть выключена, а реплика включена; это удобно, например, для сервисного обслуживания.

    Подробнее о новых возможностях репликации можно почитать в статье на Хабре «Новые возможности Veeam Backup & Replication v8.0: усовершенствованная репликация».

    Автоматический контроль интенсивности операций чтения/записи


    В Veeam Backup & Replication v8.0 реализован метод автоматического контроля за интенсивностью операций чтения/записи Backup I/O Control. Резервное копирование – ресурсоемкий процесс, который может поглотить существенную долю ресурсов продуктивной системы, причем так, что это могут заметить ее пользователи, что снизит их производительность труда. Поэтому в версии v8 Veeam B&R умеет самоограничиваться — вам надо лишь задать допустимое значение для datastore latency (IOPS) и задать оптимальное для вашей инфраструктуры сочетание параметров, которое обеспечит максимальную производительность процесса резервного копирования при заданной допустимой нагрузке на работу продуктивной сети компании.

    Подробнее о механизме автоматического контроля рассказывается в статье на Хабре «Новые возможности Veeam Backup & Replication v8.0: автоматический контроль интенсивности операций чтения/записи»

    Что нового в бесплатной редакции


    Бесплатная версия продукта позволяет реализовывать базовые сценарии резервного копирования, характерные для некритических ресурсов сети, для домашних пользователей, или совсем небольших компаний. Полный обзор возможностей бесплатной версии можно прочитать в этой статьей на Хабре "Veeam Backup Free Edition v7 – обзор новой версии". В целом бесплатная версия имеет ряд ограничений, например:
    • Только полный бэкап, только отдельных виртуальных машин и только в режиме ручного запуска, без расписания;
    • Нет возможности запускать забэкапленные виртуальные машины прямо из репозитория резервных копий;
    • Нет поддержки API для скриптинга.

    В таблице ниже показано, какой новый функционал доступен в бесплатной редакции Veeam Backup v8.0 Free Edition. Полное описание всех возможностей бесплатной редакции можно найти здесь на сайте.
    Описанный выше новый функционал, который включен в состав бесплатной редакции “Free Edition”:
    Новый функционал Есть в Free Edition
    Veeam Explorer for Microsoft Active Directory Да*
    Veeam Explorer for Microsoft SQL Да*
    Поддержка аппаратных снимков NetApp Нет
    Поддержка EMC Data Domain Boost Нет
    Репликация Нет
    Автоматический контроль интенсивности операций чтения/записи Нет

    *об ограничениях для бесплатной версии см. здесь.

    Дополнительные ссылки


    Veeam Software
    134.88
    Продукты для резервного копирования информации
    Share post

    Comments 15

      +1
      Тема бекапов актуальна, спасибо за пост. Но я не смог осилить вашу первую картинку-инфорграфику.
        0
        Можно ли 8-ю версию поставить на отдельный сервер и для тестов делать бэкапы существующих ESXi, с которыми уже трудится Veeam 7?
          +1
          Да, именно так и рекомендуем.
            0
            C ESXi это, скорее всего, нормально сработает. Главное — разнести джобы по времени, дергать их исключительно по очереди, чтобы не было «драки» за снятие/удаление снэпшотов с машин и т.д.

            А вот с Hyper-V мы не рекомендуем так делать из-за архитектурных особенностей в реализации работы со снапшотами томов с виртуальными машинами.
              0
              спасибо!
            0
            Дуров, верни стенуВерните NFR лицензии!
              0
              А то будем мучаться от багов ломанной veComLic.dll и писать про вас всякое :-P
                +1
                Гранд мерси, теперь по ссылке дают ключ для восьмёрки!
                0
                > процедура восстановления из аппаратного снапшота не гранулярна (при необходимости восстановить отдельный файл на хранилище, в результате восстановления диска из аппаратного снимка, все хранилище целиком “перемещается в прошлое” и последние изменения на диске теряются),

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

                > аппаратные снапшоты используют полезную емкость оригинального диска

                Да, но крайне экономно. А вот вынесенные наружу они начинают использовать огромный объем, пусть и вторичного хранилища для резервных копий, но — огромный, так как становятся не differential, а full copy/

                > может замедлять или даже приводить к сбоям в работе некоторых приложений

                Это не проблема «аппаратных снэпшотов», а проблема этих «некоторых приложений», не так ли? Каких, кстати?

                > снапшоты не могут рассматриваться как надежный способ защиты данных от сбоев, прежде всего потому, что снапшоты располагаются на том же СХД

                Не «прежде всего», а «только лишь потому, что».
                Зато у них есть большие преимущества, прежде всего то, что восстановление с них происходит быстро, быстрее любого другого варианта резервной копии. Кроме того, они лежат на хранилище с очень высокой надежностью его самого по себе, вдобавок, они занимают на primary storage минимально возможное место, и, наконец, мы не зависим от сторонних решений при восстановлении, от отказов вторичного стораджа, канала передачи данных до него, багов ПО Veeam, и так далее.
                Видите, сколько плюсов на один «минус»?
                  0
                  1. SnapRestore требует NFS, на блочном сторадже (около 50% для NetApp + VMware) не работает.
                  2. Как бы экономно не использовали, но используют. Причём используют дорогущий production FAS, а не больно какой копеечный JBOD забитый толстыми SATA… речь об этом.
                  3. Согласен, нужны пояснения, что здесь имелось ввиду.
                  4. Большие преимущества Ferrari перед Газелькой очевидны и бесспорны, пока не нужно отвезти холодильник на дачу. Именно в такой, безусловно очень редкий, момент, все плюсы перестают что-либо значить. Поэтому при всей своей корявости, родственник с Газелькой никому ещё не помешал :) а так-то Ferrari ругать никто здесь и не думал.
                  0
                  > SnapRestore требует NFS, на блочном сторадже (около 50% для NetApp + VMware) не работает.

                  Э-э… Что-то вас понесло, и понесло не туда. Вообще-то SnapRestore это функция WAFL и никакого отношения к NFS и вообще любым протоколам не имеет.
                  Он может не быть включенным, например если не куплена на него лицензия, но снэпшоты и восстановление из них простым копированием все равно есть и всегда будут, просто как свойство внутренней файловой системы стораджа.
                  Тема про странных людей, использующих блочные протоколы при возможности использовать NFS на том же сторадже, со всеми его плюсами, оставлю сейчас за скобками темы.
                    0
                    Речь в комментируемом Вами посте идёт про VMware, на котором SnapRestore VM возможен только на NFS, так что никуда меня не понесло. А минусов у NFS не меньше, чем плюсов, и это долгий религиозный спор… вот только намекать на то, что добрая половина клиентов NetApp с VMware является странными неудомками по меньшей мере странно с Вашей стороны.
                      0
                      > на котором SnapRestore VM возможен только на NFS

                      Это не так. Все что я могу вам по этому поводу сказать. Не упорствуйте в грехе, лучше пойдите почитайте документацию (исправьте, если это написано у Veeam)

                      > является странными неудомками по меньшей мере странно с Вашей стороны.

                      Не приписывайте мне то, что я не говорил, это ваши фантазии и ваши слова.

                        0
                        Откуда Ваша информация про SnapRestore VMware VM? Моя непосредственно из NetApp R&D и Product Management, с которыми я напрямую работал последний год, пока мы разрабатывали интеграцию выше. И конкретно со SnapRestore они мне всю плешь проели, в смысле чтобы мы именно через него свой Instant VM Recovery заимплементили. Примерно раз в квартал эта тема разными людьми поднималась, и заканчивалась всегда именно моим аргументом, что мы будем делать по-другому, так как нам нужен общий движок и для NFS, и для блокового стораджа.
                          0
                          Коллеги, мне кажется, у вас тут небольшое недопонимание произошло на почве SnapRestore.
                          Snaprestore — это технология восстановления из снэпшота средствами массива. Она работает на всех протоколах доступа.
                          Но на файловом уровне можно восстановить любой файл (например, vmdk диск), а на блочном — только LUN целиком.
                          netto прав в том, что snaprestore работает всегда и везде, но восстановить конкретную ВМ его средствами, как верно подметил TheRealGostev, возможно только на nfs.

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