Veeam Backup & Replication V10: резервное копирование NAS и файловых шар

Этой статьёй я хочу дать старт небольшому циклу, который будет посвящён новому функционалу в Veeam Backup & Replication V10, который мы так долго уже ждём. На момент публикации данной статьи дата релиза GA всё ещё неизвестна, но я побывал на Veeam Vanguard Summit 2019, где появилось довольно много подробностей о 10-й версии продукта и теперь у меня есть большое количество материалов, которыми я мог бы с вами поделиться. Тем более, что всё это подкрепляется уже 2-й бета версией, которая уже доступна узкому кругу лиц.

Бекапа файловых шар действительно не хватало и это было очень частым запросом. Конечно были варианты, каким образом бекапить файловые шары при помощи Veeam, один из таких способов при помощи Linux Agent я уже описывал, но скажем честно — это грабли, а не решение.

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

10-я версия предлагает 2 варианта резервного копирования файловых шар:

• SMB v1, v2 и v3
• NFS v3 и v4.1
• «Управляемые» файловые сервера на базе Linux и Windows.

Начну с «управляемых» файловых серверов, т.к. этот вариант у нас фактически уже имелся и реализован практически также — при помощи агентов, установленных на файловых серверах под управлением Linux и Windows. Здесь компания Veeam немного отошла от своей основной идеи «делаем бекап всего, а вы уже сами решаете, что вы хотите из этого восстановить». Новые агенты для файлового бекапа, схожи по своей сути с хелперами, которые устанавливаются на виртуальные машины при application-aware. Они позволяют выполнить бекап отдельных дисков/разделов сервера, но при этом не позволяют сделать резервное копирование всего сервера и, соответственно, из такого бекапа можно восстановить только отдельные файлы. Именно этот вариант рекомендуется использовать, если ваш файловый сервер находится под управление одной из этих операционных систем. Если же вы хотите иметь возможность восстанавливать файловый сервер целиком, чтобы защититься от полного отказа, то ваш путь — полноценный Windows/Linux агент.

Но перейдём к более интересному — сетевые шары.
Одной из интересных особенностей на мой взгляд является использование снепшотов. Во-первых, для SMB3 можно использовать VSS снепшоты, а если вы используете СХД с поддержкой снепшотов, то можете использовать её снепшоты.

Да, вы можете забирать данные на прямую с шары, но в этом случае заблокированные (используемые пользователями в этот момент) файлы не смогут быть прочитаны и Veeam их просто проигнорирует при резервном копировании.
Для работы VSS снепшотов, единственным условием является поддержка SMB3 как со стороны самой файловой шары, так и со стороны Veeam Proxy, чтобы он мог шаре дать соответствующую команду.
И третий вариант — снепшоты СХД. На GitHub в репозитории VeeamHub уже есть примеры pre-job скриптов, которые делают снепшот (на примере NetApp FAS/AFF). При этом, Veeam корректно работает со снепшотом, вам не нужно указать путь именно до него, что позволяет в дальнейшем восстанавливать файлы в оригинальное место на шаре без дополнительных проблем.

Процесс и хранение
При первом бекапе вычисляется CRC-хэш для каждого файла и директории, при запуске следующего задания (инкрементного) происходит сравнение CRC-хэшей «по дереву», начиная с рутовой директории. Если хэш директории не изменялся — она просто пропускается, т.к. внутри ничего не менялось. Таким образом ищутся директории с изменённым хэшем и уже внутри этих директорий ищутся файлы с изменившимся хэшем. Для этих файлов снова вычисляется хэш, записывается их метадата и происходит бекап данного файла.

Хэши хранятся в Cache Repository. Cache Repository создаётся отдельный для каждой шары на этапе добавления каждой шары в VBR, желательно располагать на SSD, т.к. работа с метаданными требует хорошей скорости дисковой подсистемы. Если вы используете для хранения данных SOBR, то стоит учитывать, что Cache Repository не может располагаться на нём. Также у нас появилось несколько приятных вещей:

• Для файлового бекапа Veeam ушёл от использования точек восстановления и перешёл к дням.

• Мы можем хранить несколько версий файлов, если они изменялись, при этом для долгосрочного хранения этих файлов мы можем указать другой репозиторий. В том числе есть гибкие настройки по хранению файлов и в том числе поддерживается фильтрация по расширению файла.
  
  Предполагается, что для долговременного хранения файлов будет использоваться иное хранилище, нежели основной репозиторий для бекапов, к примеру, это может быть более дешевая система хранения данных или облачное S3 хранилище.

• Может быть использовано несколько прокси для бекапа одной шары в рамках одного задания.
  
  Это позволяет лучше масштабировать систему и добиться максимальной скорости. В рамках одного задания разные прокси могут обрабатывать одну шару, разделяя между собой данные, но используя при этом один и тот же Cache Repository и Backup Repository. Возможность использовать Backup Repository несколькими прокси серверами появилась благодаря новому формату хранения данных для файлового бекапа. Native BLOB Storage вместо VBK и VIB. Данные хранятся в блобах, размер которых равен 64Мб.
  
  
  Переход к новому формату хранения данные позволяет добиться ещё одной положительной возможности — данные одной сессии бекапа могут храниться на разных экстентах. То, чего невозможно добиться при бекапе виртуальных машин (по крайней мере на сегодняшний день), но что может потенциально дать дополнительный прирост производительности, если для SOBR вы используете разные системы хранения данных или шары с разных дисковых агрегатов.

• При использовании SOBR для файлового бекапа на каждом экстенте хранится дополнительные набор (из двух копий) метаданных, что позволяет «потерять» до двух экстентов (независимо от того — 3 у вас или 20). Но это не отказоустойчивость на уровне самих данных, а только на уровне метаданных, что позволит при потере одного из экстентов перечитать все метаданные, чтобы составить карту данных, которые нам ещё доступны на живых экстентах, что бы этот бекап у нас был работоспособен.
  
  Для корректной работы данного функционала требуется у задания включить Backup Health check. И для полной безопасности — запускать его ежедневно. Тогда при потере одного из экстентов мы сможем запустить Health check у джоба и перестроить метаданные, для запуска процесса восстановления. Нужно понимать, что при перестроении метаданных, из них удаляется информация о тех данных, что были на экстенте, который умер. Соответственно Health check можно запустить только вручную и только при полном понимании администратором, что данный экстент и данные на нём навсегда утеряны. Если же ваш экстент недоступен временно, этот функционал использовать нельзя, даже если экстент станет доступен, данные уже не будут подтянуты Veeam.

Прокси для файлового бекапа может быть только на Windows — это уточнение теперь необходимо, в связи с появлением Linux Virtual Proxy, но на нём подробнее остановлюсь в части про бекап виртуальных машин.

Восстановление
Конечно, для восстановления у нас есть Explorer, какой он был для файлового восстановления, но в нём добавилось несколько отличных вещей.
Одно важное замечание — если вы делаете файловый бекап Linux сервера при помощи нового “файлового” агента, то для восстановления файлом больше не требуется FLR, который необходимо было запускать в вашей виртуальной инфраструктуре и уже через него восстанавливать файлы. Благодаря этому новый эксплорер запускается за секунды и сразу же готов к работе.

Первый вариант восстановления — Entire File share

Здесь примечательно, что у нас появился не просто выбор точек, как это было реализовано раньше, а в стиле CDP (если кто-то видел презентацию Андрея Железко и Дмитрия Князева на VeeamON Forum Russia 2017). Хотя можно и вручную выбрать конкретную точку по календарю, если вам удобнее классический вариант. Самым же удобным является то, что у нас есть браузер файлов и мы можем посмотреть состав бекапа. Найти нужную копию (например, до того, как директорию обработал шифровальщик) и восстановиться на этот момент без всяких проблем. Есть возможность как восстанавливаться в оригинальное расположение файлов, так и в другую директорию и/или на другой сервер. При этом у нас имеется ряд дополнительных опций при восстановлении, если восстанавливаемый файл есть на нашей шаре:

• Skip restoring (keeps existing files)
• Replace older files only (use for restoring shares reverted to a snapshot)
• Replace newest files only (use to roll back unwanted contents changes)
• Restore anyway (overwrites existing files)

Так же при восстановлении могут быть восстановлены атрибуты доступа к файлам и директориям.
Второй вариант — Rollback to point in time
Самый простой вариант — откатываем всё что есть на рестор поинт, без дополнительных параметров.

И самый интересный и наиболее востребованный вариант — Files and Folders.
По умолчанию, нам предлагается в качестве восстановления использовать последнюю копию бекапа либо можно выбрать необходимый рестор поинт, но самое интересное, это вариант All time, где мы сможем увидеть все файлы, которые имеются в нашем бекапе и в том числе — все версии изменявшихся файлов, с возможностью восстановить именно необходимую копию файла. И видны те файлы, которые уже удалены с продуктивного хранилища вместе с указанием даты их удаления. Это удобно, когда вам нужно восстановить конкретный файл, который вы не знаете когда именно был удалён или изменён, а при наличии поиска по файлам это операция занимает минимальное количество времени.

И небольшая вишенка на торте — Veeam ONE, в который добавлены новые репорты для NAS бекапа:

• Backups on repository
• Backups on tape

некоторые старые репорты подверглись обновлению:

• Job history
• Backup infrastructure custom data

которые помогут следить и анализировать NAS бекапы.

Алерты к нему же и обновлены:

• File backup job state
• File backup copy state
• File-to-tape jobs state
• Proxy connection
• Proxy performance

И самое интересное — лицензирование

И так, мы наконец-то получили недостающую часть звена в резервном копировании при помощи Veeam. Знаю, что было множество запросов на эту тему. Приятно, что реализация оказалась на довольно высоком уровне и интересными решениями. Поддержка снепшотов СХД (а поддерживаются все совместимые на сегодняшний день СХД и те, которые будут добавляться в дальнейшем при помощи Storage API) на мой взгляд просто отличная идея, как и новый формат хранения.