Приветствую вас, товарищи и господа!

Подскажите по настройке разностного бекапа MSSQL.

У нас схема такая:
1. Полный бекап раз в неделю
2. Разностный бекап два раза в сутки
3. Бекап логов каждые 15 мин

Каждый тип бекапа делается в свой девайс (bdfull.bak, bddiff.bak, bdlog.bak). Я так понимаю, что при полном бекапе должны очищаться бекапы разностный и лога. И, соответственно, при создании разностного бекапа должен очищаться бекап логов.

Правильно или нет?

http://pics.rsh.ru/img/000_johy57zn.png

А бекапы (это файлы?) с чего должны очищаться? Очищается (помечается не используемым) место в файлых БД...

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

вроде можно поиграться с бэкапсет https://docs.microsoft.com/ru-ru/sql/relational-databases/system-tables/backupset-transact-sql?view=sql-server-ver15

обычно используют либо бэкап логов либо разностный.

(1) (2) смотрите. Допустим, сделали фуллбекап - 10Гб, диффбекап  0Гб. проходит день, дифф вырос до 1 ГБ (условно), через день - до 2Гб, через неделю до 7Гб. В этот момент делается фуллбекап, дифф при этом должен быть опять 0Гб

(4) такая схема как у нас тоже имеет права на жизнь

(0) "при создании разностного бекапа должен очищаться бекап логов." - нет. Это разные виды бэкапов.
У нас делается и full, и diff и бэкап логов.

(7) файлы бекапов имеют дату/время в названии или в пути сохранения?

Отчет Сводная ведомость расчетов и Ведомость расчетов с клиентами Формируется неправильно. В колонке Долг клиента\поставщика показывает долг , хотя у клиента отсрочка от 14-30 дней. То есть Реализация проведена 26.11.2020, К оплате 26.12.2020(100%).И при Реализации не дает провести ее( Имеется просроченная задолженность на сумму 7232 руб, с прошлой реализации в которой оплата по сроку тоже дается 20 дней) Может кто сталкивался с этим.

(9) ничоси. деоа...

(5) Если новый диф-бэкап ты делаешь относительно нового фулбэкапа, то в него и запишет только измененные со времени базового фуллбэкапа экстенты. Мы просто диф-бэкапов не делаем, поэтому на практике не подскажу как происходит процесс выбора опорного фулбэкапа. Но это ключевой момент. Какой опорный будет использоваться - такого размера диф и получишь (чем новее, тем меньше размер).
А бэкапы логов особняком стоят. Им на все плевать. Они вещь в себе. Бэкапятся себе и бэкапятся. Они ж не накопительные, а просто последовательные пачки транзакций. Из них можно налить недостающих данных до нужного момента.

(11) чтобы поднять базу из бекапа на определенный момент, нужен фулбекап и все разностные бекапы (диффы и логи) от момента фулла до необходимой точки во времени.
Вчера нарвались на то, что программист взял фулл бекап, дифф, лог и не смог загрузить потому что лог был сделан до фулла. SQL сказал что log.bak is incorrectly formated and can not be read.
Ясен пень что он незагрузится вместе с более свежим фуллом.
Собственно, к этом и тему поднял. Нужно ли очищать разностные бекапы, когда делаешь фулл бекап

(12) Не очень понял, чего вы ожидали пытаясь загрузить бэкапы логов, сделанные до фулл-бэкапа. Они же уже вошли в фулл-бэкап. Ничего очищать не нужно. Все дифы тоже не нужны. Только последний.
Поднимаешь фуллбэкап и на него - последний диф, сделанный на его основе. А вот дальше нужны ВСЕ бэкапы логов, которые "цепляют" момент создания последнего дифа до того времени, куда нужно восстановиться. Без пропусков. Формулировка "очистка разностного бэкапа" мне по-прежнему неясна. Ничего "очищать" не нужно. Нужно просто иметь все нужные бэкапы.

(12) Еще раз: основной бэкап и бэкап лога - это разные вещи. В бэкапе лога никакие точки основного бэкапа не отмечаются.

(12) Но вообще ошибку стремную выдало. Что-то вы там намутили не того. Ошибка говорит о том, что сиквел вообще не понимает, чего вы ему суете.

Короче проще всего - возьми каркасную конфигурацию и прогони на ней типовые сценарии резервирования/восстановления, пока не отпадут все вопросы.

(13) я же написал, что логи пишутся в один файл. логи до фулла и диффа не нужны, значит файл нужно очищать

(17) > логи пишутся в один файл
Это бред. Логи в один файл не пишутся. У тебя есть расписание создания бэкапов логов. Каждый раз должен создаваться новый файл. Потому что бэкапы логов - они не разностные. И для восстановления нужна вся цепочка за нужный период.

(18) :) никто не запрещает писать логи в один файл

Смотри как оно работает - при включении полной модели восстановления зафиксированные транзакции перестают удаляться из журнала.
И тут оп - делается бэкап транзакций. Из журнала просто выгребаются все зафиксированные транзакции и скидываются в файл бэкапа.
И так - каждый очередной бэкап. А чтобы восстановиться - тебе нужные ВСЕ транзакции с момента бэкапа БД (неважно - фулл или фулл+дифф).
Если ты каждые 15 минут переписываешь файл бэкапа логов, то там остаются только транзакции за последние 15 минут.

http://pics.rsh.ru/img/001_vmliq7nc.png

(20) есть же опция "Append existing"

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

(23) зачем плодить кучу файлов?

(24) Потому что это удобно?

(25) куча файлов удобнее одного? о_О

(26) Конечно. Для логов это повсеместно. Максимальная гибкость. Ротацию очень удобно делать (удалять устаревшие периоды). Все очень понятно и наглядно.
Подозреваю, что твоя беда с восстановлением связана как раз с этим накопительным файлом. Подозреваю, что оно имеет особый формат, который не понимается в том инструменте, который ты используешь для восстановления.

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

(27) >>Подозреваю, что оно имеет особый формат, который не понимается в том инструменте, который ты используешь для восстановления.

ты это... выдыхай, чтоли :)

(29) > SQL сказал что log.bak is incorrectly formated and can not be read
Это не потому что "лог был сделан до фулла". Это потому, что сиквел вообще не смог этот файл "прожевать".

After SQL Server detects a filemark error on a device, SQL Server does not write additional information to the device.
https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/database-backup-error-3266-3013
логи у вас делаеются, ага, щаз)

(31) Причем тут это? У меня совсем не эта ошибка выходит. Да и понятно почему выходит

(30) Вот, ты уверен?

(32) в (12) не та ошибка? https://www.google.com/search?q=bak+is+incorrectly+formated+and+can+not+be+read

(34) http://pics.rsh.ru/img/image_2020_11_30T08_16_19_097Z_twjhkhql.png

(33) "Файл неправильно сформирован и не может быть прочитан". "Не может быть ПРОЧИТАН", Карл!

(36) он немецкий в школе учил)

ок. Какая ошибка должна была выйти?

(38) Если каких-то транзакций не хватает, то оно прямым текстом об этом и сообщает. Кажись что-то там про LSN тра-ля-ля.

(0)
>>2. Разностный бекап два раза в сутки

зачем 2 раза то ? И одного хватит

(0) ну и занафига последовательно их делать в плане ?!

(5) да

Короче, у нас так

фулл в воскресенье, с понедельника по субботу дифф и бэкап лога 10 минут
усё.
Только это отдельные задания в плане, а не как у тебя со стрелочками

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

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

(44) лог в один файл пишется. До меня так сделали и мне это удобно

(45) занафига делать это последовательно ?

у тебя же расписание будет применено ко всем одинаковое

Короче, какую то х..ню тебе сделали, а не план

(12) это не так, нужен фулл и ближайший разностный + логи от ближайшего разностного

И ничего очищать не надо, если восстанавливаешь через студию, то просто галку сними с лога, если он "влетел" раньше фуллбекапа

Короче, делаешь Один план и ТРИ вложенных плана - полный разностный и логов и у каждого вложенного СВОЁ расписание.
+ для логов можешь еще через "стрелочку" прицепить шринк лога после бекапа лога.
Ну и во всех вложенных - очистку после обслуживания, в которых  указать предел хранения файлов.

Ну и для каждого вложенного плана указываешь свой каталог для хранения (для удобства) и своё расширение (на всякий. чтоб не путать bak-и)

А я вообще планы не люблю. Скрипт + ручное задание = наше всё! Максимальная гибкость и прозрачность.

(52) (53) так и сделано

(54) +1
я тоже не люблю планы. Отлаживать их то ещё удовольствие

(55) да ну ? а в (5) что ?!

точнее в (0) - у тебя 1 план и 3 задания в нём..через стрелочку.

(58) это один из субпланов. Создание фулла

Диффы и логи отдельными субпланами делаются

(59) а зачем ты при создании фулла еще и дифф и бекап лога лепишь ?

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

(61) Да блеать! Чтобы они очистились

(63) Кто очистился ?

зачем скулю делать лишнюю работу по созданию пустого разностного бекапа ?

а туда запросто может влететь транзакция, между последним фулом и первым диффом.. ну и нафига хранить дифф с одной-паройизменений ?

(65) Бедный скуль, столько работы...

(66) Как она туда залетит, если сначала делается фулл, затем дифф, и лишь потом лог?

Карочи, нормальная рабочая схема. Не делайте мне мозги

(68) сделался фулл, закоммичилась транзакция получился не пустой дифф

Да и делать пустой дифф.. извращение

(69) это не схема, это полный ПЭ

(71) почему