В прошлой статье мы говорили об истории развития Microsoft Data Protection Manager. Сегодня предлагаем пойти дальше. Вы узнаете о том, как он работает технически, с заглядыванием на страшного зверя VSS.
Передаю слово автору статьи, khabarovdaniil (Даниилу Хабарову).
Меня всегда радовало то, как DPM умеет работать с дисками, а еще больше меня радовало отвечать на вопросы формата: «А почему он создает столько дисков», «А как можно разобраться с их количеством».
Итак, для того, чтобы понять почему и как работает DPM необходимо понять базовые вещи, связанные с замечательной технологией VSS. Как говорит нам сайт Technet. Нас здесь будет интересовать следующие вещи:
VSS — это фреймворк, который позволяет выполнять операции резервного копирования, пока приложение продолжает работать и записывать на том. По своей сути, он состоит из трех больших элементов:
А на картинке это выглядит следующим образом:
Подробнее про них имеет смысл разговаривать при описании работы механизма резервного копирования приложения, а сейчас нам нужно понять, как это связано с организацией хранения резервных копий на дисках.
Итак, если стараться и приводить аналогии, то VSS очень напоминает лук. Да-да, тот самый лук из мультфильма Шрек, и именно потому, что он — многослойный. Каждый слой VSS лука является, так называемой, DiffArea, которые, складываясь вместе превращаются из разрозненных элементов в целую луковицу.
Для создания резервной копии и ее записи на диск, DPM, как вам известно, создает 2 тома. На одном томе хранится, так называемый, initial backup, тот самый который создается при первоначальной синхронизации. По общепринятой терминологии, это будет Full Backup. Для того, чтобы сделать резервную копию актуальной, DPM производит регулярные синхронизации, которые вы задаете при создании Группы защиты (Protection Group).
А вот дальше начинается магия того самого «шрековского» лука. На втором томе, который на момент создания первоначальной копии является пустым, начинают создаваться так называемые, DiffArea. Вопреки вашим ожиданием, на DiffArea сохраняются не изменения, а исторические данные. То есть, выглядит это следующим образом:
1. Первоначальная синхронизация произошла, у нас есть данные:
2. В момент времени 1 создана первая DiffArea1, которая хранит изначальное состояние диска:
3. Аналогично предыдущему рисунку:
4. Аналогично предыдущему рисунку:
5. Конечное состояние диска:
Каждая новая DiffArea хранит в себе исторические данные о предыдущем состоянии. Таким образом, у нас получается приблизительно такой комикс, как нарисовано выше. Чтобы получить первоначальное состояние данных AAAAAAA нам нужно сложить последовательно все слои (визуально следуя иллюстрациям).
Каждого из вас, кто читает эти строки, конечно же, интересует, куда же сохраняются эти данные. А вот тут мы вернемся к вариантам размещения данных, которое предоставляется VSS. В целом, он позволяет очень гибко и удобно размещать данные. В случае, если мы рассматриваем работу VSS внутри DPM, то тут схема выглядит таким образом:
По этой иллюстрации видно, что у нас на одном сервере хранятся данные, а также и теневые копии. Их можно с помощью набора VSS context разнести по разным томам, или же хранить на том же самом. Каждый, кто так или иначе, использовал службу резервного копирования даже на уровне домашней операционной системы, наблюдал, как это работает. Теневые копии сохраняются на диск, но не видимы при просмотре обычными средствами, и даже не занимают пространства, если верить Disk Manager.
С помощью VSS context вы можете также задать и другие параметры, такие как: можно ли монтировать теневую копию, является ли эта резервная копия приложения, и многое другое. Суть в том, что с помощью контекста вы задаете основные правила по которым вы сможете в дальнейшем работать с этими резервными копиями. Задается это на уровне приложения, и DPM в нашем случае.
Для трепетных читателей, которые хотят в деталях узнать о том, как работает VSS, мы сможем продолжить цикл рассказов в будущем.
И завершая тему VSS, хочется, пожалуй, добавить, что он предоставляет огромное количество возможностей, которые зачастую неизвестны, или же не интересны обывателю, но тем не менее, работа с внешними Hardware Providers, с разными LUNами, разнообразные контексты снимков, а также механизм создания Bitmap меня всегда заставлял радоваться за технологический прогресс и возможности резервного копирования.
Если применять все вышеперечисленно на практический смысл DPM, то мы получаем следующее:
В завершении своего рассказа, хочу заметить, что в следующий раз мы будем говорить про DPM 2016, его новые возможности, а, в случае, если многоуважаемая публика проявит интерес к нашему сериалу, мы сможем поговорить о возможных путях решения вышеобозначенных проблем, а также некоторых слабодокументированных возможностях.
Очень надеюсь, что смог на комиксах объяснить, как это работает, и почему это именно так.
Всем спасибо за внимание, и до новых встреч!
Передаю слово автору статьи, khabarovdaniil (Даниилу Хабарову).
План всего рассказа такой:Привет, сообщество, это снова я, и сегодня, как и было обещано, мы будем говорить о том, как DPM работает внутри.
В первой части мы поговорим про исторический контекст Microsoft Data Protection Manager, и то, почему он такой.
Во второй — о том, как он работает технически, с заглядыванием на страшного зверя VSS.
Ну а в третьей — текущее положение дел, что он умеет и как мы это сможем использовать, в том числе и с Microsoft Azure Backup.
Меня всегда радовало то, как DPM умеет работать с дисками, а еще больше меня радовало отвечать на вопросы формата: «А почему он создает столько дисков», «А как можно разобраться с их количеством».
Microsoft Data Protection Manager и лук
Итак, для того, чтобы понять почему и как работает DPM необходимо понять базовые вещи, связанные с замечательной технологией VSS. Как говорит нам сайт Technet. Нас здесь будет интересовать следующие вещи:
VSS — это фреймворк, который позволяет выполнять операции резервного копирования, пока приложение продолжает работать и записывать на том. По своей сути, он состоит из трех больших элементов:
- VSS writer
- VSS provider
- VSS requestor
А на картинке это выглядит следующим образом:
Подробнее про них имеет смысл разговаривать при описании работы механизма резервного копирования приложения, а сейчас нам нужно понять, как это связано с организацией хранения резервных копий на дисках.
Итак, если стараться и приводить аналогии, то VSS очень напоминает лук. Да-да, тот самый лук из мультфильма Шрек, и именно потому, что он — многослойный. Каждый слой VSS лука является, так называемой, DiffArea, которые, складываясь вместе превращаются из разрозненных элементов в целую луковицу.
Для создания резервной копии и ее записи на диск, DPM, как вам известно, создает 2 тома. На одном томе хранится, так называемый, initial backup, тот самый который создается при первоначальной синхронизации. По общепринятой терминологии, это будет Full Backup. Для того, чтобы сделать резервную копию актуальной, DPM производит регулярные синхронизации, которые вы задаете при создании Группы защиты (Protection Group).
Переходим к магии
А вот дальше начинается магия того самого «шрековского» лука. На втором томе, который на момент создания первоначальной копии является пустым, начинают создаваться так называемые, DiffArea. Вопреки вашим ожиданием, на DiffArea сохраняются не изменения, а исторические данные. То есть, выглядит это следующим образом:
1. Первоначальная синхронизация произошла, у нас есть данные:
2. В момент времени 1 создана первая DiffArea1, которая хранит изначальное состояние диска:
3. Аналогично предыдущему рисунку:
4. Аналогично предыдущему рисунку:
5. Конечное состояние диска:
Каждая новая DiffArea хранит в себе исторические данные о предыдущем состоянии. Таким образом, у нас получается приблизительно такой комикс, как нарисовано выше. Чтобы получить первоначальное состояние данных AAAAAAA нам нужно сложить последовательно все слои (визуально следуя иллюстрациям).
Каждого из вас, кто читает эти строки, конечно же, интересует, куда же сохраняются эти данные. А вот тут мы вернемся к вариантам размещения данных, которое предоставляется VSS. В целом, он позволяет очень гибко и удобно размещать данные. В случае, если мы рассматриваем работу VSS внутри DPM, то тут схема выглядит таким образом:
По этой иллюстрации видно, что у нас на одном сервере хранятся данные, а также и теневые копии. Их можно с помощью набора VSS context разнести по разным томам, или же хранить на том же самом. Каждый, кто так или иначе, использовал службу резервного копирования даже на уровне домашней операционной системы, наблюдал, как это работает. Теневые копии сохраняются на диск, но не видимы при просмотре обычными средствами, и даже не занимают пространства, если верить Disk Manager.
С помощью VSS context вы можете также задать и другие параметры, такие как: можно ли монтировать теневую копию, является ли эта резервная копия приложения, и многое другое. Суть в том, что с помощью контекста вы задаете основные правила по которым вы сможете в дальнейшем работать с этими резервными копиями. Задается это на уровне приложения, и DPM в нашем случае.
Для трепетных читателей, которые хотят в деталях узнать о том, как работает VSS, мы сможем продолжить цикл рассказов в будущем.
Но а для тех, кто хочет увидеть всю картину сразу, с радостью привожу справочный материал, который довольно полно описывает принцип работы VSS.
И завершая тему VSS, хочется, пожалуй, добавить, что он предоставляет огромное количество возможностей, которые зачастую неизвестны, или же не интересны обывателю, но тем не менее, работа с внешними Hardware Providers, с разными LUNами, разнообразные контексты снимков, а также механизм создания Bitmap меня всегда заставлял радоваться за технологический прогресс и возможности резервного копирования.
Итог
Если применять все вышеперечисленно на практический смысл DPM, то мы получаем следующее:
- Количество дисков DPM определяется исключительно системой и напрямую не может быть исправлено пользователем. В связи с этим у многих администраторов возникало кроме множества вопросов, еще и множество проблем:
a. Logical Disk Manager при определенном стечении обстоятельств, может препятствовать созданию резервных копий. Суть в том, что LDM обладает ограничениями, потому что не может поддерживать более 2950 дисков. Это относится ко всем дискам, включая физические. Чтобы избежать этого, необходимо хорошее планирование Protection Group.
b. Количество теневых копий ограничено. Как многие знают, максимальное количество теневых копий — 64. Это означает, что если вы хотите сделать на диске большое количество копий — нужно искать альтернативы. - DPM использует исключительно штатные механизмы резервного копирования, которые предусмотрены ОС, поэтому и существуют все вышеобозначенные ограничения. Плюс такого решения — в безусловной поддерживаемости резервного копирования с точки зрения всех MS технологий. Именно благодаря этому мы имеем полноценную возможность использования DPM для бекапа AD, что является одним из самых больших плюсов его использования в корпоративной среде.
В завершении своего рассказа, хочу заметить, что в следующий раз мы будем говорить про DPM 2016, его новые возможности, а, в случае, если многоуважаемая публика проявит интерес к нашему сериалу, мы сможем поговорить о возможных путях решения вышеобозначенных проблем, а также некоторых слабодокументированных возможностях.
Очень надеюсь, что смог на комиксах объяснить, как это работает, и почему это именно так.
Всем спасибо за внимание, и до новых встреч!
