Бэкап SQL , что за фигня?

BACKUP DATABASE успешно обработал 295551 страниц за 19.423 секунд (118.878 MБ/сек)

я правильно понял это сообщение, что полный бекап у вас делается за 19 секунд, а размер бекапа примерно 2.3 гига?

если это так, то зачем вам острые ощущения с инкрементальными бекапами?..

делайте полные бекапы и жмите их архиватором, если места впритык.

Да, бэкап делается быстро.

Места тоже в принципе хватает, хотя его много не бывает. Но, бэкап быстро разрастается, когда он каждый день полный. Когда его создаешь с нуля, то он вообще 1,3 гб, но уже через несколько дней 4,5. К тому же у меня бэкапы каждый день сливаются в облако, чтобы я его мог иметь всегда на локальной, моей машине (это база 1С). И есть разница качать 1,3 Гб или 5.

Но, это ж непорядок, что так работает? Есть же какая-то причина.

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

Ну а причину-то такого поведения как найти? Никто не сталкивался?

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

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

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

разрастается база - посмотрите как у вас настроен shrink(можно его делать перед бекапом) и какой режим логов транзакций(в большинстве случаев достаточно выбрать simple mode и логи сами будут подчищаться). база и бекапы уменьшатся.

"И есть разница качать 1,3 Гб или 5." - запакуйте бекап, сжатие будет раз в 7 или больше, т.е. 5G / 7 = 714Mb

Понял.

Дык так же может полететь и полный.

А где это смотреть? Это то?

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

У меня поставлено сжатие средствами СКЛа. Это не то? Жать просто в зип? База от этого не полетит?

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

в свойствах базы, https://stackoverflow.com/questions/480897/how-can-i-manage-sql-server-log-size

у меня уже не осталось MSSQL серверов, так что негде посмотреть. называется "Simple Recovery Model"

про "сжатие средствами СКЛа" ничего не скажу, я бекапил без сжатия, чтобы бекап проходил быстрее и меньше напрягать MSSQL сервер, затем по крону запускал батничек, который 7zip-ом паковал бекапы в зип, одна база - один архив (попутно ставил и пароль на архивы). бекап - это обычный файл(ы), при упаковке/распаковке с ним ничего не случиться.

А вы измените

BACKUP DATABASE [ЙЙЙЙ] TO DISK = N'D:\MSSQL\Backup\ЙЙЙ' WITH RETAINDAYS = 14, NOFORMAT, INIT

Тем самым Ваш файл с бэкапом будет перезаписываться.

Лично я усечение (shrink) базы не практикую, зачем мне лишняя фрагментация... Глядишь нагрузка на диски снизится...

Кроме того, если и регулярно бэкапить логи транзакци, то файл логов при Вашем размере базы сильно не разрастется. И переживать об этом не стоит.

Ставить режим simple для базы 1с, не самая лучшая идея, мало ли кто то сильно накосячит (особенно в конфигураторе) и нужно будет откатить базу на некоторое время назад (например 15 минут), а в режиме simple это не возможно (толь восстановление на момент создание полного бэкапа).

вы сможете за 15 минут обнаружить косяк, убедиться, что это действительно косяк и никак кроме отката назад его не исправить и откатится назад? тогда снимаю шляпу :)

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

если нужно внести потенциально опасные изменения("в конфигураторе" или еще как-то), то желательно клацнуть пару кнопок и сделать полный бекап, по времени у ТС это занимает 20 секунд и дальше крутите, что хотите. :)

А причем тут "кто то", тут самих 1Сков хватает.

Не могу назвать дату, но года 2 назад 1Сники выпустили обновление ЗУП 2,5 ( и при определенных условиях, а именно наличия каких-то проводок) обновление конфигурации приводило к полной не работоспособности конфигурации.

Был случай, 1С зависла на ровном месте, в момент обновления.

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

Если сможете вылечить причину (кудрявые руки разработчиков 1С), то с меня ящик пива.

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

При модели simple - восстановление только с того момента как создана.

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

И самое главное в полной модели есть возможность доставки журналов если вы понимаете о чем я.

Спасательный круг на случай если сервер БД решит прилечь и откажется просыпаться.

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

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

Кроме того, со временем база разрастется и к этому вопросу придется вернуться.