Здравствуйте! MS SQL 2019 SE
Подскажите возможно ли побороть проблему восстановления цепочки архивов для базы с моделью восстановления FULL.
Ситуация: был настроен план архивации БД:
1) Полный архив - 2 раза в неделю
2) Разностный раз в 6 часов
3) Журнал транзакции 1 час.
Через некоторое время выяснилось, что цепочка архивов рвётся при создании архива ВМ в 5 утра . Служба SQL Writer - отключена, но тем не менее в пять утра появляются стабильно записи в backupset c признаком copy_only = 0. Местный админ отмалчивается по проблеме уже неделю, соответственно мне пришлось каждый день делать полный архив сразу после его. Всё бы ничего, но диск не резиновый, и создавать так часто полную копию не планировалось. Кроме этого при попытке восстановления базы этот архив так же мешал, так как физически на диске он отсутствовал. Я вычистил скриптом все упоминания об этом наборе их backupset, backupmediaset, backupfiles, backupgroups и т.д. После этого, хотя бы появилась возможность восстановить базу нормально на любой момент без плясок с бубном. Однако diff всё же не создаётся, так как в поле database_backup_lsn уже начало прописываться новое значение - для несуществующей на диске копии.
Перерыл кучу форумов, но так и не понял где (в какой ИБ) заменить это значение на LSN предыдущего полного бака, чтобы diff архив находил по LSN предыдущий архив а не натыкался на отсутствие последнего. Собственно даже не оч.понял, что возможно ли это вообще.

P.S. Склоняюсь к мысли просто восстанавливать из архива в 5.01 по состоянию на 4:59

Что за дикая ревность к скриншотам другого форума?

Вторая картинка.

alexeyvg,

Добрый день! коллега, да хоть раз в сутки, хоть раз в 6 часов - полный бэкап есть но при создании DIFF его не видит. Причина - другой номер LSN прописанные где то, не знаю где, но предполагаю, если узнаю что есть возможность его там заменить. На второй пикче в 8й строке 3й справа колонки видно что LSN уже другой, а в седьмой LSN ещё соответствовал полному баку в первой строке (6я колонка она ужата - видны только первые две цифры). Причина другого LSN - снятая системой автоматическая копия без выставления флага COPY ONLY её нет в этом списке, потому как я вытер все упоминания на неё, в надежде что новый DIFF спустится по цепочке и обнаружит полный бак. Но этого не произошло, так как DIFF сразу смотрит куда то, где уже записан новый LSN на снимке это номер 280500.. и пытается найти по 6й колонке полный архив с таким LSN и естественно не находит, так как его нет. Ранее, до того как скриптами вытереть записи об этом архиве она его не находила физически, потому как упоминание о полном архиве в системной таблице было, а самого архива не было. После вытирания упоминания о создании этого архива (на что я надеялся) я всё равно получил ошибку, так как алгоритм поиска полного бака происходит не так как я ожидал.

На самом деле я всё же разобрался. И проблема была действительно в службе SQL VSS Writer, служба была в состоянии запуска по требованию, а не в состоянии отключена. И при создании теневой копии тома, где были размещены ИБ благополучно запускалась. Когда я перевёл её в состояние отключена - архивы создаваться перестали, т.е. я устранил первопричину. Но желание восстанавливать цепочки дифф архивов осталась. Нужно только понять где хранится этот полный номер LSN и переписать его последним, нужным мне полным баком на второй пикче это номер в 7й строке 275400.. Тогда при поиске DIFF найдёт нужный полный бак, который присутствует на диске и всё будет работать.

SERG1257,

Добрый день! Да не резиновый, но дифф перед полным баком = 30 Мб, а полный бак - 1,5 Гб.

SERG1257SQL Server VSS Writer?
Да именно эта служба была причиной, выше написал как всё получилось.
SERG1257Картинки не показываются.
Картинки добавил, что за дикая ревность к чужому форуму? Разве плохо, что я сэкономил место на этом. Но не суть.
SERG1257Не создается или не восстанавливается.
Не создавался
SERG1257А если без диффов накатывая только бакапы логов восстанавливается?
Конечно, но они много места занимают, поэтому им TTL = 2 дня, а полному и дифу 21 и 14 дней соответственно.
SERG1257По хорошему надо договариватся с админом, либо не делать полный бакап либо научится с него восстанавливатся.
Я полагаю, восстановиться с этих баков можно было бы только если откатить полностью копию ВМ, при этом той же службой это и восстановилось бы. Теперь я точно зна, что если увижу архив с физическим размещением {какой то ГУИД} то это точно SQL VSS WRITER повинен.

Нужно было не восстановление, с ним то проблем как раз не было (точнее я их решил очисткой как раз записей в этих файлах), а создание нового дифа по расписанию без ошибок.
там выше я написал, что полный бак был, но при создании DIFF его не находил.
Если знаете команду BACKUP DIFFERENTIAL в которой можно указать какой полный архив нужно использовать - напишите, я не нашёл.

Это была служба SQL VSS WRITER которую нужно не по требванию оставлять, а отключать в моём случае совсем.


Спасибо, но вычислять вручную последовательность архивов на нужный момент времени я как то не горю желанием, для этого и существует SSMS

Возможность восстановления на любой момент я починил, писал об этом в самом начале. Мне нужно чтобы очередной дифф создавался по расписанию а он не создавался была ошибка:

Сообщение
Выполняется от имени пользователя: NT Service\SQLSERVERAGENT.Программа выполнения пакетов Microsoft (R) SQL Server Version 15.0.2000.5 for 64-bit (с) Корпорация Майкрософт (Microsoft Corporation), 2019. Все права защищены. Начало: 12:00:00 Выполнение: 2020-07-07 12:00:00.65 Источник: {772914CF-36D8-4892-945B-D4EEA843A562} Выполнение запроса "DECLARE @Guid UNIQUEIDENTIFIER EXECUTE msdb..sp...".: 100% завершено Конец выполнения Ошибка: 2020-07-07 12:00:00.84 Код: 0xC002F210 Источник: Резервное копирование базы данных (разностное) Задача "Выполнение SQL" Описание: Сбой выполнения запроса "BACKUP DATABASE [cpm.modeling] TO DISK = N'E:\SQL..." со следующей ошибкой: "Не удается выполнить разностное резервное копирование для базы данных "cpm.modeling", так как не существует ее текущей резервной копии. Произведите полное резервное копирование базы данных, выполнив инструкцию BACKUP DATABASE без параметра WITH DIFFERENTIAL. BACKUP DATABASE прервано с ошибкой.". Возможные причины сбоя: проблемы с этим запросом, свойство "ResultSet" установлено неправильно, параметры установлены неправильно или соединение было установлено неправильно. Конец ошибки DTExec: завершено исполнение пакетаDTSER_FAILURE (1). Начало: 12:00:00 Готово: 12:00:00 Прошло:0.75 секунд. Не удалось выполнить пакет. Шаг завершился с ошибкой.

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

Коллеги, всем спасибо за ответы, хотя у меня сложилось однозначное впечатление, что я написал свой вопрос как то неправильно. Я получил ответы про прописные истины, о том, что нужно чтобы восстановиться. Это я всё и так знаю, и с восстановлением у меня проблем НЕТ. Была проблема с созданием дифференциального архива. Острой необходимости сейчас уже нет, так как найдена первопричина - что создаёт копии без признака COPY ONLY и устранена (хорошо что у меня на этом сервере были делегированы права по настройке служб SQL, во всём остальном я там не админ). Остался интерес возможности исправить ситуацию: дать при создании разностного архива системе возможность найти реально присутствующий полный архив в системе.