Доброго. вопрос в следующем. имеем sql 2008r2. какое то время назад настроил на нем автоматическое создание ежедневных бекапов средствами самого sql (до этого батник был), т.е. создал план обслуживания, в котором задал необходимые параметры. настроил рассылку почтой, в случае ошибок и если план обслуживания был не выполнен. все прекрасно работало. сегодня интереса ради залез на сервак (удаленный филиал) и с удивлением обнаружил, что последний бэкап от 1го ноября, а новых нет, хотя до этого бекапы есть, т.е. все прекрасно выполнялось. залез в журнал плана обслуживания, а там написано, что план успешно выполнен и ошибок нет за каждый день, в который должен был быть бэкап, в назначенное время по расписанию. ладно. принудительно поставил на выполнение плана обслуживания, а то мало ли. все прошло без ошибок. туплю. в чем косяк?

(0) 1. Не было места на винте
2. Руками поудаляли файлы бэкапов

если не было бы места  , задача не выполнилась бы без ошибки

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

(2) У меня такое было разок, года два назад. И ошибок, насколько помню, не писал.

(4) в чем проблема была не разобрались?

+(4) а. Вы про место на диске

(6) ага

(7) да места то хватает... с лихвой при том

(8) В задании проверить куда пишется бекап? Мож кто с шаловливыми ручками поменял?

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

О дальнейшем история умалчивает.

(9) первым делом. путь тот же
(10) циклические бэкапы точно не настраивал.
(11) вброс не засчитан. уж что что, а бэкапы дело святое.

может кто удалил???

(12) реальная история, мне админ рассказал, который после него взяли. А вот так не посмотрел бы и как назло?

Кстате - скуль энтерпрайз?

(12) админы всю жизнь делились на тех кто не и уже

(14) ну что реальная - не сомневаюсь. иначе бы не было этой крылатой фразы) дык как раз настроил оповещение, если будут какие-либо ошибки и что б по всем сервакам не лазить каждый день и проверять. а тут на тебе Юрьев день. с базой то все норм. просто сам факт насторожил.
(15) он самый
(16) известный факт) и не только сис.админы)

(17) сжатие скульное используете?

кстате, тоже давно не смотрел. Сейчас глянул, все норм :-)

(16) был у меня случай. Работал в конторке одной гос., было это в далеком году 97. И бэкапы делала начальница в обеденный перерыв, обучил ее и делала. И тут она в отпуск и на 10-й день рушится база DBF-ная, а я ни одного бекапа не делал.

Так я разобрал и починил заголовок DBF-ного файла.

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

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

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

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

Много чего за 15 лет перепробовал: и виндовый шедулер, и крон и скуль-агент. Как ни странно, уже как 2 года все запихал в регламентные задания. Удобно скрипты писать на 1С, универсальнее получается.

(22) И напрасно батенька не используете сжатие. Только по след. причинам его надо использовать, а именно:
1. Из 40 гиговой базы бэкап будет порядка 5-ти гигов.
2. Скорость бэкапа увеличивается в разы.
3. Если использовать WinRAR, то еще нужно время на запаковку/распаковку.
(21) Только не это, глючная вещь та еще.

(0) Кто-то зашел и стер.

(25)
Не понял за счет чего скорость увеличивается в разы, если ему еще и сжать нужно?

Сжатие резервных копий

По умолчанию резервное копирование с использованием сжатия резервных копий существенно увеличивает загрузку ЦП, а дополнительная загрузка ЦП процессом сжатия может неблагоприятно повлиять на параллельные операции. Поэтому может понадобиться создать низкоприоритетную сжатую резервную копию в сеансе, загрузка ЦП в котором ограничивается регулятором ресурсов в случае конфликта за ЦП. Дополнительные сведения см. в разделе Как использовать регулятор ресурсов для ограничения загрузки ЦП при сжатии резервной копии (компонент Transact-SQL).
(с) http://technet.microsoft.com/ru-ru/library/ms190954(v=sql.105).aspx

+(28) Вот-вот, лучше просто бакапить скулем, а РАР запустить на другом сервере. Он у меня так и называется - сервер бакапов. Заодно и запасной контроллер домена

(27) Вопросик на засыпку - что быстрее записать на винт 5-ть гиг, аль 40? А процессоров у нас 16-ть и 32 оперативы. Да и какая там нагрузка ночью?
(29) Ага, ага и ждать потом пока этот РАР разархивирует... вообщем я уже с развернутой базой буду, а вы смотреть прогресс бар РАРа.

+(30) точнее 24 проца, образно конечно. Столько в диспечере задач кажет.

(29) вот я просто скулем и бэкаплю... А у вас получается - не экономное использование комп. ресурсов и времени.

(30) Согласен. Сжатие - вещь.
По факту тоже получается, что сжатый архив быстрее создается.

(33) был удивлен этим фактом, когда обнаружил, что гораздо быстрее создается пожатый архив.

(30) А скуль конечно разжимать эти данные не будет?

(0) я в таких случаях (виндовый планировщик) ставлю время запуска на +минута от текущей и жду чуда.
В зависимости от наступления оного делаются варианта танца с бубном (исправление косяков что увидел).

в логе скл (не лог плана) есть запись что бэкап прошел? Если есть, значит кто то тупо удалил файлы

(35) а что разжимать дольше чем сжимать?

(30) Сколько по времени 60гиговый бэкап пакуется?

Эх, у нас SQL 2008 Standart, сжатия нет.
400 гб сжимать рар-ом - то еще удовольствие :(

Плюс стандарт едишн sql сервер не поддерживает бэкап со сжатием, а это значит надо на энтерпрайз раскошеливаться

(40) есть сжатие в стандарте 2008р2sql

2012 стандарт поддерживает сжатие. Что-то мне кажется, что 2008 R2 стандарт тоже, но зуб не дам - надо смотреть

(43) 2012 standard ed. вроде есть. 2008 standard ed. - нет.

у нас не R2 :(

(43) Да R2 поддерживает.

(34) тогда нужно поставить в винде сжатие папки чтобы всё летало?

(47) В скуле еще есть маза таблицы сжимать, но не особо рекомендуют если к таблице большое кол-во обращений.