Не удается создать план восстановления из-за нарушения непрерывности цепочки LSN
В MS SQL создан план обслуживания, который делает бэкапы:
1. Полный бэкап - раз в неделю
2. Дифференциальный бэкап раз - раз в день
3. Бэкап журнала транзакций - раз в 15 минут
По идее, такая схема даёт возможность восстановить базу с потерей данных максимум за 15 минут. Восстановление идёт без проблем, но только до момента создания второго дифференциального бэкапа. Ко второму дифференциальному бэкапу не подтягивается полный и дифференциальный не на что ставить. В чём может быть проблема? Кто-то сталкивался с подобной проблемой?
1. Полный бэкап - раз в неделю
2. Дифференциальный бэкап раз - раз в день
3. Бэкап журнала транзакций - раз в 15 минут
По идее, такая схема даёт возможность восстановить базу с потерей данных максимум за 15 минут. Восстановление идёт без проблем, но только до момента создания второго дифференциального бэкапа. Ко второму дифференциальному бэкапу не подтягивается полный и дифференциальный не на что ставить. В чём может быть проблема? Кто-то сталкивался с подобной проблемой?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Ну у меня ж всё есть, всё в одной папке хранится. Я не понимаю, почему диф бэкапу не подходит полный. У меня так: в воскресенье делается полный бэкап, а потом каждый день дифференциальный. В пн сделался диф бэкап и я могу восстановиться за весь понедельник, потом создаётся диф бэкап во вторник и я уже не могу восстановиться, но при этом всё ещё могу восстановиться на понедельник
Не уверен, но я почему думал что поднимаешь полый бекап, потом накатывает все бекапы транзакций, потом диф, потом опять транзакций, потом снова диф и так до нужной даты.
Я пару раз помучился и теперь делаю полный бекап каждую ночь. Ну его.
Я пару раз помучился и теперь делаю полный бекап каждую ночь. Ну его.
(4), ну там дифф бэкап всё время растёт, пока не сделаешь полный. Он накапливает в себе изменения с момента создания полного бэкапа. Вроде как сначала накатывается полный, потом диф. бэкап, а потом уже все транзакции
Я пока только вникаю в тему, поэтому могу ошибаться
Я пока только вникаю в тему, поэтому могу ошибаться
(5)
Пошарился по заначкам , вот чего нарыл у себя в записях.
Возможны 2 ситуации:
1. Достаточно наличие любого полного бэкапа (желательно последнего для экономии времени) и все бэкапы логов транзакций от момента полного бэкапа до момента восстановления.
2. Достаточно наличие любого полного бэкапа, любого дифф. бэкапа сделанного после данного полного, но до следующего полного и все бэкапы логов транзакций от момента взятого дифф. бэкапа до момента восстановления.
Понятно, что цепочка бэкапов журналов транзакций должна быть непрерывной (не должно быть, например, смены модели на простую и обратно в течение цепочки). Если бы необходимо было использовать последний полный бэкап, тогда log shipping был бы невозможен.
походу тебе надо только последний диф накатывать.
Пошарился по заначкам , вот чего нарыл у себя в записях.
Возможны 2 ситуации:
1. Достаточно наличие любого полного бэкапа (желательно последнего для экономии времени) и все бэкапы логов транзакций от момента полного бэкапа до момента восстановления.
2. Достаточно наличие любого полного бэкапа, любого дифф. бэкапа сделанного после данного полного, но до следующего полного и все бэкапы логов транзакций от момента взятого дифф. бэкапа до момента восстановления.
Понятно, что цепочка бэкапов журналов транзакций должна быть непрерывной (не должно быть, например, смены модели на простую и обратно в течение цепочки). Если бы необходимо было использовать последний полный бэкап, тогда log shipping был бы невозможен.
походу тебе надо только последний диф накатывать.
(6), Я так и делаю...
На первой картинке восстановление успешно проходит, но вот когда пытаюсь сделать восстановление позднее второго бэкапа, появляется ошибка (на второй картинке, чуть выше окна с выбором даты). Шкала с белыми пятнаями из-за масштаба, а так всех журналов транзакций хватает, там всё зелёное, т. е. нет прерываний никаких
На первой картинке восстановление успешно проходит, но вот когда пытаюсь сделать восстановление позднее второго бэкапа, появляется ошибка (на второй картинке, чуть выше окна с выбором даты). Шкала с белыми пятнаями из-за масштаба, а так всех журналов транзакций хватает, там всё зелёное, т. е. нет прерываний никаких
Прикрепленные файлы:
(7)Вопрос:Я занимаюсь разработкой плана резервного копирования наших баз данных, который помимо прочего предусматривает резервное копирование журнала транзакций. Это позволит нам в случае сбоя восстановить систему, потеряв минимум данных. Исследуя, с какими проблемами мы можем столкнуться, я много раз читал, что нужно быть очень внимательным, чтобы не разорвать цепочку резервных копий журнала. Не могли бы вы объяснить, что это за цепочка и как ее можно разорвать?
Ответ:Это замечательный вопрос, так как очень часто о таких нюансах забывают. Цепочкой резервных копий журнала (иногда ее просто называют цепочкой журнала) называют непрерывный набор резервных копий журнала транзакций, которые охватывают время с момента создания самой последней резервной копии данных (полной или разностной) до момента, на который надо восстановить сервер. Примерная последовательность применения резервных копий в процессе восстановления такова:
самая свежая полная резервная копия базы данных;
самая свежая разностная резервная копия базы данных;
все резервные копии журнала транзакций, созданные позже.
Большинство ИТ-специалистов хранят больше резервных копий журнала транзакций на случай, если какая-то из резервных копий окажется поврежденной, и придется восстанавливать систему, используя не самую свежую резервную копию данных. За более подробной информацией отсылаю к двум моим статьям о резервном копировании и восстановлении, опубликованных в прошлом году в TechNet Magazine : "Understanding SQL Server Backups" и "Recovering from Disasters Using Backups".
Если какая-либо из резервных копий журнала в выбранной последовательности восстановления повреждена или отсутствует, цепочка резервных копий журнала будет нарушена и систему не удастся восстановить дальше этой точки. Если повреждена только одна из резервных копий журнала, можете принудительно восстановить систему, используя параметр WITH CONTINUE_AFTER_ERROR. При этом будут восстановлены и поврежденные записи журнала транзакций, что повлечет за собой повреждение базы данных. Советую сто раз подумать, прежде чем применять этот тип восстановления.
Одна из операций, которая могла привести к отсутствию необходимой резервной копии журнала, - создание "внеочередной" резервной копии (например, чтобы отдать копию разработчику) без обеспечения сохранности цепочки. Эта резервная копия журнала является частью цепочки резервных копий журналов, поскольку содержит записи журнала, созданные с момента создания предыдущей резервной копии журнала.
Так происходит, если не использовать параметр WITH COPY_ONLY, который позволяет создать резервную копию журнала, но при этом следующая резервная копия будет содержать те же записи журнала. Подробнее о том, как избежать прерывания цепочки резервных копия см. в записи "BACKUP WITH COPY_ONLY" с моем блоге.
Более популярный пример нарушения цепочки резервных копий - операция, которая не позволяет создать регулярную резервную копию журнала транзакций. К таким операциям относятся:
переход на простую модель восстановления и затем обратно к полной модели или модели с неполным протоколированием (BULK_LOGGED);
создание дампа журнала в версии SQL Server 2005 или более ранней, используя параметр BACKUP LOG … WITH NO_LOG или TRUNCATE_ONLY;
восстановление базы данных из моментального снимка;
создание резервной копии данных (полной или разностной) после любой из этих операций, чтобы обеспечить продолжение регулярного резервного копирования журнала. Это называется перезапуском цепочки резервных копий.
И последнее: совершенно ошибочен тот популярный миф, что создание полной или разностной резервной копии нарушает цепочку резервных копий - оно вообще никак не влияет на резервное копирование журнала.
Ответ:Это замечательный вопрос, так как очень часто о таких нюансах забывают. Цепочкой резервных копий журнала (иногда ее просто называют цепочкой журнала) называют непрерывный набор резервных копий журнала транзакций, которые охватывают время с момента создания самой последней резервной копии данных (полной или разностной) до момента, на который надо восстановить сервер. Примерная последовательность применения резервных копий в процессе восстановления такова:
самая свежая полная резервная копия базы данных;
самая свежая разностная резервная копия базы данных;
все резервные копии журнала транзакций, созданные позже.
Большинство ИТ-специалистов хранят больше резервных копий журнала транзакций на случай, если какая-то из резервных копий окажется поврежденной, и придется восстанавливать систему, используя не самую свежую резервную копию данных. За более подробной информацией отсылаю к двум моим статьям о резервном копировании и восстановлении, опубликованных в прошлом году в TechNet Magazine : "Understanding SQL Server Backups" и "Recovering from Disasters Using Backups".
Если какая-либо из резервных копий журнала в выбранной последовательности восстановления повреждена или отсутствует, цепочка резервных копий журнала будет нарушена и систему не удастся восстановить дальше этой точки. Если повреждена только одна из резервных копий журнала, можете принудительно восстановить систему, используя параметр WITH CONTINUE_AFTER_ERROR. При этом будут восстановлены и поврежденные записи журнала транзакций, что повлечет за собой повреждение базы данных. Советую сто раз подумать, прежде чем применять этот тип восстановления.
Одна из операций, которая могла привести к отсутствию необходимой резервной копии журнала, - создание "внеочередной" резервной копии (например, чтобы отдать копию разработчику) без обеспечения сохранности цепочки. Эта резервная копия журнала является частью цепочки резервных копий журналов, поскольку содержит записи журнала, созданные с момента создания предыдущей резервной копии журнала.
Так происходит, если не использовать параметр WITH COPY_ONLY, который позволяет создать резервную копию журнала, но при этом следующая резервная копия будет содержать те же записи журнала. Подробнее о том, как избежать прерывания цепочки резервных копия см. в записи "BACKUP WITH COPY_ONLY" с моем блоге.
Более популярный пример нарушения цепочки резервных копий - операция, которая не позволяет создать регулярную резервную копию журнала транзакций. К таким операциям относятся:
переход на простую модель восстановления и затем обратно к полной модели или модели с неполным протоколированием (BULK_LOGGED);
создание дампа журнала в версии SQL Server 2005 или более ранней, используя параметр BACKUP LOG … WITH NO_LOG или TRUNCATE_ONLY;
восстановление базы данных из моментального снимка;
создание резервной копии данных (полной или разностной) после любой из этих операций, чтобы обеспечить продолжение регулярного резервного копирования журнала. Это называется перезапуском цепочки резервных копий.
И последнее: совершенно ошибочен тот популярный миф, что создание полной или разностной резервной копии нарушает цепочку резервных копий - оно вообще никак не влияет на резервное копирование журнала.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот