С момента его первого появления, я использовал менеджер защиты данных Microsoft Data Protection Manager (DPM) в своей собственной сети для защиты данных. Я всегда думал, что DPM был превосходным приложением, но мне всегда казалось, что что-то в нем было пропущено. К счастью, компания Microsoft усердно работает над DPM версии 2, который в настоящий момент находится в бета тестировании. DPM версии 2 спроектирован для того, чтобы заполнить некоторые пустоты, которые были в менеджере защиты данных DPM 2006. В этой статье я расскажу о том, что можно ожидать от DPM версии 2.

Что такое менеджер защиты данных Data Protection Manager?

Хотя на мой взгляд менеджер защиты данных Data Protection Manager – это великолепный продукт, долгое время он оставался в тени, и не был так популярен, как многие другие продукты Microsoft Server. Он, конечно, же не так хорошо известен, как Exchange Server или SQL Server. Именно поэтому, я хочу потратить несколько минут и поговорить о том, что такое DPM, и что он делает. Все, о чем я говорю в этом разделе относится как к версии DPM 2006, так и к версии DPM version 2.

DPM – это серверное приложение, которое спроектировано для резервного копирования (back up) ваших данных. Различие между DPM и другими продуктами для резервного копирования, такими как NTBACKUP, заключается в том, что DPM спроектирован для того, чтобы обойти фундаментальные недостатки традиционных решений для резервного копирования. Существует несколько проблем с типичным продуктом для резервного копирования (backup solution). Первая проблема заключается в том, что количество данных, производимых компанией, возрастает экспоненциально. Это верно даже по отношению к небольшим сетям, таким, как моя собственная сеть. Даже простой факт сохранения документа Microsoft Word, который я пишу в настоящее время, означает, что при резервном копировании сегодня вечером у меня будет больше данных, чем при вчерашнем. Конечно, проблема с постоянно увеличивающимся числом сохраняемых в резервном архиве данных приводит к тому, что время на резервное копирования с каждым днем возрастает, т.к. увеличивается объем копируемых данных.

К несчастью, тратить все больше и больше времени на выполнение резервного копирования не входит в мои правила. Многие компании ведут свой бизнес 24 часа в сутки, поэтому долгое резервное копирование в середине ночи может быть недопустимым, т.к. файлы необходимо закрывать на время резервного копирования Такие проблемы не новы, с ними сталкиваются на протяжении многих лет. Обычно администраторы обходят проблему увеличивающихся данных путем выполнения частичного или инкрементного резервного копирования (incremental backup) в течении недели и выполнения полного резервного копирования в конце недели. В то время, как эти техники для некоторых могут сработать, даже инкрементное или частичное резервное копирование занимает время, а также приводит к снижению производительности.

Другая проблема с традиционным резервным копированием заключается в том, что резервное копирование выполняется один раз в день. Для того, чтобы увидеть, почему это может быть проблемой, представьте, что ваша компания выполняет резервное копирование данных каждую ночь в 11:00 PM и на его выполнение уходит час. Если какая-то неприятность случиться в 10:00 PM, то в результате будут потеряны все данные за целый день? В такой ситуации вы можете потерять все данные, которые были созданы с момента последнего резервного копирования (с 11:00 вечера предыдущего дня). Никто не хочет объяснить начальнику, почему целый день работы прошел даром.

Менеджер защиты данных Data Protection Manager решает эту проблему благодаря использованию технологии, известной как disk to disk to tape backup (резервное копирование с диска на диск, а затем на ленту). Основная идея заключается в том, что постоянно выполняется резервное копирование данных, полученных за день, а затем производится одно большое резервное копирование поздно ночью. Эта технология позволяет значительно снизить объем данных, которые могут быть потеряны в случае аварии в системе.

Интервал резервного копирования (backup interval) в DPM можно настроить. В моей собственной сети DPM настроен таким образом, что он выполняет резервную копию один раз в час. Таким образом, DPM просто выполняет резервную копию всего, что изменилось за последний час. Один великолепный аспект при использовании такого подхода заключается в том, что он позволяет вам поддерживать несколько версий файлов, для которых вы выполняете резервное копирование в течении дня. Например, если пользователь решает, что ему нужно восстановить документ до того состояния, в котором он был два часа назад, то у него есть такая возможность. Реальное число версий файла, которое вы можете иметь, зависит от свободного пространства на сервере, на котором размещается ваш DPM server.

Так каким же образом менеджер защиты данных DPM может осуществлять резервное копирование данных в течение дня, в то время как традиционные приложения для резервного копирования этого делать не могут? Дело в том, что DPM использует теневые копии (shadow copies) для снятия образов данных, которые необходимо сохранить. Это позволяет создать резервную копию файлов, даже если они открыты во время выполнения резервного копирования. Если DPM выполняет резервное копирование файла, то он также проверяет, производилось ли резервное копирование этого файла ранее. Если да, то выполняется резервное копирование лишь тех байтов, которые изменились с момента выполнения последнего резервного копирования. Это позволяет DPM сохранить пространство на диске, а также пропускную способность сети, что позволяем ему работать с большей эффективностью.

Что нового во второй версии (Version 2)?

На первый взгляд менеджер защиты данных DPM версии 2 выглядит почти также, как и DPM 2006. Но есть одно очень важное различие между этими двумя версиями. DPM 2006 была ограничена в плане выполнения резервного копирования файловых серверов (file server), но версия 2 DPM может также осуществлять резервное копирование серверов приложений.

Это означает, что DPM версии 2 сможет осуществлять резервное копирование файловых серверов (file server), как и в текущей версии, но также сможет осуществлять резервное копирование баз данных, связанных с Exchange Server (включая готовящийся к выходу Exchange Server 2007), SQL Servers и SharePoint Servers. Эти приложения традиционно не могли использовать механизм резервного копирования (backup mechanisms) такой, как DPM, т.к. они не полагались на резервные копии на уровне файлов (file level backup). Например, Exchange Server хранит пользовательские почтовые ящики, контакты и календарную информацию в базе данных. Однако база данных остается открытой все время. Это значит, что приложения для выполнения резервного копирования не могли просто скопировать файл базы данных. Файл базы данных мог значительно измениться к тому времени, как завершится процесс резервного копирования. Вместо этого, приложения, спроектированные для резервного копирования Exchange Server использую журналы транзакций (transaction logs) Exchange Server.

Реальный процесс резервного копирования достаточно сложен, но существует его упрощенное объяснение. Когда новые данные (например новые электронные сообщения) достигают базы данных Exchange, они записываются не напрямую в базу данных (database), а в файл журнала транзакций (transaction log file). После того, как журнал транзакций заполняется, его содержимое переносится в базу данных. Если традиционное приложение для резервного копирования выполняет резервное копирование базы данных Exchange database, то оно должно заблокировать базу данных, поэтому во время копирования журналы транзакций не переносятся в базу данных. После завершения резервного копирования базы данных, происходит резервное копирование журналов транзакций, а лишь после этого происходит передача содержимого журнала транзакций в базу данных.

Как вы можете увидеть, этот процесс очень запутанный. В действительности, обычное приложения для резервного копирования не может осуществить резервное копирование Exchange Server, до тех пор пока не будут остановлены базы данных. Приложение для резервного копирования должно быть специализированным, чтобы оно могло выполнять резервное копирование Exchange Server, если подключены базы данных. Именно благодаря такой сложности менеджер защиты данных DPM version 2 стал таким долгожданным и сможет обеспечивать непрерывную защиту данных, хранящихся на серверах Exchange, SharePoint и SQL servers.

Несмотря на свои новые возможности, менеджер защиты данных DPM version 2 имеет свои ограничения. Например, DPM не может произвести резервное копирование системного состояния сервера (server system state). Это значит, что чистое восстановление сервера с помощью DPM невозможно. Другое ограничение заключается в том, что DPM полагается на агентов, которые необходимо установить на серверах, для которых будет осуществляться резервное копирование. Это значит, что DPM может использоваться лишь на серверах, работающих под управлением операционной системы компании Microsoft. Это касается не только тех, кто работает на серверах Unix, Linux или NetWare, но и также тех, у кого данные хранятся на устройствах NAS, которые не содержат традиционной операционной системы.

Заключение

Мне хочется думать, что менеджер защиты данных Data Protection Manager version 2 установит новый стандарт в области защиты данных. Одно необходим помнить, что менеджер защиты данных DPM не является заменой традиционных средств для выполнения резервного копирования. Они по-прежнему будут необходимы для переноса данных на ленту, и таким образом, копия данных может быть удалена после выполнения резервного копирования, это повысит защиту данных в случае пожара или стихийного бедствия. Различие заключается в том, что резервное копирование на ленту (tape backup) используется для прямого резервного копирования серверов. В среде, к которой используется DPM, DPM будет осуществлять резервное копирование ваших серверов, а на ленточный носитель будет записываться резервная копия, полученная с помощью DPM.

www.windowsnetworking.com