Archive

Archive for the ‘How it works’ Category

Множество расписаний для одного источника данных или как обойти ограничения VSS

Постоянно встречаю у администраторов DPM интерес к назначению множества расписаний для резервного копирования данных, например, файлового хранилища. И стандартный ответ тут звучит примерно так: «Используя один сервер DPM этого сделать нельзя. Невозможно включить один источник в разные группы защиты, а для одной группы не существует технической возможности задать более одного расписания.»

Так же обстоит дело с вопросом в духе «Как бы мне хранить ежедневные копии файлового хранилища больше 64х дней без ленты? Firestreamer не предлагать/нет денег.» С одним сервером DPM ответ — никак — был обеспечен.

Причина всех этих «бед» в ограничениях VSS, который лежит в основе всего резервного копирования DPM. Ограничения эти не обходятся и не подкручиваются. Приходится приспосабливаться. Но…

Как всегда, поиск нестандартных ходов и возможностей на основе внутренних механизмов работы DPM привел меня к возможности обойти эти ограничения, используя резервное копирование самих резервных копий. Ничего так каламбур? :) И все это на одном единственном сервере DPM.

Как мы можем это делать. Для начала, тем, кто этого еще не сделал, нужно прочитать вводную Пользовательские тома в DPM. Этот способ размещения томов реплик на сервере DPM позволяет нам защитить уже готовую зеркальную копию данных защищаемого компьютера как локальный том DPM. Получается следующий алгоритм:

1. Заготавливаем пользовательские тома — по 2 на каждое расписание:

custom volumes

2. Создаем Группу защиты 1 для источника данных — файловые ресурсы защищаемого сервера.

3. Указываем пользовательские тома DPM replica 1 для хранения реплики и DPM rp 1 для точек восстановления.

4. Назначаем расписание — ежедневное создание точек восстановления, хранить 7 дней.

5. Создаем Группу защиты 2 для источника данных — папка сервера DPM на томе реплики DPM replica 1 (в случае демонстрации тому назначена буква E), содержащая копию данных с сервера из п.1:

6. Назначаем этой группе пользовательские тома с номерами 2:

7. Назначаем расписание — еженедельные точки восстановления, хранить 64 дня (получаем 448 календарных дней хранения).

8. Все, защита и для частого копирования и для длительного хранения готова.

Итак, мы можем создать 2 и более расписания на единственном сервере DPM для резервного копирования папки на защищенном компьютере. Можем хранить резервные копии с ежедневным созданием точек восстановления 64 дня и ту же самую информацию хранить 448 дней при еженедельном резервном копировании. Думаю, в некоторых случаях указанный способ может пригодиться.

Пользовательские тома в DPM

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

Тег «Далее»

Диапазон хранения в DPM

Продолжаем детально рассматривать терминологию и понятия DPM. Сегодня в центре внимания — Диапазон хранения.

При создании группы защиты администратор указывает Диапазон хранения —  продолжительность времени, в течение которого данные должны быть доступны для восстановления. Определение это общепринятое для средств резервного копирования. В контексте DPM, под диапазоном хранения можно понимать время, в течение которого сервер DPM хранит точки восстановления. Существенный момент для DPM один — дни, в которые реплика не была согласована, не учитываются при при определении диапазона хранения.

Каждую ночь в 12 часов сервер DPM 2010 выполняет скрипт PruneShadowCopiesDpm2010.ps1 (для сервера DPM 2007 — PruneShadowCopies.ps1), который вы можете обнаружить в папке %ProgramFiles%\Microsoft DPM\DPM\bin. Данный скрипт анализирует диапазон хранения для каждой группы защиты и удаляет самые старые точки восстановления, в случае, когда они не вписываются в заданные временные рамки. При возникновении любых проблем с синхронизацией реплики в течение дня или отсутствии в расписании дня создания точки восстановления, этот день не учитывается при определении диапазона хранения скриптом очистки. При создании множественных точек восстановления в течение дня в диапазоне хранения такой день является равноценным дню с одной точкой.

Таким образом, в контексте DPM диапазон хранения, допустим, в 5 дней, означает примерно следующее — на сервере DPM должны существовать точки восстановления за, как минимум, 5 дней. Ежедневное создание точек дает нам самую старую точку восстановления на момент 5 дней назад. При создании точек восстановления каждое воскресенье, самая старая точка, при том же пятидневном диапазоне хранения, будет храниться на сервере 5 недель, или 35 дней. Если сервер был выключен в одно воскресенье, самая старая точка будет храниться 6 недель, пока не наберется положенные 5 точек.

Отдельно отмечу — ежедневное выполнение скрипта PruneShadowCopiesDpm2010.ps1 не отображается среди прочих запланированных заданий на вкладке Наблюдение.

Существующие ограничения диапазонов хранения таковы: от 1 до 64 дней для краткосрочной защиты на диске, до 12 недель для краткосрочной защиты на ленте и до 99 лет для долгосрочного хранения на ленте. Обратите внимание, что 64 дня диапазона хранения на дисках, при действующем минимальном ограничении — 1 точка восстановления в неделю, дает 448 календарных дней хранения.

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

Рубрики:DPM 2007, DPM 2010, How it works Метки: , ,

Что такое «точка восстановления DPM»

Данный вопрос, судя по статистике поисковых систем, волнует многих специалистов, работающих с архивацией данных. Попробую кратко ответить на него.

В русскоязычной справке DPM дано следующее определение:

Точка восстановления, называемая также моментальным снимком, является копией на определенный момент времени реплики, хранящейся на сервере Data Protection Manager (DPM).

Вынужден не согласиться с таким объяснением. Из данной трактовки можно сделать ошибочный вывод о том, что DPM хранит множество копий реплики, и каждая из них создается в момент создания точки восстановления. Т.е. однозначно верно определить для себя — что же это такое из справки нельзя. Попробую дать свое определение:

Точка восстановления — это изменения реплики на уровне блоков, произошедшие с момента создания последней точки восстановления и хранящиеся в виде файла на томе точек восстановления.

Из этого определения следует однозначный правильный вывод о том, что точка восстановления является поблочной разницей реплики на момент создания прошлой и текущей точек восстановления. Физически она представляет собой файл, хранящийся на томе точек восстановления в папке System Volume Information. И по сути это просто «склеенные куски файлов», которые изменились с момента создания прошлой точки восстановления. Вот так все просто, если копнуть чуть глубже.

Рубрики:How it works Метки: , ,

DPM, EFS и пруфлинк

В среде суровых админов невысоко ценятся голословные утверждения о тонкостях работы каких-либо программных или аппаратных продуктов, и даже мнение MVP не может заменить главный аргумент — пруфлинк (англ. proof link — подтверждающая ссылка).

Несколько дней назад появилась возможность представить вашему вниманию пруфлинк на мою заметку DPM 2010: Особенность защиты зашифрованных и сжатых файлов. Это свежеизданная статья Базы Знаний Microsoft KB2476276. Несмотря на пометку «FAST PUBLISH» article, что буквально можно перевести как «написано на скорую руку», статья коротко и ясно объясняет тот факт, что при любом изменении зашифрованного файла, в процессе синхронизации DPM передает его целиком:

— If a file has not changed since the last sync, DPM will not transfer any data.
— If a file has changed and is not encrypted with EFS, DPM transfers only the changed blocks of a file.
— If a file has changed and the file is protected with EFS, DPM will transfer the entire file.
The behavior above is by design…

Ну а что касается аналогичного поведения DPM со сжатыми NTFS файлами — тут вам придется поверить мне на слово =)

Рубрики:How it works Метки: ,