none
дифференциации бэкап SQL 2005 и transaction log shipping на другой SQL server RRS feed

  • Вопрос

  • Здравствуйте!

    Есть сервер с SQL 2005 Ent 64nit. FULL Бекапы  льются ежечасно в несжатом формате  bak на другой том (отдельный RAID массив) и сохраняются за последние 2 часа, ночью делается так же FULL BAk, который сжимается и кладется на другой пк в 2 места .

    Режим главной базы 24 часа. Гл. База 1с8 120Г и другие 30Г суммарно.

    База растет и нужно оптимизировать бекапы, решил переходить на дефы..будущий план такой:

    Ночью: 00:00) Full  бекап, потом каждые 3 часа Def и каждый час backup tran log

    При восстановлении  бекапа актуальностью 14:30, нужно

    1) развернуть full, накатить def сделанный в 12:00, потом 2 раза развернуть полные transaction log и при разворачивании последнего указать метку stopat 15, правильная же цепочка.

    Сначала будет настроена transhipping log shipping у основных баз на другой SQL сервер с периодом 5 минут сразу в сетевую папку того сервера.

    Вопрос в следующем:

    1) В SQL 2005 Ent есть функция сжимать самим SQL файлы  bak не прибегая к внешним средствам? В 2008 это реализовано...

    2) Будут ли ежечасные бекапы логов транзакций полные или выход в ежечасном создании деф бекапов ? помойку нет...так как журнал же каждые 5 минут будет помечаться, что он забекаплен и следовательно перетираться новыми транзакциями...или при работе настроенного механизма у базы transhipping log shipping свою отметку ставить? Так как планируется дефы и логи ежечасные на другом томе этого сервера сжимать и кидать на другой сервер, так как при выходе физ сервера они будут недоступны, а ночной бекап неактуален уже...требования бизнеса выросли.

    PS: понимаю что лучше кластер с СХД...но денег нет на это а ISCSI через 1Гбит сеть не вариант...приходится изголяться.

    Помогите люди добрые, как выкрутится тут.

    11 декабря 2013 г. 13:56

Ответы

Все ответы

  • Никто не может помочь по данному вопросу?
    12 декабря 2013 г. 5:49
  • Я бы делал полный бекап ночью и tlog'и раз в 5 минут(можно чаще). 
    Зачем вам второй сервер? Ресториться на нём хотите в случае проблем с основным. Для это есть прекрасный инструмент в виде database mirroring. Log shipping существенно хуже для этого подходит(у него вообще сейчас довольно ограниченная область применения, на мой взгляд).

    Но, как уже много раз говорилось, надо начинать с требований бизнеса. Какое время простоя вам разрешено?

    12 декабря 2013 г. 7:13
  • Требования бизнеса - уровень HA. Актуальность базы не позднее чем за последний 5-10 минут, а вообще mirroring самое то, но читал отзывы, что в 2005 это хромое дело и рекомендовали через tlog shipping организовывать, в 2008 уже нормально.

    Подстраховываемся от выхода из строя на уровне оборудования, сейчас бекапы большие ежечастные льются на этот пк, что не правильно и не представляется возможным их каждый час сливать на другой сервер, делаются то 16-20 минут, остается 40 минут...хотя будут успевать сливаться, скорость копирования плавающая от 70-138мб/с на нормальный пк, а сервак бекапов NAS не потянет в ночное время, в него и так будет еще куча всего сливаться.

    Нам подходит Mirroring без следящего сервера баз данных в асинхронный режиме, все равно 1с8 все не поддерживает переключение с одно на другой сервер, если не развернуть в сети native sql client..

    Вопрос как это стабильно работает на 2005?

    Так есть в  2005 sql Ent сжатие на выходе бекапов? Так бы можно было бы уже начинать жать при бекапе и сливать на другой пк, так как уменьшение размера 3-5 раз было бы.

    12 декабря 2013 г. 10:55
  • Сжатия в 2005 нет. И ещё раз: зачем вам большие бэкапы каждый час? 

    16 декабря 2013 г. 7:30
  • Жаль, я нашел статью, где идет обсуждение сжатия для 2005...только сторонними утилитами.

    Потому что деф бекапы ранее не настраивал никто, места хватало и они лежат для прям вообще экстренного восстановления, а из-за сильного роста лога транзакций 27Г за 3 часа база работает в simple режиме, в общем прежде удобно для быстрого восстановления в пару кликов, сейчас места не хватает и нужно еще делать зеркалирование.. ранее планировал tlog shipping, сейчас буду тестировать как работает mirroring...на копию с помощью механизма tlog переключался и полет был нормальный, только если один из серваков перегуржается то логи прекращаются восстанавливаться..и идет ошибка, не очень надежное решение

    16 декабря 2013 г. 8:32
  • Simple не совместим с mirroring, к слову говоря. 

    16 декабря 2013 г. 12:29