none
sql backup на сетевую папку RRS feed

  • Вопрос

  • Главная задача: обеспечить регулярное архивирование логов и полной базы и локально и на резервный сервер с расшареной папкой. 

    Удалось: 1) создать батник делающий зеркальную копию папки с архивом на локальные диски и сетевые папки

    2) удалось подключить батник к плану обслуживания, но только с зеркалированием на локальные диски (на сетевые папки задание завершается ошибкой времени ожидания)

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

    3) Были попытки сделать второе задание в плане обслуживания с бэкапом сразу на сетевую папку, но подключенного сетевого диска не видит

    4) был прочитан мануал

    http://msdn.microsoft.com/ru-ru/library/ms179313.aspx#NetworkShare

    из которого ничего внятного не вынес 

    5) запускали службы агента и самого сервера SQL под разными учетками системными, "сетвая служба", Администратор и прочими..
    SQL установлен со смешанной авторизацией: пользователи sa, Администратор

    Для справки: домен присутствует, SQL стоит как раз на контроллере домена с ролью PDC и остальными ролями FSMO.


    Подскажите пожалуйста, что не так делаем?

    5 сентября 2014 г. 15:10

Ответы

  • Про самостоятельную сетевую папку тоже не принципиально, тут главное чтобы права были правильно настроены.

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

    При размере базы в 10 гиг я бы вообще не переживала, пять минут бекапа сервер переживет в любом виде. Когда размеры баз по 500 гиг тогда архивирование спасает.

    8 сентября 2014 г. 11:02
  • Честно говоря, заниматься архивированием при наличии встроенных средств сжатия резервных копий(начиная с версии SQL Server 2008) не имеет большого смысла. Степень компрессии у рара повыше будет, но это в пределах 5-10 процентов, по моему опыту. При этом нетехнологичность восстановления убивает все достоинства, а при острой нехватке места может вообще сделать его невозможным. 
    Я с большим удовольствием убил в своё время все скрипты, которые этим занимались. :)

    Вдобавок ко всему, резервное копирование и восстановление со сжатием происходят значительно быстрее. В данном случае размен IOPS на CPU практически всегда оправдан. 


    8 сентября 2014 г. 15:26
  • В сжатии бекапов, по моему опыту, минусов нет никаких. В сжатии данных средствами mssql сложности есть - надо всё крайне внимательно тестировать.

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

    8 сентября 2014 г. 17:39

Все ответы

  • Проверьте права на сетевой папкe (на шаре полный доступ и на ntfs полный доступ) для той учетной записи под которой запущен SQL Server agent, если это local system - выдайте права компьютеру

    Если указываете параметр "create a backup file for every database" то просто пишете путь к папке в формате \\server\share\

    Если "back up databases across one or more files" - указываете конечный путь к файлу \\server\share\base.bak или бекап девайс

    Еще можно архивировать большие бекапы баз, экономится место и в результате можно хранить архивы за больший период времени. Для примера задание в task scheduler по архивации сразу на сервер используя winrar

    Rar.exe a -r -agDD-MM-YYYY "\\server\куда архивировать" "с:\откуда\"

    5 сентября 2014 г. 17:34
  • Спасибо за подсказку "просто пишете путь к папке ", а я в задании SQL пытался найти сетевую папку в обзоре...
    спасибо "Проверьте права на сетевой папкe", еще раз проверил. И все-таки было не правильно сделано, целевая папка уже лежала в другой сетевой папке и самостоятельной сетевой папкой не была, вот и весь нюанс.

    Заработал и бэкап в сеть и батник "зеркалирования" файлов в сеть, запускаемый из SQL.

    Правда ли, если бы не было домена, то такие вещи не доступны?

    С батником кажется целесообразнее, зачем лишний раз нагружать и весь главный сервер, и массив с базами.... (особенно актуально про полный бэкап базы 10 Гб)
    А так пусть только жесткий диск с бэкапами в это время поработает....
    Как вы считаете?
    Места на дисках не сказать чтобы совсем много, но и базы не очень большие, главное, правильную очистку организовать (всего по семь копий одновременно: 2 суток, 10 дней, месяц, квартал, а годы складываются все) но архивацию наверно в сторону )). Очень драгоценное оперативное время восстановления сократится (нужно сначала из РАРа поднять). А так SQL 2012 прекрасно сам находит все бэки логов, сам выстраивает в последовательность, остается только кнопку нажать ))) 

    7 сентября 2014 г. 8:50
  • Про самостоятельную сетевую папку тоже не принципиально, тут главное чтобы права были правильно настроены.

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

    При размере базы в 10 гиг я бы вообще не переживала, пять минут бекапа сервер переживет в любом виде. Когда размеры баз по 500 гиг тогда архивирование спасает.

    8 сентября 2014 г. 11:02
  • Честно говоря, заниматься архивированием при наличии встроенных средств сжатия резервных копий(начиная с версии SQL Server 2008) не имеет большого смысла. Степень компрессии у рара повыше будет, но это в пределах 5-10 процентов, по моему опыту. При этом нетехнологичность восстановления убивает все достоинства, а при острой нехватке места может вообще сделать его невозможным. 
    Я с большим удовольствием убил в своё время все скрипты, которые этим занимались. :)

    Вдобавок ко всему, резервное копирование и восстановление со сжатием происходят значительно быстрее. В данном случае размен IOPS на CPU практически всегда оправдан. 


    8 сентября 2014 г. 15:26
  • У меня архивируются старые бекапы 2000-го sql, по-моему он не умеет жать. На 2008 проверила в 2 раза меньше архив rar, но вы правы оно того не стоит.

    А никаких минусов нет в сжатии, по-опыту? Можно смело менять default server setting на сжатие или оставить как есть если место позволяет?

    8 сентября 2014 г. 16:51
  • В сжатии бекапов, по моему опыту, минусов нет никаких. В сжатии данных средствами mssql сложности есть - надо всё крайне внимательно тестировать.

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

    8 сентября 2014 г. 17:39