Резервное Копирование Nas И Никакой Магии. Глубокое Погружение От Veeam

Прошло несколько месяцев с момента релиза Veeam Резервное копирование и репликация 10 .

Появилась даже обзорная статья о предстоящем релизе.

Но не было пострелизной статьи, посвящённой более подробному и техническому анализу самой ожидаемой функции новой версии — NAS Backup. Поэтому нам срочно нужно это исправить.

Давайте следовать ритуалам и в первую очередь посмотрим на сухую спецификацию поддерживаемых технологий:

• Файловые ресурсы SMB(CIFS) версий 1, 2 и 3. Начиная с версии 3.0 доступны снимки Microsoft VSS.
• Шарики NFS версии 3.0 и 4.1
• Детальное восстановление отдельных файлов и возможность отката к определенному моменту времени.

• Поддержка файловых серверов Linux и Windows.
• Гибкая ресторанная политика: файлы не только всегда можно перезаписать или пропустить, но и заменить можно только те файлы, которые изменились с момента резервного копирования (как более новые, так и старые)
• Возможность выбора метода резервного копирования: с помощью Microsoft VSS, напрямую или из снимков хранилища.

• Новая политика хранения резервных копий, основанная на управлении версиями.

• Не обязательно иметь оборудование с поддержкой NDMP. Забудь об этом, как о дурном сне.

1. Как быстро обрабатывать петабайты неструктурированных данных? Слово «неструктурированный» здесь является ключевым словом.

   И обработка не означает просто чтение.

   Данные еще нужно перенести из точки А в точку Б, сохранить, и весь процесс нужно выстроить так, чтобы он не занимал дни или недели.

2. Как обеспечить простое масштабирование всех компонентов, участвующих в резервном копировании? Легко сделать систему, адаптированную под два десятка гигабайт или наоборот, под сотни петабайт. Но задача состоит в том, чтобы гарантировать, что ваше решение одинаково хорошо работает на любом томе.

3. Наверное, самое сложное для NAS: как обеспечить быстрое и точное создание инкрементов, да еще и на файловом уровне.

   Чтобы поиск измененных файлов не занимал вечность, и в случае потери отдельных файлов не пришлось перезаписывать целые тома.

4. Как обеспечить согласованность данных там, где часто нельзя доверять даже CRC?
5. И как сделать так, чтобы итоговое решение не требовало от клиентов приобретения определенного оборудования, а работало на существующем оборудовании.

Что под капотом

Первым будет сам NAS. Брать файлы из него мы можем тремя способами, реализованными в Veeam:

• Метод лобовой атаки: просто возьмите и скачайте.

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

  К счастью, скорее всего, они будут скопированы во время следующего инкремента.

  И это действительно многих устраивает. Вы сами в шоке.

• Дальше идет более сложное, но уже обеспечивающее согласованность резервное копирование через Снимок VSS .

  Конечно, это доступно только там, где эта функция поддерживается.

  И не думайте, что VSS — это домен серверов Windows. Вот заклинание, которое включит VSS в Netapp в одной строке: параметры vssserver cifs модифицируют -vserver SVM_CIFS -shadowscopy-enable true Остается только добавить обратный DNS, если шара добавлена по IP - и вы молодцы.

  Кстати, есть мнение, что VSS снапшот снижает нагрузку на хранилище.

  В целом это не так, поскольку он находится на том же оборудовании, что и основной LUN. В случае с Windows снижения нагрузки можно добиться путем чтения внехостового снимка.

  Подобная функция есть и у многих сторажей, но ее реализация часто стоит серьезных денег.

• А самый продвинутый метод, позволяющий сделать все максимально быстро и быть уверенным в целостности данных – резервное копирование через снимок хранилища .

  Здесь без специализированных решений уже не обойтись, но в итоге мы получаем минимальную нагрузку на производство и гарантию сохранности данных.

  Но надо учитывать, что мы физически не сможем реализовать поддержку всех NAS-решений в мире, поэтому реализация механизма создания снапшотов по-прежнему остается за пользователем.

Его задача — обеспечить быстрое создание инкрементов и снизить нагрузку на файловый ресурс при резервном копировании.

Репозиторием кэша может быть либо выделенный сервер Windows/Linux, либо любой общий ресурс CIFS(SMB)/NFS. Этот кэш используется исключительно для ускорения создания инкрементов и восстановления отдельных файлов, поэтому его можно потерять без каких-либо критических последствий.

При следующем запуске резервной копии она просто будет создана заново.

Да, это займет некоторое время, но без него все было бы гораздо дольше.

Естественно, для максимальной производительности кэш должен располагаться как можно ближе к резервируемому NAS и желательно на SSD. И роль его назначена любой репозиторий в инфраструктуре Veeam, за исключением облачных, дедуплицированных и SOBR. О структуре метаданных и о том, зачем они нужны, мы поговорим чуть ниже.

Теперь давайте посмотрим на файловый прокси.

Этот компонент, по сути, является полным аналогом старого доброго Backup Proxy, только для работы с NAS. Суть не изменилась — прокси играет связующую роль между остальными компонентами, участвующими в резервном копировании, и отвечает за отправку данных из продаж в резервное хранилище.

По умолчанию эту роль выполняет сам сервер Veeam, но такой вариант использования подходит только для небольших установок, где все компоненты расположены в одном сегменте сети.

Для более интересных вариантов нужно выделить под прокси отдельные машины с Windows. А еще лучше, когда их несколько, поскольку они умеют балансировать нагрузку.

Но подробности, опять же, будут ниже.

Кстати, технически ничто не мешает вам использовать существующие прокси для новой роли.

Вам даже не придется устанавливать новые компоненты.

Просто следите за окном загрузки и резервного копирования.

Как это работает

Давайте сначала посмотрим на репозиторий кэша.

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

Здесь нет никакой магии.

Но с постепенными запусками начинается самое интересное.

Чтобы найти данные, изменившиеся с момента последнего запуска, Veeam строит дерево файлов и папок и вычисляет CRC для каждой папки и файла (о том, как именно, мы поговорим через пару абзацев ниже).

А для большей скорости в работе размещает его целиком в оперативной памяти.

Наша реализация позволяет уместить дерево из двух миллионов папок в 70 Мб.

В ходе инкрементного запуска строится новое дерево, которое сравнивается с существующим и определяются места с измененными файлами/папками, которые необходимо взять в резервную копию.

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

По этой же причине вам не придется беспокоиться о кеше: в случае его потери он будет воссоздан из метаданных в резервной копии.

И еще одна важная деталь в случае общения со специалистами по безопасности: кэш репозитория никак не взаимодействует с реальными данными, хранящимися на NAS. Данные обрабатывает файловый прокси, а хранилище кэша лишь координирует их работу.

Соответственно, пришло время разобраться с File Proxy. Они делают две вещи: просматривают папки в поисках изменений (и создают CRC) и передают данные.

Это тот самый компонент, благодаря которому мы можем масштабироваться.

Главное следить за процессором.

И тут может возникнуть вопрос: а где масштабирование, если на одном прокси всё можно ограничить процессором? Ответ — возможность использовать сразу несколько прокси для одного хранилища кэша.

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

Прокси производит расчет, возвращает результат в кэш и получает новую папку для расчета.

И так до тех пор, пока они не закончатся.

Это означает, что чем больше у вас прокси (и ЦП на них), тем больше папок будет рассчитываться одновременно (читай, параллельно).

Единственное, что хочу отметить, лучше всего это работает с шарами CIFS, где можно сразу обратиться по любому адресу.

В случае с NFS могут возникнуть трудности, так как для того, чтобы открыть папку или файл, нужно сначала пройти всю иерархию.

Но мы никак не можем повлиять на это.

Как получается само дерево CRC? Как правило, чтобы вычислить CRC файла, его необходимо прочитать полностью.

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

Что несколько дорого.

А еще есть свертка каталогов, которая включает CRC содержимого файла.

Однако не все так плохо, и бывает, что CRC рассчитывается уже на уровне файловой системы, как это работает, например, с VMware ChangeTracking. Но жаль, что у нас нет такой роскоши.

С другой стороны, ничто из этого не мешает файловому ресурсу вообще сообщать что-либо, включая дату изменения файла и его размер.

Здесь мы можем рассчитывать только на то, что файловая система содержит указание на дату последней записи, и это хотя бы можно проверить.

Кстати, плохой совет домохозяйке на заметку: в Windows можно отключить обновление времени последней записи в файл, что неплохо ускоряет работу диска.

Правда, никто вам за это спасибо не скажет, но если вы борец с IOPS, это ваш путь самурая.

Поэтому наш вариант — составная CRC атрибутов папки и атрибутов дочерних элементов уровнем ниже.

А именно, расчет включает в себя: время модификации каждого файла, время создания каждого файла, имя каждого файла и информацию о безопасности папки.

Если вы тоже хотите положиться на размер файла, то вот еще интересный факт — при резервном копировании снимка с помощью VSS Windows не всегда выдает правильный размер файла.

Поэтому использовать его (размер файла) в CRC — плохая идея.

Одним словом, наш вариант позволяет построить достаточно легкое дерево и быстро находить измененные места.

Соответственно, если CRC для элемента верхнего уровня не изменился, это означает, что внутри него не было изменений ни на одном уровне.

После этого нам нужно взять все дочерние папки и пройтись по ним поглубже.

Он также позволяет отслеживать «мигающие» файлы и папки, которые были удалены и воссозданы.

Почему так хитро? Ответ — баланс между удобством и производительностью: при изменении в самом низу иерархии не пересчитывать все CRC наверх.

Несколько слов о сохранении прав на файлы и папки.

По умолчанию списки ACL читаются и сохраняются на уровне папки.

При восстановлении права на файлы просто наследуются.

Если вас такой подход не устраивает и вам нужно хранить права на каждый файл отдельно, вы можете указать это в настройках резервного копирования.

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

Причины такого поведения оказались для меня весьма неожиданными: изменения в Security Info не меняют Время модификации файла.

И поэтому, чтобы понять, изменилось ли что-нибудь, нужно перечитать всю Security Info, что резко увеличивает время выполнения.

Отлично, теперь мы нашли измененные файлы, и возникает вопрос: что именно (и как) нужно взять в резервную копию? К сожалению, блочное резервное копирование здесь невозможно, поэтому вам придется копировать файлы целиком, а значит начинать нужно с разных версий.

Именно в этих мыслях появилась новая политика хранения, основанная на версионировании.

По умолчанию резервная копия создается в хранилище Short Term, где хранятся все версии файлов за указанный период. По сути, это хранилище для быстрого восстановления всего шара на случай, если боевой вдруг покинет эту бренную оболочку.

В этом случае нам потребуются все версии файлов от первого до последнего дня хранения.

Когда краткосрочная версия файла устаревает, ее просто выбрасывают. Это поведение по умолчанию.

Но прелесть в том, что если вам нужно хранить данные из общих ресурсов и дальше, то по истечении срока их действия их можно перенести на архивное хранение, которое мы называем Long Term Retention. Обычно оборудование для краткосрочного репозитория — это хорошее, дорогое хранилище с быстрыми дисками.

А хранить на таком сайте файлы, которые никому особо не нужны, было бы инженерным преступлением.

Поэтому мы предусмотрели возможность сбрасывать устаревшие файлы на медленные хранилища.

Версии в долгосрочном архиве удаляются только по истечении указанного периода.

То есть, если Short Term установлен на 28 дней, то версия будет заархивирована через 28 дней, при условии, что она устарела (читай, появилась более свежая версия файла).

Важно понимать, что восстановить весь файл из архива в два клика уже невозможно, а только через File-Level Restore. Поэтому вы можете указать, что если файл был удален, то должно храниться не более такого-то количества версий.

Или наоборот — хранить столько версий файла, сколько он существует в хранилище.

Это делается с помощью Элементы «Активная версия файла» и «Удаленная версия файла» .

Кроме того, существуют настройки фильтра для расширений файлов, позволяющие выбрать, какие файлы будут или не будут перенесены в долгосрочную перспективу.

Соответственно, самая последняя копия файла всегда будет находиться в краткосрочном репозитории.

А чтобы он оказался в архиве, файл должен измениться хотя бы один раз.

То есть хентай-коллекция или другие статические файлы типа .

ISO никогда не попадут в архив.

За одним исключением: если файл будет удален из файла, он будет помечен как удаленный в резервной копии и попадет в архив.

Немного практики: предположим, у нас есть файл, который меняется каждый день, резервная копия создается раз в день, а для параметра Short Term Retention установлено значение 3. Это означает, что через три дня и три резервных копии в хранилище будет три версии этого файла.

На четвертый день будет создана четвертая версия, а первая будет помещена в долгосрочный репозиторий.

Теперь посмотрим, как выглядит резервная копия в репозитории на уровне файлов и папок.

Самое интересное — общие метаданные — хранятся в файле .

vstore. В нем описан весь бэкап: что это за файлы, откуда они взялись, как долго хранятся и т.д. Также есть папки с номерами GUID. Каждая папка соответствует одному источнику резервного копирования (читай, доле в задаче).

Каждая такая папка содержит файл .

vsource, описывающий только файлы, принадлежащие одному источнику.

Рядом с ним находятся папки мета и данных.

Мета содержит файлы .

vindex и .

vslice. Vindex описывает сами файлы и их свойства, а vslice содержит расположение объектов данных в папке данных.

Как мы видим, мета — это быстро и часто меняющиеся файлы, да ещё и с параллельным доступом.

Поэтому, пожалуйста, не нужно никакого дедупликационного хранилища.

Пожалейте себя и тех, кто читает ваши гневные отзывы.

Сами большие двоичные объекты представляют собой файлы .

vblob с двоичными данными, каждый размером примерно 64 мегабайта, расположенные в папках по одному гигабайту.

Если такое расположение информации кажется странным, значит, вы просто не работали с объектными хранилищами, где вся информация хранится совершенно одинаково.

То есть мы сразу готовим файлы к архивному хранению, чтобы в дальнейшем избежать длительной трансформации.

И есть запасная папка метабэкапа.

Это копия метапапки на случай, если вы потеряете оригинал.

В СОБРе оно лежит на разных экстентах - для большей отказоустойчивости.

Вот и тут мы убили сразу нескольких зайцев:

• В таком виде вы сможете хранить миллионы файлов, не беспокоясь об их общем объеме.

• Производительность такой системы практически не зависит от фрагментации данных на дисках.

• Резервное копирование работает с отдельными файлами.

  Неважно, обычный ли это SMB-ресурс или огромный NAS, умеющий делать снимки — в конечном итоге копируются отдельные файлы, а не образы папок, измененные блоки или что-то в этом роде.

  Можно даже распечатать себе большой плакат: файлы на уровне версии файла, а не поблочные изменения, как, например, при резервном копировании виртуальных машин!

• За счет возможности балансировки нагрузки между несколькими файловыми прокси можно организовать практически бесконечное распараллеливание процесса резервного копирования (разумеется, пока мы не упираемся в возможности самого NAS), добиваясь максимально возможной производительности.

• Инкрементное резервное копирование выполняется максимально быстро, так как а) в первую очередь проверяются атрибуты папок в) нам не требуется доступ к файлам резервных копий
• Новый формат хранения, предназначенный для хранения миллионов файлов объемом в петабайты данных без ущерба для производительности.

• Встроенные механизмы сжатия и шифрования.

• Если вы пользуетесь Veeam больше года, то все равно все настраивается через Далее> Далее> Готово и просто начинает работать.

  Если вы новый пользователь, то вы будете приятно удивлены.

Как он восстанавливает

Или даже восстановить все хранилище в новом месте.

Гораздо более интересный случай, когда часть файлов была зашифрована, случайно удалена или иным образом повреждена, из-за чего необходимо восстанавливать множество файлов в самых разных папках, а делать это вручную крайне сложно и неэффективно.

Вот тут-то вам и придет на помощь возможность откатиться к определенному моменту времени.

Откат к моменту времени .

Мы можем узнать, какие файлы были изменены, и перезаписать их правильной версией из резервной копии.

Система сама найдет все измененные файлы и сохранит ваши данные.

Аналогичный функционал есть и в базах данных, когда вместо восстановления всей базы данных просто отменяют все транзакции до определенного момента.

Как это контролируется?

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

И защита от коррупции на уровне хранилища не исчезла из внутренних механизмов.

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

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

Несколько полезных ссылок в завершение

Форум, на котором вы можете обсудить продукт напрямую с ответственными за него лицами.

Теги: #ИТ-инфраструктура #Системное администрирование #Хранение данных #Восстановление данных #nas #veeam #veeam резервное копирование и репликация

• Развлекайтесь С Помощью Своей Большой Галереи Фотографий

  19 Oct, 24

• Исключительные Планшеты Android, Которые Вам Понравятся

  19 Oct, 24

• Поставщики Услуг По Восстановлению Жестких Дисков И Вы

  19 Oct, 24

• Гиляров-Платонов Никита Петрович.

  19 Oct, 24

• Расследование Ведет «Солар Дозор»: 5 Необычных Дел, Раскрытых Длп

  19 Oct, 24

• Облако - Сортировка

  19 Oct, 24

• Калькулятор Excel Для Определения Реальной Надежности Пароля

  19 Oct, 24

• Google Внедрил Свой Сервис В Windows Vista

  19 Oct, 24

• Вторая Бета-Версия Gran Paradiso Будет Доступна В Конце Весны.

  19 Oct, 24

• Исследование Мобильного Jar-Трояна

  19 Oct, 24