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

Множество расписаний для одного источника данных или как обойти ограничения 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 дней при еженедельном резервном копировании. Думаю, в некоторых случаях указанный способ может пригодиться.

Реклама
  1. Алексей
    18.10.2011 в 14:30

    недельный архив содержит копию данных только того дня когда делается или же всей недели?

    • 18.10.2011 в 14:54

      Совокупность реплики и точек восстановления расписания №2 из примера (недельное) дает возможность восстановить информацию только на конкретный день — на момент создания точки восстановления расписания №2. Указанные точки создаются с интервалом 1 неделя.

  2. Алексей
    18.10.2011 в 15:42

    спасибо.теперь понятно

  3. 31.10.2011 в 16:23

    Подскажите, а как обойти вот эту ошибку?
    «Please ensure that there are a minimum of two tape drives or two tape libraries for copy backups to succeed».

    Возникает при создании ПротекшнГруп.
    У меня всего одна библиотека с одним приводом…
    Как-то с этим вообще можно жить?!

    • 31.10.2011 в 16:40

      Алексей, а какое расписание вы пытаетесь настроить?

      • 31.10.2011 в 17:40

        По шагам расскажу.

        1) Пытаюсь создать Protection Group через мастера.
        2) Protection method: «Long-Term Protection using Tape»
        3) Recovery goals: «1 recovery point every 1 week for the last 4 weeks»
        И вот как раз на следующем шаге — «Select library and tape details» — получаю такое предупреждение с желтым треугольником.

        Вот я сюда выложил скриншот:

        Вообще на иностранных форумах пишут про эту проблему, но решения я не нашел.

  4. 31.10.2011 в 18:37

    Основным принципом долгосрочного резервирования на ленты является тот факт, что все такие ленты предназначаются для удаленного хранения(offsite). Из этого следует простой вывод — каждая новая точка восстановления из долгосрочного хранения на лентах требует новой ленты для своего создания. Это условие обойти невозможно. По крайней мере, мне еще неизвестен механизм обхода…

  5. 31.10.2011 в 20:10

    А зачем тогда делать библиотеки с одним драйвом?!
    MSL2024 — в моем случае….

    Получается эта библиотека вообще несовместима с ДПМ?

    • 31.10.2011 в 22:39

      Виноват. Я неверно трактовал изначальный вопрос. Поправлюсь. Вот в чем корень ваших бед — для долгосрочной защиты на ленту резервные копии всегда пишутся с дискового пула DPM(при его наличии) либо с последней краткосрочной копии на ленте. Так что выхода 2: использовать дисковый пул совместно с лентой или использовать только краткосрочную защиту на ленты.

  6. 01.11.2011 в 12:08

    «использовать дисковый пул совместно с лентой» — вот с этим вариантом также проходит эта ошибка.

    «использовать только краткосрочную защиту на ленты.» — попробую сегодня.

  7. 28.12.2011 в 12:18

    Егор, крутая тема! Спасибо за идею :) Кстати, необязательно присваивать реплике букву тома, во-первых настроек может быть много, а во-вторых пустые буквы в папке «Мой компьютер» просто смущают))). В таком случае, при настройке второго расписания путь к репликам надо искать в соответствующей типу защищаемых данных папке тут: C:\Program Files\Microsoft DPM\DPM\Volumes\Replica\.

  8. Александр
    28.03.2012 в 12:31

    А как потом восстанавливать что-то из этого долговременного архива?

    • 28.03.2012 в 13:10

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

      • Александр
        28.03.2012 в 13:16

        Неверно задал вопрос =)
        Можно ли данным способом сделать «долговременный» бэкап приложения (SQL или Exchange) и как потом это восстановить (конкретную базу или ящик)?

  9. 28.03.2012 в 15:10

    Данные приложения и так поддерживают длительное хранение на жестких дисках, т.к. не подпадают под ограничения VSS для файловых ресурсов. Так что этот способ не для них. Но, если «скучно», то вполне возможно восстановление реплики DPM из «долгосрочного» архива на файловом уровне, потом извлечение файлов базы данных (базы почтовых ящиков) вручную и монтирование их на соответствующих серверах. О восстановлении отдельного ящика не может быть и речи, т.к. этот функционал недоступен и для стандартных поддерживаемых сценариев защиты.

  10. Alexey
    10.12.2012 в 21:29

    то ли я тугой, то ли тут ошибка.
    Мне кажется что в этом случае время хранения составит 64+7 дней, т.е. 71 день.
    И никак ни 448.
    Что скажете?

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: