Уже несколько месяцев прошло с момента релиза Veeam Backup & Replication 10. Даже была обзорная статья про грядущий релиз. А вот пост-релизной статьи посвящённой более детальному и техническому разбору самой ожидаемой функции новой версии — NAS Backup, так и не было.
Поэтому надо срочно исправляться.   Давайте будем блюсти ритуалы и в первую очередь посмотрим на сухую спецификацию поддерживаемых технологий: Теперь, когда вводные даны, давайте сначала разберёмся, на какие вопросы предстояло найти ответы перед тем, как начать разрабатывать новую функцию. В поисках ответов пришлось многое делать с нуля, и сегодня мы представляем вам результат. Давайте теперь пройдёмся по всем компонентам, участвующим в успешном создании бекапа. Первым будет сам NAS. Забрать с него файлы мы можем тремя путями, реализованными в Veeam:  Теперь рассмотрим две новые для Veeam сущности: Cache Repository и File Proxy. Кэш репозиторий — это не хранилище всей налички вашей компании (обидно, да), а специальное хранилище для временного хранения метаданных. Его задача — обеспечивать быстрое создание инкремента и снижать нагрузку на файловую шару во время бекапа. В качестве кэш репозитория может выступать как выделенный Windows/Linux сервер, так и любая CIFS(SMB)/NFS шара. Этот кэш используется исключительно для ускорения создания инкрементов и восстановления отдельных файлов, поэтому может быть потерян без всяких критических последствий. При следующем запуске бекапа он просто будет создан заново. Да, это займёт какое-то время, но без него всё было бы намного дольше. Естественно, для максимальной производительности кэш надо располагать максимально близко к бекапируемому NAS, и лучше всего на SSD. А его роль назначается любому репозиторию в инфраструктуре Veeam, за исключением облачных, дедуплицированных и SOBR. Про устройство метаданных и зачем они нужны, мы поговорим немного ниже. Теперь рассмотрим File Proxy. Этот компонент, по сути, полный аналог старого доброго Backup Proxy, только для работы с NAS. Суть не изменилась — прокси выполняет связующую роль между остальными компонентами, задействованными в бекапе, и отвечает за пересылку данных из прода в хранилища бекапов. По умолчанию эту роль выполняет сам сервер Veeam, но такой вариант использования подходит только для небольших инсталяций, где все компоненты находятся в одном сетевом сегменте. Для более интересных вариантов под прокси надо выделять отдельные Windows машины. А лучше даже, когда их несколько, так как они умеют балансировать нагрузку. Но детали, опять же, будут ниже. Кстати, технически ничего вам не мешает использовать существующие прокси для новой роли. Даже новых компонентов устанавливать не придётся. Просто следите за нагрузкой и окном бекапа.  И вот настал момент, ради которого всё и затевалось — давайте теперь углубимся в детали работы.
Первым рассмотрим Cache Repository. Совершенно очевидно, что при первом запуске бекапа мы должны тем или иным способом просто забрать всю информацию, как-то её обработать и сохранить в бекапе. Тут никакой магии нет. А вот при инкрементальных прогонах начинается самое интересное. Чтобы найти изменившиеся с последнего запуска данные, Veeam строит дерево файлов и папок и считает CRC для каждой папки и файла (парой абзацев ниже поговорим, как именно). А для пущей быстроты в работе помещает её целиком в RAM. Наша реализация позволяет умещать дерево на два миллиона папок в 70 Mb.  При инкрементальном прогоне строится новое дерево, которое сравнивается с имеющимся, и определяются места с изменёнными файлами/папками, которые надо забрать в бекап. Технически это можно делать, используя метаданные из бекапа, вот только процесс этот был бы на два порядка медленней, особенно когда речь идёт про миллионы файлов. По этой же причине можно не переживать за кэш: в случае его утери он будет воссоздан из метаданных в бекапе.  И ещё важная деталь на случай общения с безопасниками: кэш репозиторий никак не взаимодействует с реальными данными, хранящимися на NAS. Данными оперируют file proxy, а кэш репозиторий только координирует их работу.   Соответственно, настала пора разобраться с File Proxy. Они занимаются двумя вещами: обходят папки в поисках изменений (и строят CRC), передают данные. Это тот самый компонент, благодаря которому мы можем масштабироваться. Главное, следить за CPU. И здесь может возникнуть вопрос — где же то самое масштабирование, если всё может упереться в процессор на одном прокси? Ответ в возможности использования одним кэш репозиторием сразу нескольких прокси. Если не углубляться в подсознание, то процесс выглядит так: кэш выдаёт каждой проксе задание на обсчёт папки из любого места шары. Прокси считает, возвращает результат в кэш и получает новую папку для обсчёта. И так пока они не закончатся. Значит, чем больше у вас проксей (и CPU на них ), тем больше папок будет обсчитываться одновременно (читай, параллельно). Единственное, хочу отметить, что это в лучшей степени работает с CIFS шарами, где можно сразу обращаться по любому адресу. В случае с NFS могут возникнуть сложности, так как в нём для открытия папки или файла надо сначала пройти по всей иерархии. Но на это мы повлиять никак не можем.  А как получается само CRC дерево? В общем случае для подсчёта CRC файла его надо прочитать целиком. Операция не самая быстрая и в случае бекапа обыкновенной файловой шары грозит локальным скачиванием всей вашей коллекции аниме при каждом запуске бекапа. Что несколько затратно. А есть ещё свертка директорий, куда входит CRC содержимого файлов... Однако не всё так плохо, и бывает так, что CRC уже посчитано на уровне файловой системы, как это работает при, например, VMware ChangeTracking. Но жаль, что такой роскоши у нас нет.
С другой стороны, ничего из этого не мешает файловой шаре не рапортовать вообще ничего, включая дату изменения файла и его размер. Тут остаётся уповать только на то, что в файловой системе есть указание на дату последней записи, и можно проверить хотя бы это. Кстати, вредный совет хозяйке на заметку: в Windows можно отключить обновление времени последней записи в файл, что неплохо ускоряет работу диска. Правда, спасибо вам за это никто не скажет, но если вы борец за IOPS, это ваш путь самурая. Поэтому наш вариант — составное CRC атрибутов папки и атрибутов дочерних элементов на один уровень вниз. А именно, в подсчёте участвуют: modification time для каждого файла, creation time для каждого файла, имя каждого файла и security info папки. Если хочется опираться ещё и на размер файла, то вот вам другой занимательный факт — при бекапе с VSS снапшота Windows не всегда отдаёт верный размер файла. Так что использовать его(размер файла) в CRC — идея плохая. Одним словом, наш вариант позволяет строить достаточно легковесное дерево и быстро находить изменившиеся места. Соответственно, если CRC для верхнеуровнего элемента не изменился, значит, внутри него на один уровень изменений не было. После этого нам нужно взять все дочерние папки и идти обходить по ним вглубь. Также это позволяет отслеживать "моргающие" файлы и папки, которые были удалены и созданы заново.  Зачем так хитро? Ответ в балансе удобства и производительности: при изменении в самом низу иерархии не пересчитывать все CRC наверх.  Пара слов про сохранение прав у файлов и папок. По умолчанию, ACL читаются и хранятся на уровне папок. Когда доходит до восстановления, права для файлов просто наследуются. Если такой подход вам не подходит и необходимо хранить права на каждый файл отдельно, это можно указать в настройках бекапа. Но будьте готовы к серьёзному замедлению процесса.  Причины такого поведения для меня были довольно неожиданны: изменения в Security Info не изменяют Modification Time у файла. И поэтому, чтобы понять, не поменялось ли чего, нужно перечитывать все Security Info, отчего резко увеличивается время на выполнение. Отлично, вот мы нашли изменившиеся файлы, и возникает вопрос: а что именно (и как) надо забирать в бекап? К сожалению, блочный бекап здесь невозможен, поэтому придётся бекапить файлы целиком, а значит, надо отталкиваться от различных их версий. Вот в таких раздумьях и появился новый retention policy, основанный на версионировании.  По умолчанию бекап создаётся на Short Term репозитории, где хранятся все версии файлов за указанный период. Фактически, это хранилище для быстрого восстановления всей шары на случай, если боевая внезапно покинет сей бренный мир. В этом случае нам понадобятся все файл-версии от первого до последнего дня ретеншена.  Когда файл-версия в Short Term устаревает, он просто выкидывается. Это поведение по дефолту. Но прелесть в том, что если вам надо хранить данные с шары и дальше, то по истечении срока их можно перенести на архивное хранение, которое у нас называется Long Term Retention. Обычно оборудование для Short Term репозитория — это хорошее дорогое хранилище с быстрыми дисками. А хранить на таком файлы, которые особо никому и не нужны было бы инженерным преступлением. Поэтому мы предусмотрели возможность скидывать устаревшие файлы на медленное хранилище.   Версии в Long Term архив уезжают, только когда проходит заданный период. То есть если Short Term выставлен в 28 дней, то в архив поедет версия через 28 дней, при условии, что она устарела (читай, появилась более свежая версия файла). Важно понимать, что из архива уже нельзя восстановить всю шару в два клика, а только через File-Level Restore. Поэтому можно указать, что если файл был удалён, то хранить его следует не более стольки-то версий. Или наоборот — хранить столько-то версий файла, пока он существует на хранилище. Это делается с помощью пунктов Active File Version и Deleted File Version. Плюс есть настройки фильтров по расширениям файлов, чтобы выбрать, какие именно файлы будут или не будут переноситься в Long Term.  Соответственно, самая свежая копия файла всегда будет находить в Short term репозитории. А чтобы ей оказаться в архиве, файл должен измениться хотя бы один раз. То есть сборник хентая или другие статичные файлы вроде .ISO никогда не попадут в архив. За одним исключением: если файл удалить с шары, в бекапе он отметится как удалённый и окажется в архиве. Немного практики: предположим, что у нас есть файл, который меняется каждый день, раз в день делается бекап, и Short Term Retention установлено 3.
Значит, после трёх дней и трёх бекапов в репозитории будет лежать три версии этого файла. На четвёртый день создастся четвёртая версия, а первая будет помещена в Long Term репозиторий.  Теперь посмотрим, как на уровне файлов и папок выглядит бекап в репозитории.
Самое интересное — общие метаданные — хранится в файле .vstore В нём описан весь бекап: что за файлы, откуда они взялись, сколько они хранятся и т.д. Там же находятся папки c GUID номерами. Каждая папка соответствует одному источнику бекапа (читай, шаре в задании). В каждой такой папке находится .vsource файл, описывающий уже только файлы, принадлежащие одному источнику. Рядом с ним лежат папки meta и data. В meta лежат файлы .vindex и .vslice. Vindex описывает сами файлы и их свойства, а vslice содержит расположение блобов с данными в папке data. Как мы видим, meta — это быстро и часто меняющиеся файлы, да ещё и с параллельным доступом. Поэтому, пожалуйста, не надо никаких дедуплицирующих стораджей. Пожалейте и себя, и читающих ваши гневные отзывы.
Сами блобы — это файлы .vblob с бинарными данными, каждый размером примерно 64 мегабайта, размещённые в папках по одному гигабайту. Если такое размещение информации кажется странным, значит, вы просто не работали с объектными хранилищами, где вся информация хранится ровно так же. То есть мы сразу подготавливаем файлы для архивного хранения, чтобы в дальнейшем избежать длительной трансформации. И есть запасная папка metabackup. Это копия папки meta на случай утери оригинала. В SOBR она лежит на разных экстентах — для пущей отказоустойчивости. Так что здесь мы убили сразу несколько зайцев:  Теперь окинем взглядом всё вышеописанное и подведём небольшие итоги. Совершенно очевидно, что нет никакой проблемы восстановить несколько файлов/папок обратно на NAS или куда-то в другое место. Или даже восстановить всё хранилище целиком в новом месте. Гораздо интересней случай, когда часть файлов была зашифрована, случайно удалена или ещё как-то испорчена, из-за чего надо восстановить множество файлов в самых разнообразных папках, и делать это вручную крайне сложно и неэффективно. Тут вам на помощь приходит возможность откатиться на определённый момент времени Rolling back to a point in time. Мы можем выяснить, какие файлы были изменены, и перезаписать их нужной версией из бекапа. Система сама найдёт все изменившиеся файлы и спасёт ваши данные.
Подобный функционал есть в базах данных, когда вместо восстановления всей базы они просто отменяют все транзакции до определённого момента.   И, само собой, была добавлена полная поддержка в Veeam ONE — для мониторинга. Основной упор сделан на возможность понять, что именно изменилось с момента последнего бекапа: сколько файлов изменилось, какой объём данных пришлось скачать, какая часть инфраструктуры тормозила процесс, и т.д. Фактически получился неплохой мониторинг для самого NAS на случай, если у него нет встроенных средств. А из внутренних механизмов никуда не делся Storage-level corruption guard. Он запускается по расписанию и перечитывает все данные в бекапе, проверяя соответствие информации из базы данных с реальным контентом на репозитории. В случае расхождения данных он попытается всё восстановить или рапортует о неконсистентном состоянии бекапа. Официальная документация по NAS Backup
Вся документация по продуктам Veeam
Здесь можно скачать и заодно получить лицензию на месяц
А здесь можно обратиться в сапорт, если всё сломалось. Даже если у вас пробная лицензия.
Форум, где можно обсудить продукт напрямую с ответственными за него Пишу тексты пальцами