none
Объясните по резервному копированию. RRS feed

  • Вопрос

  • Всем привет!

    Необходимо автоматизировать бэкапы базы MS SQL Server Standart 2005 в две сетевые шары, физически расположенные в разных местах (посколько Standart Edition - MIRROR TO не работает).

    Написал скрипты, сделал джобы для бэкапов по следующей схеме:

    В 1.00 полный бэкап в \\Server1\Share\DB-dd-mm-yy.bak

    В 4.00 полный бэкап в \\Server2\Share\DB-dd-mm-yy.bak;

    Начиная с 8.00 до 24.00 резервные копии журналов транзакций в \\Server2\Share\DB-dd-mm-yy.bak каждые 20 минут;

    В 12.00 дифференциальный бэкап в \\Server2\Share\DB-dd-mm-yy.bak

    В 14.00 дифференциальный бэкап в \\Server1\Share\DB-dd-mm-yy.bak

    Бэкапы журналов транзакций в \\Server1\Share не делаются (дополнительный бэкап на случай пожара\потопа\землетрясения и т.п.)

    На следующий день создается новый набор резервных копий соответственно.

    Все работает, но в книге Станека "Microsoft  SQL Server 2005. Справочник администратора" (стр. 447) наткнулся на вот такое изречение:

    "Как упоминалось выше, время завершения последнего дифференциального или полного резервного копирования означает начало неразрывной последовательности журналов транзакций...." Это заставило меня задуматься: получается что когда я в 14.00 делаю дифференциальный бэкап в \\Server1\Share последовательность резервных копий журналов транзакций на \\Server2\Share разрывается ? Или Станек и тут ерунду опять написал (в этой книге я уже натыкался на совершенно абсурдные вещи, например стр. 135, где он советует не использовать для SQL-серверов параметр ОС "Максимальная пропускная способность для сетевых приложений") ?

    В BOL вроде ничего не сказано, о том что полный или дифференциальный бэкап начинает новую неразрывную последовательность журналов транзакций. Объясните пожста что к чему в этом вопросе ?   


    Andy Mishechkin

    29 августа 2012 г. 4:57

Ответы

Все ответы

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

    По логике, не имеет никакой разницы, нарушает ли разностная копия цепочку копий журнала, поскольку копии журнала до разностной копии не нужно восстанавливать. Однако, стоит проверить на практике, можно ли скипануть разностную копию... явного указания на то, будет ли это работать, я не видел. Вы ведь включили в стратегию резервирования периодическое тестирование копий на восстановимость? ;)

    Если попробуете, пожалуйста, напишите о резельтате тут.

    29 августа 2012 г. 8:46
  • Речь вроде о дифференциальном бэкапе, так что тут COPY_ONLY не катит. Вот что в  BOL написано:  Если параметры DIFFERENTIAL и COPY_ONLY используются вместе, то параметр COPY_ONLY не учитывается и создается разностная резервная копия.

    Тут вопрос не в том что можно ли скипануть разностную копию - она делается совершенно в другой BackupSet. Просто после нее, если верить Станеку, цепочка копий журналов прерывается вообще и в принципе. Вот например:

    Цепочка1:

    00:00 - полная копия в \\Server1\Share\backup.bak

    1:00 - полная копия в \\Server2\Share\backup.bak

    2:00 - копия ЖТ в  \\Server1\Share\backup.bak

    2:30 - копия ЖТ в  \\Server1\Share\backup.bak

    3:00 - копия ЖТ в  \\Server1\Share\backup.bak

    3:30 - копия ЖТ в \\Server1\Share\backup.bak

    4:00 - разностная копия в \\Server2\Share\backup.bak - вот в ней то и весь вопрос!

    4:30 - копия ЖТ в \\Server1\Share\backup.bak - получается, что здесь уже началась новая цепочка ЖТ.

    Вот в этом случае если потребуется восстановление с \\Server1\Share, то получается что целая цепочка только до 3:30, дальше уже не целая ? Или я не прав ?

    Хотя ИМХО тут возможен обходной вариант: непосредственно перед разностной копией в \\Server2\Share сделать разностную копию в \\Server1\Share


    Andy Mishechkin

    29 августа 2012 г. 10:45
  • Цепочка копий журналов существует только одна и она никак не привязывается в кустройствам резервирования. Она привязана к журналу транзакций и к последовательности LSN в нём. В начале цепочки всегда лежит последняя полная резервная копия, куда бы Вы её не делали. Восстановление начинается имено с неё. Потом восстанавливается последняя разностная копия, вслед за которой восстанавливаются до нужного момента все сделаные после последней разностной копии копии журнала транзакций. В вашем случае (последний вариант), восстановление будет в таком порядке:

    1. Восстанавливается копия, сделанная в 1:00

    2. Восстанавливается последняя разностная копия, сделаная в 4:00

    3. Восстанавливаются все копии журнала, начиная с 4:30

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

    Полная копия в 0 часов тоже выпадает из цепочки, поскольку после неё уже были полные копии.

    29 августа 2012 г. 11:29
  • ...вдогонку.

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

    29 августа 2012 г. 11:32
  • Т.е. если в этом случае вдруг навернется Server2, то единственное что остается - восстановить полную копию в 0 c Server1?

    Журналы транзакций, которые все равно копировались на Server1 уже не имеют никакого значения ?


    Andy Mishechkin

    29 августа 2012 г. 11:59
  • Да, восстановить удатся только состояние на 0 часов.

    Вы можете делать зеркальные копии на второй сервер (не помню только, поддерживает ли такое 2005)...



    29 августа 2012 г. 12:03
  • 2005-й поддерживает. Но только Enterprise, а у меня - Standart.


    Andy Mishechkin

    29 августа 2012 г. 13:13
  • Решил тогда на всякий случай тогда делать на Server2 ежедневные резерные копии базы данных c COPY_ONLY. В случае катастрофы можно будет восстановить информацю до прошедшего дня 


    Andy Mishechkin

    29 августа 2012 г. 13:16
  • Решил тогда на всякий случай тогда делать на Server2 ежедневные резерные копии базы данных c COPY_ONLY. В случае катастрофы можно будет восстановить информацю до прошедшего дня 


    Andy Mishechkin


    Как вариант, копируйте уже готовые файлы копий с первого сервера, на второй. Мы практикуем копировани файлов резервных копий с помощью DPM в другом датацентре. Думаю, с помощью скриптов PS можно заставить NTBACKUP делать что-то подобное...
    29 августа 2012 г. 13:26