Уже несколько месяцев прошло с момента релиза Veeam Backup & Replication 10. Даже была обзорная статья про грядущий релиз. А вот пост-релизной статьи посвящённой более детальному и техническому разбору самой ожидаемой функции новой версии — NAS Backup, так и не было.
Поэтому надо срочно исправляться.
Давайте будем блюсти ритуалы и в первую очередь посмотрим на сухую спецификацию поддерживаемых технологий:
- SMB(CIFS) файловые шары версий 1, 2 и 3. Начиная с версии 3.0, доступны Microsoft VSS снапшоты
- NFS шары версий 3.0 и 4.1
- Гранулярный рестор отдельных файлов и возможность отката на определённый момент времени.
- Поддержка Linux и Windows file серверов
- Гибкие политики рестора: файлы можно не только всегда перезаписывать или пропускать, но заменять только изменившиеся с момента бекапа файлы (как более новые, так и более старые)
- Возможность выбирать метод бекапа: с помощью Microsoft VSS, напрямую или из storage snapshots.
- Новая политика хранения архивных копий, основанная на версионировании.
- Обязательно иметь железо с подержкой NDMP не надо. Забудьте как страшный сон.
Теперь, когда вводные даны, давайте сначала разберёмся, на какие вопросы предстояло найти ответы перед тем, как начать разрабатывать новую функцию.
- Как быстро обрабатывать петабайты неструктурированных данных? Слово “неструктурированных” здесь главное. А обработать — не значит просто прочитать. Данные ещё надо передать из пункта А в пункт В, хранить, и весь процесс должен быть устроен так, чтобы он не занимал дни или недели.
- Как обеспечить легкое масштабирование всех компонентов, участвующих в бекапе? Легко сделать систему, адаптированную под два десятка гигабайт, или наоборот, под сотни петабайт. Но вызов в том, чтобы твоё решение одинаково хорошо работало на любых объёмах.
- Вероятно, самое сложное для NAS: как обеспечить быстрое и точное создание инкрементов, да ещё и на файловом уровне. Чтобы поиск изменившихся файлов не длился вечность, а в случае потери единичных файлов не приходилось перезаписывать целые тома.
- Как обеспечивать консистентность данных там, где зачастую даже CRC доверять нельзя?
- И как сделать так, чтобы итоговое решение не требовало от клиентов покупки специфического железа, а работало на уже имеющемся оборудовании.
В поисках ответов пришлось многое делать с нуля, и сегодня мы представляем вам результат.
Что под капотом
Давайте теперь пройдёмся по всем компонентам, участвующим в успешном создании бекапа.
Первым будет сам NAS. Забрать с него файлы мы можем тремя путями, реализованными в Veeam:
- Метод лобовой атаки: просто взять и скачать. Читаем список файлов, начинаем их копировать, если находим залоченный файл — запоминаем его, ждём, пробуем ещё раз через какое-то время, пишем результат в репорт. Очень простой и быстрый метод. И что самое важное — вполне устраивающий многие компании, даже несмотря на пропуски залоченных файлов. Благо, скорее всего, они попадут в бекап при следующем инкременте. И это действительно многим подходит. Сами в шоке.
- Следом идёт более сложный, но уже обеспеичвающий консистентнсть бекап через VSS снапшот. Само собой, доступен он только там, где поддерживается эта функция. И не надо думать, что VSS — это удел Windows серверов. Вот вам заклинание, которое в одну строчку включит VSS на Netapp: vssserver cifs options modify -vserver SVM_CIFS -shadowscopy-enable true
Останется только добавить реверс DNS, если шара добавлена по IP — и вы восхитительны.
Кстати, бытует мнение, что VSS снапшот снижает нагрузку на хранилище. В общем случае это не так, поскольку располагается он на том же железе, что и основной LUN. Вот в случае Windows снижения нагрузки можно достичь, если читать снапшот offhost. У многих стораджей тоже есть подобная функция, но её реализация зачастую стоит серьёзных денег. - И самый продвинутый, позволяющий делать всё максимально быстро и быть уверенным в консистентности данных, способ — бекап через storage snapshot. Здесь уже не обойтись без специализированных решений, но на выходе мы получаем минимальную нагрузку на продакшн и гарантию в сохранности данных. Но надо учитывать, что мы чисто физически не смогли бы реализовать поддержку всех на свете NAS решений, поэтому реализация механизма создания снапшотов пока оставлена на стороне пользователя.
Теперь рассмотрим две новые для 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 она лежит на разных экстентах — для пущей отказоустойчивости.
Так что здесь мы убили сразу несколько зайцев:
- В таком виде можно хранить миллионы файлов, не переживая за их суммарный объём.
- Производительность такой системы практически не зависит от фрагментации данных на дисках.
Теперь окинем взглядом всё вышеописанное и подведём небольшие итоги.
- Бекап работает с отдельными файлами. Не важно, обычная это SMB шара или огромный NAS, умеющий делать снапшоты — в конечном итоге бекапятся отдельные файлы, а не образы папок, изменившиеся блоки или нечто в этом духе. Можно даже себе большой плакат распечатать: файлы на уровне файл-версий, а не поблочные изменения, как, например, при бекапе виртуальных машин!
- За счёт возможности балансировки нагрузки между несколькими file proxy можно организовать практически бесконечное распараллеливание процесса бекапа (конечно, пока мы не упрёмся в возможности самого NAS), добиваясь максимально возможной производительности.
- Инкрементный бекап делается максимально быстро, так как а) в первую очередь проверяются аттрибуты папок в) нам не надо обращаться к файлам бекапа
- Новый формат хранения, разработанный для возможности хранения миллионов файлов на многие петабайты данных, без потери производительности.
- Встроенные механизмы сжатия и шифрования.
- Если вы не первый год используете Veeam, то по-прежнему всё настраивается через Next>Next>Finish и просто начинает работать. Если вы новый пользователь, значит, будете приятно удивлены.
Как это восстанавливает
Совершенно очевидно, что нет никакой проблемы восстановить несколько файлов/папок обратно на NAS или куда-то в другое место. Или даже восстановить всё хранилище целиком в новом месте.
Гораздо интересней случай, когда часть файлов была зашифрована, случайно удалена или ещё как-то испорчена, из-за чего надо восстановить множество файлов в самых разнообразных папках, и делать это вручную крайне сложно и неэффективно. Тут вам на помощь приходит возможность откатиться на определённый момент времени Rolling back to a point in time. Мы можем выяснить, какие файлы были изменены, и перезаписать их нужной версией из бекапа. Система сама найдёт все изменившиеся файлы и спасёт ваши данные.
Подобный функционал есть в базах данных, когда вместо восстановления всей базы они просто отменяют все транзакции до определённого момента.
Как это мониторится
И, само собой, была добавлена полная поддержка в Veeam ONE — для мониторинга. Основной упор сделан на возможность понять, что именно изменилось с момента последнего бекапа: сколько файлов изменилось, какой объём данных пришлось скачать, какая часть инфраструктуры тормозила процесс, и т.д. Фактически получился неплохой мониторинг для самого NAS на случай, если у него нет встроенных средств.
А из внутренних механизмов никуда не делся Storage-level corruption guard. Он запускается по расписанию и перечитывает все данные в бекапе, проверяя соответствие информации из базы данных с реальным контентом на репозитории. В случае расхождения данных он попытается всё восстановить или рапортует о неконсистентном состоянии бекапа.
Немного полезных ссылок на последок
Официальная документация по NAS Backup
Вся документация по продуктам Veeam
Здесь можно скачать и заодно получить лицензию на месяц
А здесь можно обратиться в сапорт, если всё сломалось. Даже если у вас пробная лицензия.
Форум, где можно обсудить продукт напрямую с ответственными за него
