О продукте для резервного копирования NAKIVO Backup & Replication я узнал буквально пару месяцев назад, когда о нём появилось несколько статей в рунете. Данный продукт отсутствует в свежем квадранте Gartner по направлению Backup & Replication, но тем не менее, он заинтересовал меня некоторыми своими возможностями, о которых я сегодня вам и расскажу.
NAKIVO — продукт достаточно молодой, он появился на рынке лишь в 2012 году и на мой взгляд он удачно «исповедует» подход своего конкурента — Veeam. Так же как и Veeam изначально, NAKIVO нацелен на резервное копирование виртуальных инфраструктур и при этом не использует для своей работы агентов (в том числе и хелперы, как Veeam). Но есть у NAKIVO и собственные «фишки». NAKIVO способен работать абсолютно на любой платформе — linux, windows, aws, поставляется так же в виде готового виртуального аплайнса и в том числе — в виде готового пакета для различных NAS (Synology, WD, Asus, Qnap). Это позволяет развернуть систему резервного копирования в считанные минуты. А для небольших компаний это может стать плюсом ввиду возможности использования недорогих NAS систем в качестве как хранилища резервных копий, так и самого сервера резервного копирования.
NAKIVO состоит из 3 основных компонентов:
- Director (управление и веб-интерфейс)
- Transporter (выполнение заданий)
- Backup Repository (хранилище)
Что касается управления, то у NAKIVO вам доступен Web UI, классический CLI и при этом имеется HTTP API, соответственно, у вас имеется возможность интегрировать данное решение в вашу систему управления. Помимо этого имеется и портал самовосстановления, т.е. использование данного решения для предоставления услуги BaaS доступно из коробки и не требует отдельных лицензий. Так же вы можете передавать систему в субаренду.
Использование нескольких транспортных модулей позволяет гибко масштабировать систему резервного копирования при больших объёмах или при их будущем росте, позволяя распределить как вычислительную, так и сетевую нагрузку между несколькими серверами. Интересным представляется отсутствие возможности выбора типа создаваемой резервной копии. NAKIVO создаёт только инкрементные резервные копии (нет, первая у вас конечно в любом случае будет full) при помощи VMware CBT и Hyper-V RCT для определения изменившихся блоков VM (если только вы не включаете опцию No change tracking — в этом случае бэкап будет всегда Full).
Сервер хранилища позволяет подключать локальные диски или удалённые диски (NFS, NAS или SAN), но при этом не поддерживает работу с ленточными библиотеками (поддержку ленточных библиотек обещают реализовать ближе к концу года). Стоит отметить, что дедупликация работает не в рамках сессии, а глобально, на уровне блоков хранилища. Это позволяет крайне эффективно использовать дисковое пространство. Дедупликацию можно и отключить, если вы используете специализированную СХД для хранения резервных копий, но, к сожалению, на текущий момент NAKIVO не поддерживает API таких СХД, как EMC DataDomain или HPE StoreOnce.
Создание заданий производится при помощи мастера в 4 простых шага, которые ни у кого не вызовут никаких сложностей. Что хотелось бы здесь отметить? Во-первых — очень высокую гибкость настройки шедулера, в том числе и заданий несколько разных расписаний для одной задачи.
Так же в версии 7.2 beta появился удобный календарь со всеми джобами. Удобно и быстро можно найти свободное окно для новой задачи или посмотреть когда выполняется наибольшее количество заданий, что бы можно было как то разгрузить график.
И крайне гибкая политика хранения резервных копий, настраивающаяся в пару кликов мыши.
При помощи VSS обеспечивается консистентность приложений:
- Active Directory
- Exchange
- MS SQL
- SharePoint
Список приложений пока не столь обширен, как у конкурентов, но я очень надеюсь что он будет расширяться.
Во время процедуры резервного копирования Nakivo производит верификацию переданных блоков и уже на этом этапе контролирует возможность восстановления данной виртуальной машины. В дополнение к этому, в качестве проверки резервной копии используется сценарий с ручным запуском машины из резервной копии, автоматическим запуском и созданием скриншота после выполнения задачи резервного копирования. К сожалению, тут нет расширенной проверки работы виртуальной машины — сканера портов или запуска кастомных скриптов. Не всегда убедиться в работоспособности сервиса, развёрнутого на виртуальной машине, можно простым скриншотом рабочего стола.
Во время моего знакомства с Nakivo ко мне для обзора приехал NAS от компании QNAP — TDS-16489U и я совместил приятное с полезным — попробовал работу Nakivo на этом устройстве. Как показал мониторинг загрузки — ресурсов он практически не потребляет, хотя там всё-таки 2 процессора Xeon. Но развёртывание производится в 2 клика и занимает всего около пары минут.
Что же касается скорости резервного копирования, в моей тестовой песочнице Nakivo показал такой же результат, как Veeam, который я использую в качестве основной системы РК. Разницы в эффективности хранения, в рамках одного таска я между ними так же не заметил.
В конце хочется сказать о ещё одном ключевом преимуществе данного решения — цена. Сравним с Veeam — даже если не учитывать возможности портала самообслуживая и взять простую версию Veeam Backup & Replication, она обойдётся в 73000 рублей за один процессор (прайс SoftLine), при этом самая дорогая версия Nakivo Backup & Replication с многопользовательским режимом, возможность брендирования портала, HTTP API и интеграцией с AD на текущий момент обойдётся в 36000 рублей. Если же многопользовательские функции не нужны, то стоимость опустится до 24000 рублей за один процессор. Acronis Backup 12.5 Standard Virtual Host так же получается более дорогим, а уж про такие продукты, как HPE DataProtector, EMC Avamar, Commvault или IBM Spectrum Protect и вовсе говорить не приходятся.
Да, конечно на текущий момент Nakivo уступает по своим возможностям Veeam, особенно что касается вопросам интеграции с СХД, но продукт достаточно молод, конкуренция на рынке достаточно высокая и я думаю, что продукт будет развиваться очень быстро и обрастать полезным функционалом. Если вы ищите недорогое ПО резервного копирования, и в вашей виртуальной инфраструктуре преобладают продукты от Microsoft — NAKIVO Backup & Replication может стать вашим отличным помощником.
Комментарии (21)
mikkisse
04.09.2017 11:17А есть ли бесплатное издание? Если есть — каковы ограничения?
KorP Автор
04.09.2017 11:22Есть, но ограничение в 2VM
www.nakivo.com/resources/download/free-edition
nokogerra
Цены нужно запрашивать у партнеров, в онлайн магазинах они всегда выше будут (скидки за красивые глаза, акции и т.д.). Вы говорили о «самой простой» лицензии veeam, это обычно для малых инфраструктур, коллегам из «дружественной» организации предложили закрыть их vSphere ess+ с 6 сокетами с помощью veeam b&r essentials std за 250 деревянных рублей, т.е. ~40 т.р. за сокет, что не так уж много для veeam.
За обзор спасибо, может это действительно будет вменяемый конкурент для veeam. Вот только сути обязательного forever incremental (при включенном CBT) не понял, я же retention policy контролировать не смогу, или он сам какие-то синтетические полные копии в промежутках делает?
P.S. Не так давно был вынужден протестировать акронис для виртуальных сред (хотя и бегло) и мне это показалось чудовищным набором костылей с какими-то агентами, бэкап джобы валятся чуть ли не рандомно, адекватный роллбэк рестор отсутствует, и много чего еще. Может я какой-то прелести продукта не оценил? Хотя в интернетах тоже сетуют на стабильность работы, особенно по сравнению с veeam. Мне показалось, что никто, кому дорога сохранность информации, это использовать не станет.
KorP Автор
Да, вы правы, это «list price», но конкретные скидки доступны у всех вендоров, так что я думаю соотношение цены в конечном итоге всё-равно сохраниться.
Как я понимаю, это аналогия с вимовским «прямым инкрементом» (так он называется, если мне память не изменяет), когда создаётся первый фульник, а потом только инкременты и из них автоматически лепится фульник (но процедура отличается от синтетического фульника). Господа из Nakivo мне сообщили что в версии 7.3 появится возможность делать фульники по желанию.
Вот тут скажу, основываясь на опыте работы с вимом порядка двух лет. Если есть проблема с вимом — 99% случаев это проблемы инфраструктуры/ПО/приклада, а не самого veeam. Но мне лично не известны люди, использующие акронис :)
nokogerra
Дак и я о том же, с самим вимом проблем практически не бывает. Зато имел такую ситуацию, когда машины с двух тестовых гипервизоров бэкапились вимом и акронисом в разное время суток (окна не пересекались) и джобы акрониса падали постоянно по разным причинам, а джобы вима — нет. Для меня, как конечного потребителя, это показатель.
Да, судя по всему, речь о forever forward incremental.
Это отлично.
Ну, я также хотел обратить внимание на то, что для малых инфраструктур существует veeam essentials, 1 std сокет порядка 670 долларов.
chineek
По поводу опыта работы с Acronis можете, пожалуйста, написать мне в личном сообщении (или прямо здесь), какие конкретно были проблемы при использовании?
Мне, как одному из сотрудников Acronis, очень хочется разобраться, что же именно пошло не так. Если остались какие-нибудь логи, или хотя бы примеры ошибок (мб было обращение в тех. поддержку?) — буду благодарен за любую информацию.
KorP Автор
Как мне нравится, когда в диалог вступают представители вендора, стараясь разобраться в проблеме! Респект!
nokogerra
Какие конкретно были ошибки при выполнении джоб сейчас, конечно, уже не вспомню, могу только сказать что они не были связаны с инфраструктурой. Припоминаю что в том числе были проблемы с созданием снапшотов (возможно, quiesce, не уверен) и, как я упоминал, они были рандомные — то делались, то нет. Почему-то когда команду на создание снапшота отправляла вим прокси, таких проблем я не наблюдал. И различные проблемы с той или иной джобой возникали на протяжении двух недель, и это при том, что среда была тестовая и практически статичная. Начинаешь невольно сравнивать с вимом и понимаешь, что он работает из коробки, даже если просто натыкать далее-далее, а тут какие-то проблемы с самой системой резервного копирования приходится решать.
. Единая консоль, вот это да.А общее впечатление конкретно портит весь этот архитектурный карнавал с агентами, для висферы мне потребовался vApp с, кажется, слесом на борту и развернутым там агентом. Я как будто снова на BE2010 (хотя в 2011 мне BE очень нравился своими политиками и ресурс списками). А отсутствие вменяемого аналога quick rollback (откат только изменившихся блоков) вообще убил. Уверен, у многих большая часть операций восстановления — это суть откат к определенной точке, а не восстановление целой машины из-за неконсистентности VMFS или разрушения массива. И вот эта функция мне недоступна.
Ну и маркетинговый буллшит вроде:
1. ЭКСКЛЮЗИВНО!
2. НОВИНКА! instant vm recovery новинка в 2017 (или пускай 2016, 2015) году?
3. ЭКСКЛЮЗИВНО! Кричать «эксклюзивно» когда у конкурентов помимо health check`а есть virtual lab для теста «восстановибельности» резервных копий?
Весь этот маркетинговый буллшит взят отсюда www.acronis.com/ru-ru/download/docs/ab12lavmware/overview.
Мне это напомнило ситуацию, когда в каком-то там году мы рассматривали варианты антивирусов для VDI (в то время еще VMware View) и наткнулись на Symantec «для виртуальных сред», где чуть ли не в каждой строке мне в глаза пихали новость о том, что они просто супер-дупер поддерживают всякую там виртуализацию (тогда еще это было модно, а не обыденно) и я пытался докопаться в чем же суть интеграции с вирт средой. Штудировал документацию, развернул стенд, но ничего не обнаружил. А потом пытал 2 дня саппорт, чтобы услышать от них признание, что вся поддержка виртуализации заключается в том, что агент антивируса можно поставить в виртуальную машину. Ничосе. Стоит ли говорить, что для связанных клонов это не очень подошло. Это я все к тому, что такая агрессивная и глупая маркетинговая чушь отталкивает более-менее образованных инженеров или руководителей, особенно, когда видишь когда здесь «новинки» и «эксклюзивно» это то, что было у Veeam 7 лет назад (мнение касательно маркетинга не только мое, но и многих моих коллег).
На случай, если вам вдруг показалось что я адепт Veeam, знайте — это не так, я адепт того, что удобно и работает. Мне, например, шедулер и политики BE 2010 очень нравились. Но вот Veeam работает значительно надежнее, я просидел 3 года на BE и помню сколько различных ошибок возникало (справедливости ради скажу, что половина из них была связана с работой ленточной библиотеки), хотя мне казалось что это нормально. А когда попробовал Veeam был в шоке от того, что ошибок нет. Практически совсем. И когда снова окунулся в кучу граблей аж коленки задрожали от воспоминаний.
Большинство моих коллег не желает использовать Акронис в первую очередь из-за того, что архитектура решения агентная. Я не хочу использовать по этой же причине, по причине того, что при первых же тестах решение показало себя не надежным и из-за отсутствия некоторого важного функционала.
chineek
Спасибо за подробный ответ!
Здесь разница в поведении скорее всего от того, что Вим по умолчанию использует не-quiesced снапшоты (чтобы их включить, нужно явно выставить соответствующую опцию), что и приводит к тому, что они всегда успешны на стороне гипервизора. В Acronis Backup по умолчанию создаются application-consistent (quiesced) снапшоты, чтобы гарантировать консистентность данных внутри резервной копии ВМ, но, как показывает практика, с quiesced снапшотами у VMware всегда были (и остаются) проблемы, отсюда и плохое впечатление от работы Acronis Backup, который зависит от этой функциональности VMware.
Начиная с 12.5 версии мы сделали автоматическое переключение на не-quiesced снапшоты, если quiescing не удался за 3 попытки, чтобы сгладить данный эффект, и при этом сделать всё возможное для гарантии консистентности данных.
Агент для VMware предоставляется в двух вариантах — под Windows (что по сути является полным аналогом Backup Proxy от Вим), либо в виде легковесного vApp (Virtual Appliance). «Виндовый» агент может быть установлен вместе с сервером управления и в итоге получится вим-like установка, где всё стоит на одной машине. Т.е. использовать vApp в принципе не обязательно. Здесь, судя по всему, у вас возникли проблемы с первоначальной настройкой, т.к. разворачивание Virtual Appliance действительно не самая явная операция, а наличие опции Agent for VMware (Windows Agent) не явно видно при изначальной установке.
Опции по инкрементальному восстановлению ВМ действительно не было в версии Acronis Backup 11.7, но начиная с 12ой (которая была выпущена год назад), она доступна и по умолчанию включена, т.е. применяется при любом восстановлении в «оригинальную» или «существующую» машину.
За отзыв по маркетинговым материалам отдельное спасибо — будем улучшать. По поводу Instant Restore — из нового (того о чем материалы умолчали) в 12.5 есть действительно уникальная технология "финализации" смонтированных машин, которая позволяет даже при отсутствии «storage vMotion» лицензии (либо на отдельностоящих ESXi хостах без vCenter-а), в фоновом режиме копировать машины смонтированные из образа в основной датастор, без необходимости выключать машину.
Можете пояснить в чем основная сложность с агентной архитектурой? На данный момент любое решение для более чем одной среды (например нескольких гипервизоров + физических машин) по сути является агентным. Если взять тот же Вим, то и там используется подобное решение с наличием Backup proxy компонента, который есть ни что иное как агент, которые позволяет расширять инфраструктуру когда одного дефолтного «агента» недостаточно.
Подозреваю, что основное впечатление у вас осталось от негативного опыта первоначальной настройки и необходимости в принципе устанавливать какие-либо дополнительные агенты или проблемы начались уже после этого?
nokogerra
Я и в Veeam для некоторых машин использую quiesced снапшоты, проблемы возникают крайне редко.
Бэкап прокси это транспортный модуль, в качестве аналогии можно привести датамувер для, например селерры, не совсем понимаю в каком контексте это агент. Касательно того, что агент для Windows может быть установлен вместе с сервером управления Acronis BA вообще не понял.
Не скажу точно когда тестировал, но тогда восстановление было полным. Я это точно запомнил, т.к. в тестовой среде это происходило через гигабитные линки, это очень ощутимо.
Агентная архитектура, конечно, имеет место быть при гетерогенной среде в плане физик/виртуал, но от физики многие стараются уходить. Я в жизни с физикой не работал ни разу. Точнее так: физическими были только гипервизоры. На сколько я знаю, лидером продаж для вирт. сред все таки является Veeam, а не, например, агентные netbackup, BE или Acronis BA (цифры, конечно, не приведу).
А по поводу того, что прокси — это агент, не согласен, это в первую очередь датамувер. Это в терминологии Acronis можно назвать агентом. Прокси занимается тем, что тянет трафик. Или не тянет, а работает сугубо с репозиторием (например, создавая синтетическую полную копию). Меня смущает именно то, что я должен ставить какое-то стороннее ПО чтобы делать бэкапы того или иного источника, чтобы делать app aware бэкапы. Я не хочу ничего ставить, а хочу жениться. Не хочу обновлять эти агенты. Не хочу создавать правила для локальных межсетевых экранов, чтобы к этому агенту можно было достучаться. У меня продуктивная среда имеет бешеную динамику, машины в разных доменах (под управлением разных инстансов служб каталогов) или вообще вне доменов по независящим от меня причинам. Работа с учетными записями для гостевой ОС для app aware бэкапа еще приемлема, а вот установка/удаление/обновление агентов уже не вариант для меня.
mikkisse
Возможно, здесь имеется в виду Агент как раз в вашем значении датамувера?
Но в целом немного непонятна необходимость нахождения Агента именно в среде виртуализации. Acronis работает с виртуальными машинами только в режиме HotAdd?
navion
Ключевая фраза «для некоторых». В changelog к VMTools через раз пишут про исправленный quiescing.
А как Veeam ставит и общается с агентами при активации application-aware processing? По сети или через VMCI?
KorP Автор
Вим использует свой хелпер, закидывая его каждый раз на машину, через VMCI. Я крайне согласен, что такой подход на много удобнее, чем ставить агентов на машины клиентов. Хотя подход Nakivo в данном случае ещё лучше, ибо не требует учётных данных от машины :)
chineek
Поясню, что имелось в виду касаемого агентного/безагентного подхода на примере VMware. Может быть 3 разных подхода к установке решения резервного копирования:
1) Все компоненты внутрь Windows ВМ на том же гипервизоре. Судя по всему, вам был выбран именно этот подход — поэтому именно его я подробнее рассмотрю ниже.
2) Все компоненты на отдельную физическую или виртуальную машину вне гипервизора
3) Сервер управления на отдельной машине + агент (в случае Вима это будет «backup proxy») на отдельной машине
В 1ом случае (реализуется и Вимом и Акронисом) и сервер управления и агент для VMware стоят рядом. При этом остальные ВМ с данного гипервизора бэкапятся в режиме либо HotAdd (через аттач их дисков к основной ВМ), либо NBD (Network Block Device = чтение по сети). Режимы открытия виртуальных дисков определяются VMware vStorage API, которое является основным и используется всеми вендорами в том числе Nakivo, Veeam, Acronis, Veritas, и т.д. (есть исключения в виде Zerto, но это всё-таки исключения).
Агентом в данной терминологии я называю компонент, который рядом с собой тянет библиотеки от vStorage API от VMware и отвечает за чтение исходных данных с ВМ + за передачу этих данных в хранилище резервных копий.
Соответственно, в случае Veeam, вы устанавливаете продукт на эту Windows VM и получаете и сервер управления и агент («Backup proxy») использующий vStorage API. В случае Acronis можно так же поставить сервер управления (Acronis Management Server) + агента для VMware который в том числе доступен в виндовом варианте. Поэтому в обоих случаях подход к установке идентичен. Разница только в том, что с Вимом «агент» ставится всегда по умолчанию, т.к. этот продукт заточен именно под виртуальные среды, а в случае Акронис эту опцию (компонент Agent for VMware (Windows)) нужно явно выбрать.
Все вышесказанное, естественно, не подразумевает установку агентов внутрь бэкапящихся ВМ, т.е. речь исключительно про «agent-less» подход.
Для application-aware резервных копий установка агентов внутрь ВМ также не нужна (в Acronis Backup 11.7 это было не так) — сбор метаданных приложений осуществляется следующим образом:
С помощью API предоставляемого VMware Tools (VIX API) внутрь ВМ забрасываются скрипты, которые отвечают за сбор метаданных приложений + за очистку журнала логов транзакций. Передача собранных метаданных происходит в направлении гипервизор->агент для VMware, т.е. наличие сетевого канала между гостевой ОСью ВМ и агентом не требуется. После сбора информации о приложении резервное копирование осуществляется обычным способом через vStorage API.
Разные вендоры по разному осуществляют данную операцию — кто-то опционально требует установку дополнительных «мини-агентов», которые стоят постоянно установлены, другие предпочитают закидывать нужные скрипты налету через VMware Tools (VIX канал). Главное, что во всех этих случаях канал связи между этими мини-агентами и основным агентом для VMware не зависит от сети гостевой ОСи ВМ, которую бэкапят, а осуществляется через тот же сетевой канал, который используется основным агентом для связи с гипервизором (по сути — это соединение с VMkernel интерфейсом ESXi хоста).
TL;DR: Суть сводится к тому, что принципиальных отличий в первоначальной настройке и дальнейшем сопровождении (с точки зрения настройки сетевой инфраструктуры) любых решений резервного копирования для VMware быть не должно. Таким образом разница между решениями состоит в основном в наличии или отсутствии конкретных «фич» (например Instant Restore, гранулярное восстановление данных конкретных приложений, репликация ВМ, и т.д.), но не в принципиальном подходе.
nokogerra
Что ж, ваши доводы выглядят убедительно, замечательно что все так. Я следовал документации и считал, что vapp необходим в качестве агента для висферы, так же как и агенты внутри гостей для app aware бэкапов.
chineek
Для версии 11.7 вы были бы правы относительно части app-aware бэкапов, но мы тоже на месте не стоим :)
Еще раз спасибо за разъяснения и отзывы — было продуктивно и нам в любом случае стало яснее над чем работать/что улучшать дальше.
nokogerra
Если кто-то из подведомственных/семейных организаций будет находиться в поисках решения для резервного копирования, то, я думаю, мы рассмотрим акронис более детально. Признаюсь, когда я тестировал эту систему, я был предубежден против неё. Хотя не столько против системы, сколько против бредового решения одного из руководителей, который при купленном veeam ent на 44 (!) сокета, при чем купленном еще за доллары по 35, решил рассмотреть вариант замены системы резервного копирования (с покупкой саппорта читерим, да).
Кстати, по поводу транспорта: я не помню точно, но, кажется, не нашел варианта транспорта lan free, т.е. трансфер резервных копий via SAN (DirectSAN Access). Есть такое у акрониса или планируется?
chineek
По поводу транспорта: Direct SAN Access поддерживается — как раз в компоненте Agent for VMware (Windows). Это один из стандартных транспортов предоставляемых vStorage API, так что проблем с ним не должно быть — достаточно подключить LUN от виртуального хранилища (датастора) к виндовой машине с агентом и этот транспорт будет использован автоматически. Приоритет транспортов, если доступны одновременно несколько, следующий: Direct SAN access->HotAdd->NBD
nokogerra
Благодарю за полезные комментарии.