none
практический опыт отказа от бэкапа баз при DAG 3+ копиях RRS feed

  • Общие обсуждения

  • Коллеги, есть среди нас те, кто на 10-ке не использует бэкап при наличии кол-ва копий больше 2-х?

    Подделитесь опытом, пож-та!

    Есть желание дать пользователям большие ящики - соответственно, адекватность времени бэкапа - а сособенно восстановления из бэкапа - уменьшается с увеличением роста баз...

    • Изменен тип Yuriy Lenchenkov 29 апреля 2011 г. 10:36 обсуждение замены резервного копирования использованием DAG
    15 апреля 2011 г. 13:51

Все ответы

  • Отказоустойчивость и резервное копирование - это две разные вещи, которые друг друга НЕ заменяют by design!

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

    А вообще все зависит от того, что от вас в этом плане требует бизнес.

    PS Если пользоваться нормальными средствами бэкапирования и выделить отдельную физическую сеть для бэкапа, то проблему с временем можно решить.

    PPS В случае с 3+ копиями баз данных вы попросту тратите место на стораджах! Опять же если говорить о нормальных средствах резервного копирования, то они давно научились архивы сжимать, дедуплицировать и т.п..


    http://alexxhost.ru
    15 апреля 2011 г. 14:44
  • Редкий случай, когда я категорически не согласен с Алексеем: все сказанное верно для Exchange 2003 и даже для Exchange 2007, но совершенно неверно для Exchange 2010.

    Чтобы не перегружать форум просто даю ссылку на официальную позицию команды разработчиков Exchange:

    http://blogs.technet.com/b/exchange_ru/archive/2011/02/03/robert_2700_s-rules-of-exchange_3a00_-storage-planning-and-testing.aspx

    Нам нужен раздел: Хранилище Exchange или сторонние системы архивации


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    17 апреля 2011 г. 17:52
    Модератор
  • Нашей фиктивной компании не нужны сторонние системы архивации: в нашем решении мы будем использовать большие почтовые ящики на простом недорогом хранилище.

    Да, бесспорно, мы можем теперь пользоваться более дешевыми хранилищами и предоставить пользователю ящик в 10-20 Гб. Но что делать, если пользователь удалил письмо, а вспомнил про это через неделю/месяц?

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


    http://alexxhost.ru
    18 апреля 2011 г. 2:58
  • Тогда дополню вопрос - хочется узнать, кто как пользуется новыми преимуществами и видит для себя варианты реализации - и м.б. на практике использует уже (а мужики-то не знают!)

    Я, например, вижу для себя такую реализацию плана резервного копирования в системе E2010 с кол-вом ящиком от нескольких тысяч и общим размером баз, большим 10-20 ТБ (т.е. таким размером, при котором есть повод крепко задуматься о времени бэкапа и восстановления)

    - вместо оперативного бэкапа использовать Single Item Recovery - соотв-но заложить запас скажем на 30-60 дней по стораджу для этого.

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

    18 апреля 2011 г. 5:27
  • Да, бесспорно, мы можем теперь пользоваться более дешевыми хранилищами и предоставить пользователю ящик в 10-20 Гб. Но что делать, если пользователь удалил письмо, а вспомнил про это через неделю/месяц?

    Весь вопрос в том, должны ли мы иметь возможность его восстановить (например в нашей организации мы должны восстановить любое сообщение в течении полу года)?


    Алексей, я опять с вами категорически :-) - никто и нмчто не мешает использовать Exchange 2010 точно так же как Exchange 2007 и даже как Exchange 2003 - точно так же спроектировать, точно так же реализовать и точно так же применять системы резервного копирования и восстановления. Но прелесть Exchange 2010 в том, что он позволяет сделать все то же самое, но другими средствами и намного проще, надежнее и дешевле - и это тем более ощутимо, чем больше масштабы.

    Что касается восстановления любого сообщения, то по моей ссылке есть ответ и на это.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    18 апреля 2011 г. 16:22
    Модератор
  • Тогда дополню вопрос - хочется узнать, кто как пользуется новыми преимуществами и видит для себя варианты реализации - и м.б. на практике использует уже (а мужики-то не знают!)


    Еще раз читаем статью по ссылке приведенной выше.

    Я, например, вижу для себя такую реализацию плана резервного копирования в системе E2010 с кол-вом ящиком от нескольких тысяч и общим размером баз, большим 10-20 ТБ (т.е. таким размером, при котором есть повод крепко задуматься о времени бэкапа и восстановления)

    если у вас такие масштабы, то используем калькулятор http://blogs.technet.com/b/exchange/archive/2009/11/09/3408737.aspx и бежим к начальству показывать СКОЛЬКО вам съэкономит Exchange 2010 при использовании DAG

    - вместо оперативного бэкапа использовать Single Item Recovery - соотв-но заложить запас скажем на 30-60 дней по стораджу для этого.если у вас

    Single Item Recovery не предназначено для этого сценария, но ... Но все же не надо: если у вас будет система журналирования, то она решит эту задачу.

    - журналирование и третьесторонняя система для хранения в сжатом виде этого журналированного архива с системой поиска в нём, для как раз случаев, если надо вытащить письмо за год-два и т.п. - хранить для этого оперативный бэкап баз - мне кажеться, смысла нет
    все верно
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    18 апреля 2011 г. 16:31
    Модератор
  • >Алексей, я опять с вами категорически :-)

    Илья, я наверно просто слегка консервативен в этом вопросе ;)


    http://alexxhost.ru
    18 апреля 2011 г. 16:36
  • Илья, почему не подходит SIR в качестве оперативного бэкапа в той части, что этот оперативный бэкап служит как для восстановления удаленных\повреждённых элементов,  - то что мы меняем на SIR - так и для экстренного восстановления повреждённой базы данных целиком (то, что мы хотим заменить избыточным кол-вом копий и механизмами контроля в бэкграунде контрольных сумм страниц базы и даже асинхронной репликации, в случае повреждения страницы в активной копии - чтобы не переходить на пассивную копию и не "сидить" базу)?

    зы вспомнил про PF - они у нас к сожалению особняком немножко, но сичтаем, что они могут быть "зарезервированы" наличием реплик? SIR-ом обделены PF, так что для полной гарантии - придётся бэкапить :(


    18 апреля 2011 г. 18:22
  • Есть два контекста: 1. Массовое восстановление 2. Восстановление одиночное

    Если говорить о массовом всстановлении, то Single Item Recovery для этого не предназначен, о чем мы говорили ранее.

    Если речь идет о восстановлении одиночного сообщения удаленного относительно давно, то Single Item Recovery тоже для этого не предназначен. Об этом то же есть выше: рекомедуется использовать системы управления записями.

    Если нужно восстановить относительно недавно удаленное сообщение, то следует испоьзовать Single Item Recovery.

    Шаги по восстановлению тут:

    http://blogs.technet.com/b/exchange/archive/2010/04/26/3409870.aspx

    http://technet.microsoft.com/en-us/library/ff660637.aspx

    Теория тут http://blogs.technet.com/b/exchange/archive/2009/09/25/3408389.aspx Цитата:

    Ultimately, if the storage subsystem is planned and designed appropriately and mailbox resiliency features are leveraged, traditional point-in-time backups can be relegated to a disaster recovery mechanism, if they are even needed at all.

    Дополнительно http://technet.microsoft.com/en-us/library/ee364755.aspx


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    24 апреля 2011 г. 8:47
    Модератор
  • Илья, спасибо за ссылки, ещё раз точки над i расставили.

    Но больше никто не высказался, что немного настораживает :)

    Ещё раз вернусь к фразе Алексея

    > Отказоустойчивость и резервное копирование - это две разные вещи, которые друг друга НЕ заменяют

    получается, что в случае e2010SP1 - эти механизмы тесно связаны и отказоустойчивость в виде избыточного кол-ва копий и новые фишки e2010 (такие как проверка в бэкграунде контрольных сумм элементов базы) призвана сделать ненужным резервное копирование баз на случай логических или физических проблем, когда единственным способом восстановить базу - является её восстановление из резервной копии целиком. в данном контексте я исключаю из понятия резервного копирования - те случаи, которые касаются возможности в неизменном виде предоставить почтовые элементы (письма) по требованию политик компании

    25 апреля 2011 г. 7:31
  • Илья, спасибо за ссылки, ещё раз точки над i расставили.

    Но больше никто не высказался, что немного настораживает :)

    Я ссылался на best practice от команды разрабочиков Exchange - с ними опасно спорить :-) Во всяком случае я бы не рискнул...

    > Отказоустойчивость и резервное копирование - это две разные вещи, которые друг друга НЕ заменяют

    получается, что в случае e2010SP1 - эти механизмы тесно связаны и отказоустойчивость в виде избыточного кол-ва копий и новые фишки e2010 (такие как проверка в бэкграунде контрольных сумм элементов базы) призвана сделать ненужным резервное копирование баз на случай логических или физических проблем, когда единственным способом восстановить базу - является её восстановление из резервной копии целиком. в данном контексте я исключаю из понятия резервного копирования - те случаи, которые касаются возможности в неизменном виде предоставить почтовые элементы (письма) по требованию политик компании

    Это вообще разные понятия :-)


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    26 апреля 2011 г. 8:36
    Модератор
  • Я ссылался на best practice от команды разрабочиков Exchange - с ними опасно спорить :-) Во всяком случае я бы не рискнул...

    Я к сожалению столкнулся с теми, кто спорит :)

    > Отказоустойчивость и резервное копирование - это две разные вещи, которые друг друга НЕ заменяют

    Это вообще разные понятия :-)

    Понятия разные, но избыточность одного позволяет не использовать другое
    26 апреля 2011 г. 9:06
  • наткнулся тут на агрессию

    http://markarnold.blogspot.com/search/label/Exchange%202010

    факт разномнений имеет место, хотя это скорее в рамках уже хранилища а не прямого вопроса в теме

    • Изменено k0lin 28 апреля 2011 г. 10:57
    27 апреля 2011 г. 19:03
  • Я возможно не очень вникнул в суть статьи по вашей ссылке, но она напоминает разновидность холиварных войн, а не агрессию :-) Уровень соседних статей аналогичный: абициозные заявления есть, а доказательств нет - одни слова и ссылки. Может автор опытный специалист со своей точкой зрения, а может пустослов - я его не знаю и рабираться не вижу для себя смысла.

    Что касается споров вообще, то они нужны: я думаю, вы не сомневаетесь, что на смену DAG и SIR придут другие технологие рожденные из их опыта эксплуатации.

    Если хотите факты и аргументы подкрепленные цифрами, то возьмите Exchange 2010 Mailbox Server Role Requirements Calculator - он поможет проанализировать все особенности того, как ваши требования влияют на решение и его стоимость.

    Если хотите понять работу опытного архитектора, то почитайте цикл статей Robert's Rules в блоге разработчиков Exchange (часть переведена мной для русского блога) - он каждый шаг сопровождает рассуждениями и расчетами - вот это просто бесценно: вы можете свою ситуацию тращательно и объективно проанализировать, переосмыслить и принять оптимальное для вас решение.

     


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    28 апреля 2011 г. 9:21
    Модератор
  • Подниму тему, может у кого ещё какие мысли - и вдруг практический опыт.

    А так, собстно, всё написано - "думайте сами, решайте сами" (с) http://technet.microsoft.com/en-us/library/dd876874.aspx#FleMaiPro

    16 июня 2011 г. 13:49