Veeam Backup & Replication V11: NAS

Уже объявлена дата Veeam V11 Launch Event — 24 февраля. Пока точно неизвестно — это день релиза или же будет громкий анонс, но в любом случае я рекомендую вам присоединиться к этому мероприятию.

В 10-й версии нам представили новую функциональность по бекапу файловых шар. Вещь полезная, но лично мне не нравилась реализация. Да, CFT самого Veeam был хорош, но те же снепшоты через скрипты не самое удобное решение. Было понятно, что функционал будет развиваться и сегодня у нас есть возможность оценить год проделанной работы в этом направлении.

Интеграция с СХД
В Veeam V11 появилась возможность более простой работы с NAS’ами. Если в 10-й версии приходилось настраивать интеграцию со снепшотами фактически руками при помощи скриптов, то теперь этот функционал уже есть из коробки, правда поддерживается пока только с массивами NetApp (Lenovo) на базе ONTAP и Dell EMC Isilon.

У нас появились новые галочки в мастере добавления СХД — их я уже показывал в предыдущей части «V11: агенты«, когда рассказывал про возможность использования снепшотов СХД при бекапе физического Windows сервера. Сегодня у меня развёрнут уже RC и этот мастер получил свой окончательный вид.

Block or file storage for VMware — это то, как мы использовали СХД до 11-й версии, делая снепшот луна, на котором располагалась vmfs.
Block storage for Microsoft Windows — для бекапа Windows агентом.
NAS filer — поддержка файлера.

После этого мы добавляем не просто файловую шару, как это было в 10 версии, а NAS.

Уже после создаём задание и выбираем шару уже на уровне самой СХД (в контексте ONTAP — мы видим SVM и его вольюмы).

Veeam уже имеет интеграцию с СХД, соответственно, знает для какого вольюма необходимо сделать снепшот, сам же делает export policy (для NFS) для себя и забирает данные. Именно такого подхода к бекапу файловых шар с СХД изначально и ждали от Veeam, а теперь остаётся дождаться только расширения списка поддерживаемых СХД, т. к. список NAS Devices состоит всего из двух СХД, что намного меньше, чем для блочного доступа.

При работе с Dell EMC Isilon есть возможность использовать его CFT (Change File Tracking), что конечно же крайне благоприятно влияет на скорость работы. Механизм CFT самого Veeam крайне неплохо справляется со своей задачей, но СХД делает это ещё лучше.

Instant File Share (SMB) Recovery
Veeam уже давно ставит своей основной задачей дать возможность как можно быстрее начать работать с данными в резервной копии в случае проблем с продуктивными системами. Вполне логично было ожидать появления Instant Recovery и для резервных копий шар.
Теперь, при наступлении каких-либо проблем с вашей продуктивной шарой, вы можете запустить Instant Recovery для неё и в кратчайшие сроки дать доступ к файлам вашим пользователям. Причём, если вы используете, например DFS, то это можно сделать вообще прозрачно для пользователей.

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

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

Но, к сожалению, на сегодняшний день функциональность IR для файловых шар пока довольно сильно ограничена:

• Пока поддерживается только SMB
• Публикуемые шары находятся в режиме read-only
• Нет функционала «миграции в прод», т. е. после публикации шары нам необходимо будет отдельно запустить ещё и процесс восстановления данных

Что ещё интересного нам предлагают в 11-й версии:

• NAS бэкап и дедуп-аплайенсы. Улучшена производительность при бекапе файловых шар на дедуп-аплайнсы. В материалах приводятся примеры на базе HPE StoreOnce, думаю оно же будет справедливо и для DellEMC DataDomain, но на сегодняшний день у меня нет их в лабе, чтобы проверить самостоятельно. Увеличен размер blob-файла с 64Мб до 1Гб, что дало значительное увеличение скорости.
• Meta-extent. Теперь в составе SOBR может быть репозиторий с ролью meta-extent, т. е. предполагается быстрый репозиторий (SSD) для хранения мета-данных и более медленный репозиторий для самих данных. Естественно, этот механизм так же даёт прирост в скорости работы.Примеры снова приводятся на базе HPE StoreOnce, но я не вижу никаких ограничений в том, чтобы использовать эту же схему при бекапах на обычном сервере с дисками. По крайней мере технических ограничений по данному поводу нигде не описано.Но Meta-extent будет работать только при бекапе File share, другим типам джобов оно просто не требуется.
• На вкладке нотификации для File share job у нас появилась возможность создавать CSV файл, в котором будет содержаться список файлов с проблемами с атрибутами файлов или которые были по какой-то причине пропущены во время работы джобы.
• Естественно, для всего этого подвезли и новые PowerShell командлеты.

На сегодня у меня всё. Я думаю, что это была последняя статья из цикла по V11, т. к. до Launch Event осталось всего около 3 недель, RC уже есть и вряд ли вдруг появится что-то ещё новое до релиза. Так что ждём 24 февраля, надеемся, что это будет не просто презентация новой версии, а мы увидим релиз в этот же день. Так что не забывайте регистрироваться и до встречи!