Невозможно восстановить журнал или разностную резервную копию, так как нет файлов, готовых для повтора транзакций
Обновлено: 03.07.2024
Присоединяйтесь к другим MSP, стремящимся к росту, и снабжайте свой бизнес новыми советами и учебными пособиями, которые будут доставлены прямо на ваш почтовый ящик.
Не пропустите акции, бесплатные инструменты, мероприятия и вебинары, а также обновления продуктов. Подпишитесь, чтобы получать новостную рассылку NinjaOne.
Расти быстрее. Меньше стресса.
Непрерывность бизнеса и безопасность являются главными приоритетами для ИТ-специалистов. Наряду с инструментами защиты данных резервное копирование данных играет важную роль в поддержании работы организации. В инструментах и методах резервного копирования и восстановления недостатка нет, но избыток вариантов может затруднить выбор наиболее эффективного набора операций резервного копирования.
В этой статье мы подробно рассмотрим различные типы резервного копирования, уделяя особое внимание дифференциальному резервному копированию, чтобы вы могли принимать более обоснованные решения о собственных решениях для резервного копирования.
О чем пойдет речь в этой статье:
- Что такое дифференциальная резервная копия?
- Что дифференциальное резервное копирование делает во время резервного копирования
- Какие существуют другие типы резервного копирования данных и как они работают?
- Как выбрать лучшую резервную копию для вашего случая использования
Защита данных не может быть обеспечена без какой-либо формы резервного копирования. Даже самые полные уровни кибербезопасности не могут обеспечить безопасность организации без средств резервного копирования и восстановления ценных файлов. Раньше резервное копирование и восстановление выполнялись вручную, но современные приложения упрощают эту задачу за счет автоматизации и оптимизации резервного копирования. Тем не менее, не существует единого типа резервного копирования и, конечно же, универсального идеального метода резервного копирования для любых нужд.
Доступные типы операций резервного копирования постепенно менялись с годами, чтобы обеспечить различный баланс безопасности и использования ресурсов. Наиболее распространенными типами резервного копирования являются полная резервная копия, добавочная резервная копия и дифференциальная резервная копия, при этом синтетические полные резервные копии и зеркальное копирование используются реже.
Современным ИТ-менеджерам также приходится выбирать между облачными, локальными или гибридными решениями для резервного копирования. Тип резервного копирования должен соответствовать выбранному методу, так как некоторые сетки лучше других. Например, добавочные резервные копии, как правило, лучше подходят для облачных резервных копий, поскольку они используют меньше ресурсов. Зеркальное резервное копирование обычно используется локально и часто включает внешние жесткие диски или диски.
Давайте подробнее рассмотрим различные доступные типы резервного копирования:
Полные резервные копии
Это самый простой и полный тип операции резервного копирования. Как и следовало ожидать, полная резервная копия создает копию всех данных и сохраняет их на запоминающем устройстве, таком как съемный диск или диск. Проблема с полными резервными копиями заключается в том, что для их выполнения требуется гораздо больше времени, чем для любого другого типа, и для них требуется больше всего места для хранения (и, возможно, покупка носителя или жестких дисков). Однако у выполнения полного резервного копирования есть ключевые преимущества, которые делают его жизнеспособным. Регулярные полные резервные копии означают, что полные копии всех данных доступны на одном наборе носителей. Поскольку резервные копии данных организованы и полны, время восстановления данных (показатель, известный как целевое время восстановления) значительно сокращается.
Поскольку полное резервное копирование требует больших затрат времени и ресурсов, оно обычно запускается только периодически, если у организации нет очень небольшого объема данных для защиты. Затем эти периодические полные резервные копии часто дополняются добавочными или дифференциальными резервными копиями.
Инкрементальные резервные копии
При добавочном резервном копировании копируются только те данные, которые изменились с момента последней операции резервного копирования. Проще говоря, операция инкрементного резервного копирования предполагает, что неизмененные файлы и данные не нужно копировать повторно, и фокусируется только на тех, временные метки которых изменились с момента выполнения любого другого резервного копирования.
Поскольку при инкрементном резервном копировании копируются только измененные данные, организация может запускать его сколь угодно часто, сохраняя при этом низкий уровень использования ресурсов. Инкрементальные резервные копии сохраняют меньшие объемы данных, чем полные резервные копии, поэтому обеспечивают более высокую скорость резервного копирования и меньшую потребность в дисковом пространстве.
Зеркальное резервное копирование
Зеркальное резервное копирование сравнимо с полным резервным копированием. Ключевое отличие состоит в том, что исходные данные по существу «клонируются» в их текущем состоянии, и никакие предыдущие версии данных не сохраняются. Поскольку зеркальные резервные копии копируют данные точно в том виде, в каком они существуют на исходном устройстве — файловая структура, приложения и т. д., — время восстановления может быть одним из самых быстрых. Отдельные резервные копии файлов также легко найти, так как данные каталогизированы точно так же, как и на исходном устройстве.
Однако у зеркального резервного копирования есть и недостатки. Возможно, наиболее очевидным является количество места, которое требуется. Если операция резервного копирования представляет собой клонирование исходного устройства или файловой системы, потребность в хранилище для резервных копий существенно удвоится по сравнению с потребностью в оперативной памяти.
Стоит также отметить, что потеря предыдущих версий исходных данных может быть рискованной, поскольку любое повреждение или проникновение в источник будут перенесены в резервную копию 1:1 при каждом запуске операции резервного копирования.
Возможно, вы уже знакомы с особым типом зеркалирования, называемым зеркалированием дисков, также известным как RAID 1. Этот процесс реплицирует данные на два или более дисков и часто настраивается на настольных компьютерах с двумя жесткими дисками для резервирования, а не для повышения производительности. . Зеркальное отображение дисков идеально подходит в тех случаях, когда приоритет отдается доступности данных из-за быстрого времени восстановления. Для зеркального отображения дисков требуется как минимум два физических диска, что является одновременно и бременем, и благом. Если один из этих жестких дисков выходит из строя, другой предлагает возможность немедленного восстановления после сбоя, что делает его идеальным для аварийного восстановления. Тем не менее, бремя становится заметным, если необходимо приобрести и обслуживать множество дисков резервного копирования.
Разностные резервные копии
Дифференциальные резервные копии — наша основная тема для обсуждения. Поскольку они имеют общие ключевые моменты с другими типами резервного копирования, дифференциальные резервные копии предлагают хороший компромисс между самыми крайними вариантами.
Дифференциальное резервное копирование похоже на добавочное резервное копирование при первом запуске; он начинается с копирования всех данных, измененных из предыдущей резервной копии. В отличие от инкрементного резервного копирования, он будет продолжать копировать все данные, измененные с момента предыдущего полного резервного копирования. Это означает, что в дифференциальных резервных копиях хранится больше данных, чем в инкрементной резервной копии при каждой последующей операции, но все же намного меньше, чем в полной резервной копии. В целом пространство и время, необходимые для дифференциального резервного копирования, находятся где-то между добавочными и полными резервными копиями.
Что делает дифференциальное резервное копирование в процессе резервного копирования?
Каждый из перечисленных выше процессов резервного копирования работает по-разному. Как правило, организация должна выполнить полное резервное копирование хотя бы один раз. Реальные решения вступают в игру для последующих резервных копий. Что лучше: запустить еще одну полную, инкрементную или дифференциальную резервную копию?
При первом частичном резервном копировании, выполненном после первоначального полного резервного копирования, будут созданы резервные копии тех же данных, независимо от того, являются ли они инкрементными или дифференциальными.
Разница проявляется во время третьей операции резервного копирования. Данные, для которых выполняется инкрементное резервное копирование, ограничиваются изменениями, внесенными с момента последнего инкрементного копирования, в то время как в дифференциальном резервном копировании сохраняются все изменения, внесенные с момента первого полного резервного копирования.
Выбор оптимальной стратегии резервного копирования обычно включает поиск компромисса между производительностью, уровнями защиты данных, общим объемом сохраняемых данных, временем восстановления и стоимостью.
Как мы уже говорили, для ежедневного выполнения полного резервного копирования требуется больше всего места и больше всего времени, но некоторые организации по-прежнему выбирают этот путь из-за связанных с ним преимуществ. Общее количество копий данных больше, и для выполнения операции восстановления требуется меньшее количество носителей. Полные резервные копии, как правило, обладают наибольшей устойчивостью к сбоям и обеспечивают самое быстрое восстановление.
Больше организаций предпочитают регулярно выполнять полное резервное копирование, обычно еженедельно, в сочетании с ежедневным выполнением добавочного резервного копирования. Это делает доступным меньше копий данных, а время восстановления увеличивается, поскольку необходимо будет восстанавливать несколько ежедневных резервных копий. Например, если требуются данные из резервной копии в среду, потребуются все инкрементные резервные копии, начиная с последней полной резервной копии, скажем, в воскресенье. В худшем случае для выполнения восстановления может потребоваться шесть наборов резервных копий данных.
Еженедельное полное резервное копирование плюс ежедневное дифференциальное резервное копирование — хороший компромисс. Для восстановления требуется больше наборов резервных носителей, чем при ежедневной полной политике, но меньше, чем при ежедневной добавочной политике. Для восстановления данных за любой конкретный день требуется не более двух наборов носителей, что сокращает время, необходимое для восстановления, и потенциальные проблемы с нечитаемым набором резервных копий.
Правило резервного копирования 3-2-1
Мы рекомендуем следовать правилу резервного копирования 3-2-1, которое требует наличия трех копий данных на двух разных носителях и одной копии за пределами площадки.
Выбор правильного типа резервного копирования
Для организаций с небольшими наборами данных выполнение ежедневного полного резервного копирования часто является простым решением. Ежедневное полное резервное копирование обеспечивает высокий уровень защиты без особых дополнительных затрат на дисковое пространство. Крупные организации или организации с большим объемом данных или серверов редко выбирают этот путь из-за того, что для этого требуются ресурсы и время.
Люди с большими объемами данных обычно еженедельно выполняют полное резервное копирование в сочетании с ежедневными добавочными или дифференциальными резервными копиями. Использование дифференциалов обеспечивает более высокий уровень защиты данных с меньшим временем восстановления, не требуя при этом значительного объема памяти. Еженедельное полное резервное копирование с ежедневным дифференциальным резервным копированием — хороший вариант для многих организаций, поскольку он дает лучшее из обоих миров.
Какую стратегию резервного копирования лучше всего использовать?Настоящий вопрос, который должны задать ИТ-менеджеры, заключается в том, когда использовать каждый из них и как эти варианты следует комбинировать, чтобы достичь общих бизнес-целей, производительности и времени безотказной работы.
Также важно помнить, что резервное копирование предназначено не для хранения файлов, а для возможности их восстановления. Если файлы не могут быть восстановлены после аварии, удаления или кибератаки, резервное копирование не выполнило свою работу. Поэтому тестирование резервных копий так же важно, как и их планирование.
Общий ИТ-ландшафт
Резервные копии являются неотъемлемой частью комплексного плана обеспечения безопасности и защиты данных. Но непрерывность бизнеса и снижение рисков — это только часть общей картины, когда речь идет об ИТ. Часто возникает важный вопрос: «Как мне управлять всеми этими устройствами и решениями?»
Перспектива управления ИТ на многих устройствах и, возможно, даже во многих местах может показаться невыполнимой. Именно тогда вступает в игру самый большой переломный момент в управлении ИТ:
Я использую SQL Server. Возникла проблема с моими дифференциальными резервными копиями. Я делаю полную резервную копию своей базы данных в конце недели, кроме того, я также ежедневно делаю дифференциальную резервную копию базы данных. Я создал задание, которое автоматически выполняет эти задачи резервного копирования. После того, как я взял эти полные и разные резервные копии, я восстанавливаю их с рабочим графиком каждый день и неделю. Моя задача полного восстановления успешно работает каждую неделю, но когда моя другая задача, которая восстанавливает ежедневную разностную резервную копию, пытается работать, она завершается с ошибкой «Журнал или разностная резервная копия не могут быть восстановлены, поскольку нет файлов, готовых к повтору транзакций».
У меня есть два сервера баз данных. Один из них — производственный сервер, а другой — сервер отчетов. Сервер отчетов содержит ту же базу данных, что и рабочий сервер базы данных. В конце каждой недели я делаю полную резервную копию базы данных на сервере prodcution db для сервера отчетов. Точно так же каждую полночь я делаю дифференциальное резервное копирование базы данных на производственном сервере для сервера отчетов. На следующий день я восстанавливаю последнюю копию diff в базу данных на сервере отчетов. Я использую визуальный инструмент cron для процесса, но он не работает с этой ошибкой. Я попытался восстановить вручную, но получил такое же сообщение об ошибке.
Вот мои команды восстановления.
Как решить эту проблему? Вы можете мне помочь?
Заранее спасибо.
Нам нужна дополнительная информация о том, как работают задачи, в частности, какие команды и программы они запускают. Вы написали, что задачи отвечают за создание резервных копий, но сообщение об ошибке предполагает, что проблема связана с восстановлением.
>>>но когда моя другая задача, которая ежедневно выполняет дифференциальное резервное копирование, пытается работать, она завершается с ошибкой: «Журнал или дифференциальное резервное копирование **не может быть восстановлено**
У меня есть два сервера баз данных. Один из них — производственный сервер, а другой — сервер отчетов. Сервер отчетов содержит ту же базу данных, что и рабочий сервер базы данных. В конце каждой недели я делаю полную резервную копию базы данных на сервере prodcution db для сервера отчетов. Точно так же каждую полночь я делаю дифференциальное резервное копирование базы данных на производственном сервере для сервера отчетов. На следующий день я восстанавливаю последнюю копию diff в базу данных на сервере отчетов. Я использую визуальный инструмент cron для процесса, но он не работает с этой ошибкой. Я попытался восстановить вручную, но получил такое же сообщение об ошибке.
Что такое "DatabaseRestoreMany"? Какие команды выполняют этот процесс? Пытаетесь ли вы восстановить резервную копию различий без предварительного восстановления полной резервной копии?
DatabaseRestoreMany — это процедура сохранения, написанная кем-то ранее. @sepupic Позвольте мне привести вам пример процесса. Сегодня среда. Я восстановил полную резервную копию базы данных в воскресенье. После этого я восстанавливал свой diff из резервной копии день за днем. Когда моя работа пытается восстановить резервную копию diff до отчетной базы данных, она падает и выдает исключение. Вот почему я восстановил руководство по диффу. Вчера и сегодня я видел одну и ту же проблему.
Я получил следующее электронное письмо от одного из моих читателей.
Я новичок в SQL Server, и наш постоянный администратор баз данных в отпуске. В нашей производственной базе данных возникла проблема, и я только что восстановил полную резервную копию базы данных на производственном сервере. Когда я пытаюсь применить журнал обратно, я получаю следующую ошибку. Я уверен, что это действительный файл резервной копии журнала. Скриншот прилагается.
[Некоторые другие сведения о сервере/IP-адресе удалены]
Сообщение 3117, уровень 16, состояние 1, строка 1
Невозможно восстановить журнал или разностную резервную копию, так как нет файлов, готовых к повтору транзакций.
Сообщение 3013, уровень 16, состояние 1, строка 1
Журнал восстановления завершается аварийно.
Скриншот прилагается. [Удалено, так как содержит действующий IP-адрес]
Немедленно помогите.
Ну, я ответил на этот вопрос в своем предыдущем посте, 2 года назад, здесь SQL SERVER - Исправление: ошибка: сообщение 3117, уровень 16, состояние 4 Невозможно восстановить журнал или разностную резервную копию, поскольку нет файлов, готовых к повтору транзакций. .Однако на этот раз я попытаюсь объяснить это немного подробнее.
Для использования базы данных SQL Server она должна находиться в онлайн-состоянии. Существует несколько состояний базы данных SQL Server.
- ОНЛАЙН (доступно – онлайн для данных)
- В АВТОНОМНОМ РЕЖИМЕ
- ВОССТАНОВЛЕНИЕ
- ВОССТАНОВЛЕНИЕ
- ВОССТАНОВЛЕНИЕ ОЖИДАЕТСЯ
- Подозреваю
- Экстренная ситуация (ограниченная доступность)
Если база данных находится в сети, это означает, что она активна и находится в рабочем режиме. Нет смысла применять дополнительный журнал из резервной копии, если операции с этой базой данных продолжаются. Общепринятой практикой в процессе восстановления резервной копии является указание ключевого слова RECOVERY при восстановлении базы данных. Когда указано ключевое слово RECOVERY, SQL Server возвращает базу данных в оперативный режим и не принимает никаких дополнительных резервных копий журналов.
Однако, если вы хотите восстановить более одного файла резервной копии, то есть после восстановления полной резервной копии, если вы хотите применить дополнительную дифференциальную резервную копию или резервную копию журнала, вы не можете сделать это, когда база данных находится в сети и уже активна. Вам нужно, чтобы ваша база данных находилась в состоянии, в котором она может в дальнейшем принимать данные резервного копирования, а не онлайн-запрос данных. Если SQL Server подключен к сети и также принимает файл резервной копии базы данных, может возникнуть несогласованность данных. По этой причине, когда требуется восстановить более одного файла резервной копии базы данных, необходимо восстановить базу данных с ключевым словом NO RECOVERY в операции RESTORE.
Предлагаю всем вам прочитать еще один пост, написанный мной ранее. В этом посте я объяснил временную шкалу с изображением и графикой SQL SERVER — временная шкала резервного копирования и понимание процесса восстановления базы данных в модели полного восстановления.
Пример кода для справки:
ВОССТАНОВИТЬ БАЗУ ДАННЫХ AdventureWorks
С ДИСКА = 'C:\AdventureWorksFull.bak'
БЕЗ ВОССТАНОВЛЕНИЯ ;
ВОССТАНОВИТЬ БАЗУ ДАННЫХ AdventureWorks
С ДИСКА = 'C:\AdventureWorksDiff.bak'
С ВОССТАНОВЛЕНИЕМ ;
В этом посте я не пытаюсь рассказать о полном резервном копировании и восстановлении. Я просто пытаюсь рассмотреть один тип ошибки и ее решение. Протестируйте эти сценарии на сервере разработки. Игра с резервным копированием и восстановлением базы данных в реальном времени всегда очень важна и должна быть правильно спланирована. Оставьте комментарий здесь, если вам нужна помощь по этой теме.
Примечание. Мы расскажем об обслуживании и восстановлении резервного сервера в другом посте блога и намеренно не освещаем этот пост.
Здравствуйте,
Я хотел бы поделиться правильным способом восстановления базы данных SQL, когда вы используете как полную резервную копию, так и файл дифференциальной резервной копии для восстановления вашей БД.
Как обычно, я начал с восстановления БД из файла, оставив все остальные параметры по умолчанию. Позже, когда я попытался восстановить файл дифференциальной резервной копии, на моем экране появилась следующая ошибка:
Вскоре я связался со своим ИТ-отделом, и они подсказали мне правильный способ восстановления БД с помощью дифференциального резервного копирования.
Разница между состоянием Recovery и NoRecovery при восстановлении БД:
NORECOVERY указывает, что откат не происходит. Это позволяет продолжить повтор транзакций со следующего оператора в последовательности.
В этом случае последовательность восстановления может восстановить другие резервные копии и выполнить их повтор.
ВОССТАНОВЛЕНИЕ (по умолчанию) указывает, что откат должен выполняться после завершения отката для текущей резервной копии.
Для восстановления базы данных требуется, чтобы весь набор восстанавливаемых данных (набор повтора транзакций) соответствовал базе данных. Если набор повторов транзакций не был выполнен достаточно далеко для согласования с базой данных и указано RECOVERY, компонент Database Engine выдает ошибку.
Подводя итог, после восстановления полной резервной копии, если вы хотите применить дополнительную дифференциальную резервную копию или резервную копию журнала, вы не можете сделать это, когда база данных находится в сети и уже активна. Вам нужно, чтобы ваша база данных находилась в состоянии, в котором она может в дальнейшем принимать данные резервного копирования, а не онлайн-запрос данных, иначе может возникнуть несогласованность данных. По этой причине, когда требуется восстановить более одного файла резервной копии базы данных, необходимо восстановить базу данных с ключевым словом NO RECOVERY в операции RESTORE.
- Итак, во-первых, при восстановлении БД с помощью полной резервной копии
Щелкните правой кнопкой мыши БД -> Задача -> Восстановить -> База данных ,
перейдите к Параметры в левом верхнем углу окна.
Выберите параметр Состояние восстановления с параметром ВОССТАНОВИТЬ БЕЗ ВОССТАНОВЛЕНИЯ.
или используйте команду:
- Во-вторых, при восстановлении разностной резервной копии выполните первый шаг, если у вас много файлов разностной резервной копии. Когда вы начнете восстанавливать последний файл дифференциальной резервной копии, выберите параметр Состояние восстановления с ВОССТАНОВЛЕНИЕ С ВОССТАНОВЛЕНИЕМ.
или используйте команду:
Примечание. Иногда даже после полного восстановления БД появляется сообщение «Восстановление…» перед БД.
Я потратил много времени на борьбу с этим, надеюсь, что этот пост поможет кому-то сделать правильные шаги.
Журнал или дифференциальная резервная копия не могут быть восстановлены, так как при выполнении дифференциального восстановления базы данных SQL не получены файлы, готовые к повтору транзакций.
Сообщение об ошибке
V-79-65323-3117 – Резервную копию журнала или дифференциальную резервную копию нельзя восстановить, так как нет файлов, готовых к повтору транзакций.
Причина
Восстановление завершится с ошибкой, указанной выше, если предыдущее задание восстановления было запущено с параметром "Оставить базу данных готовой к использованию. Дополнительные журналы транзакций не могут быть восстановлены". вернуть любую незафиксированную транзакцию. После применения этого параметра база данных находится в согласованном состоянии и готова к использованию, и дальнейшие наборы не могут быть восстановлены.
Решение
<р>1. Запустите восстановление полного набора резервных копий с параметром «Оставить базу данных нерабочей, можно восстановить дополнительные журналы транзакций», чтобы убедиться, что SQL Server не выполняет откат незафиксированных транзакций и позволяет применять дополнительные резервные копии. После применения этой опции база данных становится недоступной для использования, и можно восстановить дополнительные журналы транзакций. (Рисунок 1)
Рисунок 1
Рисунок 2
Дополнительную информацию о настройке параметров резервного копирования и восстановления по умолчанию в SQL см. в разделе соответствующих документов ниже.
Читайте также: