Резервное копирование журнала транзакций завершается неудачно, если не существует полной резервной копии
... по крайней мере, я так думаю.
Недавно я обновил подпрограмму резервного копирования на сервере разработки. Я создал план обслуживания для пользовательских баз данных, который выполнял некоторые еженедельные задачи очистки, ежедневные полные резервные копии и резервные копии журнала транзакций в ключевые моменты в течение дня.
Все работало хорошо до сегодняшнего дня, когда я получил электронное письмо с уведомлением о том, что резервное копирование на обед не удалось. Средство просмотра журнала не показывало ничего, кроме того, что определенное количество БД было полностью сохранено, прежде чем завершить запись в журнале:
[snipped] Source: ... The package execution fa... The step failed.
Не совсем показательно
Мне пришло в голову, что единственным изменением предыдущих попыток было то, что я создал новую (маленькую и непримечательную) базу данных этим утром.
Я перезапустил агент SQL Server и попытался вручную повторно выполнить шаг (резервное копирование журнала транзакций), но он снова не удался.
Однако выполнение этапа полного резервного копирования (таким образом, создание первой полной резервной копии для моей новой БД) сработало, более того, снова сработал этап резервного копирования журнала транзакций.
Похоже, что резервное копирование журнала транзакций из-за отсутствия полной резервной копии или предыдущей резервной копии журнала транзакций.
Это ожидаемое поведение? С одной стороны, на примитивном уровне этот вид имеет смысл, но на самом деле, я ожидал бы, что он справится с таким сценарием более изящно.
Если так, есть ли способ автоматически справиться с этим? Это случается не так часто, но я не могу не вспомнить, чтобы при создании резервной копии БД я создавался, тем более что это только на ранних стадиях разработки.
Если нет, то какова вероятная причина такого поведения? Могу ли я избежать этого?
2 ответа
Да, это ожидаемое поведение. Чтобы журналы транзакций были полезны, необходимо создать полную резервную копию для использования в качестве отправной точки для отката вперед.
Не беспокойся об этом слишком сильно. Если вы создадите новую базу данных, в первый день вы получите эту ошибку. Как вы видели, резервное копирование журналов для других БД будет успешным, но из-за этой ошибки она будет СМОТРЕТЬ, как неудачный шаг, когда на самом деле вышла из строя только одна БД. Затем, в ту ночь (или когда-либо), он сделает полную резервную копию. После этого резервное копирование журнала транзакций будет успешным для новой БД. По сути, у вас будет один день или ошибки при создании новой БД, пока не будет выполнено задание полного резервного копирования.
Я поставил флажок в моем списке DBS для резервного копирования, который указывает, что оно было скопировано. Сценарий резервного копирования не будет выполнять резервное копирование Txn, пока он не будет равен 1. В моем сценарии полного резервного копирования я установил флаг 1. Presto, больше никаких сбоев.