Sql в процессе восстановления что делать
Ручной Способ исправить Состояние ожидания восстановления SQL Server
Люди, которые использовали SQL-сервер, возможно, однажды столкнулись с ошибкой SQL база данных в состояние ожидания восстановления из-за ее повторного появления. Если вы не знаете, почему происходит эта ошибка, значит, ваш раздел базы данных, вероятно, заполнен. SQL не может открыть базу данных и не может заблокировать файл базы данных, который очень похож на базу данных в автономном режиме. Это больше похоже на то, что что-то мешает запуску сервера. В этом блоге мы собираемся обсудить, как исправить состояние ожидания восстановления SQL Server с помощью наилучших возможных методов. Прежде чем продолжить, давайте узнаем, каковы причины этой ошибки.
Причины – Состояние Ожидания восстановления базы данных SQL Server
Мгновенное Решение: Используйте средство восстановления SQL SysTools, чтобы исправить состояние ожидания восстановления в базе данных SQL Server. Это программное обеспечение может быстро устранить все ошибки, связанные с базой данных SQL. После восстановления он предоставляет возможность экспортировать данные в базу данных SQL или сценарии SQL.
Ручные способы исправить Состояние ожидания восстановления SQL Server
Как всегда можно увидеть или испытать, что ручные способы довольно сложны и опасны в использовании. Поэтому, прежде чем запустить его, убедитесь, что у вас есть резервная копия базы данных. Если вы новичок в этом, то рекомендуется, чтобы вы выполняли его под руководством технического специалиста или не выполняли его.
Способ 1
В этом ручном методе для разрешения Состояние ожидания восстановления базы данных SQL Server необходимо запустить принудительное восстановление.
1. Запустите нижеуказанные SQL-запросы.
ALTER DATABASE (Database Name) SET EMERGENCY;
ALTER DATABASE (Database Name) set single_user
DBCC CHECKDB ([Database Name], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
ALTER DATABASE (Database Name) set multi_user
2. База данных помечена как READ_ONLY в аварийном режиме, отключает ведение журнала и предоставляет доступ только системным администраторам.
3. После того, как эти шаги будут выполнены, повреждение файла будет исправлено, и база данных снова будет подключена автоматически.
Способ 2
В этом втором методе, который может разрешить состояние ожидания восстановления в базе данных SQL Server, нам нужно сначала поработать в аварийном режиме, давайте посмотрим, как.
1. Выполните следующие команды:
ALTER DATABASE (Database Name) SET EMERGENCY;
ALTER DATABASE (Database Name) set multi_user
EXEC sp_detach_ db ‘(Database Name)’
EXEC sp_attach_single_file_db @Database Name = ‘(Database Name)’, @physname = N’(mdf path)’
2. Система автоматически удалять поврежденные журналы и создаст новый.
Если вы успешно выполнили оба метода, то до сих пор проблема Состояние ожидания восстановления базы данных SQL Server может быть решена. Если нет, то рекомендуется перейти на более безопасный и лучший подход, который является автоматизированным методом.
Автоматизированное решение для исправления Состояние Ожидания восстановления SQL Server
Автоматизация гораздо лучше, чем тратить много времени и усилий на ручные методы. Для автоматического метода вы можете перейти к Восстановление базы данных SQL. Это программное обеспечение помогает восстановить поврежденный файл MDF со всеми объектами базы данных. Для выполнения процесса восстановления базы данных SQL не требуется резервное копирование. Можно легко восстановить базу данных SQL без резервного копирования. Давайте узнаем, как это работает для восстановления поврежденных файлов базы данных SQL и устранения состояние ожидания восстановления в базе данных SQL Server.
1. Установите и запустите программу восстановления SQL, затем нажмите кнопку «Открыть», чтобы загрузить файл базы данных.
2. Выберите режим быстрого или расширенного сканирования, а затем установите флажок Автоопределение версии файла SQL Server.
3. Теперь начнется процесс сканирования. После сканирования вы можете увидеть предварительный просмотр восстановленных предметов.
4. Выберите опцию «Экспорт» сверху и выберите «Экспорт данных в базу данных SQL или сценарии SQL».
5. Заполните все необходимые данные ниже и выберите экспорт только со схемой или только со схемой и данными.
6. В конце нажмите кнопку «Экспорт», чтобы восстановить файлы базы данных SQL.
Вывод
SQL Server отображает базу данных в процессе восстановления
Сегодня, после сбоя питания, одна база данных (с восстановлением: полная) показывает «In Recovery» в SSMS. Итак:
myDatabase (В режиме восстановления) (состояние базы данных: восстановление, завершение работы)
После завершения процесса восстановления в базе данных отображается имя myDatabase без «(В процессе восстановления)». Я думал, что проблема решена, но это не так.
Когда я запустил приложение, использующее эту базу данных, дополнительный текст «(В процессе восстановления)» снова появляется рядом с именем моей базы данных.
Я дождался завершения процесса восстановления, а затем я перевел базу данных в автономном режиме и вернул ее в сеть.
Я перезапустил сервер, перезапустил компьютер, и когда мое приложение запустило дополнительный текст, появится снова. В журналах SQL Server сообщение «Запуск базы данных« myDatabase »появляется несколько раз. Кажется, что база данных работает, потому что я могу вставлять данные, но состояние показывает, что что-то происходит.
Журнал сервера не показывает ничего интересного. Единственное ненормальное в том, что у меня есть 30 записей «Запуск базы данных« myDatabase ».
Я знаю, что при запуске сервера каждая база данных проходит восстановление, прежде чем она будет готова к использованию. Но в моем случае база данных поступает в сеть, а затем показывает «myDatabase (In recovery)». Если я закрою приложение, база данных переходит к Status: Normal. Это сводит меня с ума.
Я даже установил новый экземпляр SQL Server и поместил на нем старую базу данных «myDatabase». Проблема все еще происходит.
Когда я запускаю этот запрос:
Он показывает восстановление, онлайн, подозреваемый и обратно в онлайн, а затем восстановление и т. д.
Восстановление базы данных до точки сбоя — полное восстановление
В этом подразделе описывается восстановление до точки сбоя. Сведения в этом разделе относятся только к тем базам данных, которые используют модель полного восстановления или модель восстановления с неполным протоколированием.
Восстановление до точки сбоя
Создайте резервную копию заключительного фрагмента журнала базы данных, взяв за основу следующую инструкцию BACKUP :
Восстановите базу данных из ее полной резервной копии, взяв за основу следующую инструкцию RESTORE DATABASE :
Можно также восстановить базу данных из ее разностной резервной копии, взяв за основу следующую инструкцию RESTORE DATABASE:
Примените все журналы транзакций, включая резервную копию заключительного фрагмента журнала (созданную на первом шаге), указав предложение WITH NORECOVERY в инструкции RESTORE LOG:
Восстановите базу данных, выполнив следующую инструкцию RESTORE DATABASE:
Пример
Перед запуском этого примера необходимо завершить следующие подготовительные действия.
По умолчанию, база данных AdventureWorks2012 имеет простую модель восстановления. Поскольку в этой модели не поддерживается восстановление до момента сбоя, настройте AdventureWorks2012 на использование модели полного восстановления, выполнив следующую инструкцию ALTER DATABASE :
Создайте полную резервную копию базы данных при помощи следующей инструкции BACKUP:
Создайте резервную копию журналов:
В следующем примере после создания резервной копии заключительного фрагмента журнала базы данных AdventureWorks2012 производится восстановление ранее созданной резервной копии (на этом шаге предполагается, что имеется доступ к диску, на котором хранятся журналы).
Вначале создается резервная копия заключительного фрагмента журнала базы данных, которая захватывает активный журнал и оставляет базу данных в состоянии восстановления. После этого в данном примере производится восстановление резервной копии базы данных, применяется раннее созданная процедура резервного копирования журналов и создается резервная копия заключительного фрагмента журнала. Наконец, отдельным шагом производится восстановление базы данных.
По умолчанию, при обработке инструкции, выполняющей окончательное восстановление резервной копии, производится восстановление базы данных.
база MS SQL 2005 висит в режиме (Restoring. ) (Восстановление из копии. )
(6) 4 часа прошло, база со всеми логами восстановилась минут за 10.
Эта же база, но полный бэкап без логов транзакций восстанавливается и переходит в нормальное состояние.
use skip
отвечает так:
Database ‘skip’ cannot be opened. It is in the middle of a restore.
(9) SELECT ost.session_id
, DB_NAME(ISNULL(s.dbid,1)) AS dbname
, er.command
, er.percent_complete
, er.status
, osth.os_thread_id
, ost.pending_io_count
, ost.scheduler_id
, osth.creation_time
, ec.last_read
, ec.last_write
, s.text
, owt.exec_context_id
, owt.wait_duration_ms
, owt.wait_type
FROM master.sys.dm_os_tasks AS ost
JOIN master.sys.dm_os_threads AS osth ON ost.worker_address = osth.worker_address
AND ost.pending_io_count > 0 AND ost.session_id IS NOT NULL
JOIN master.sys.dm_exec_connections AS ec ON ost.session_id = ec.session_id
CROSS APPLY master.sys.dm_exec_sql_text(ec.most_recent_sql_handle) AS s
JOIN master.sys.dm_os_waiting_tasks AS owt ON ost.session_id = owt.session_id
AND owt.wait_duration_ms > 0
JOIN master.sys.dm_exec_requests AS er ON ost.session_id = er.session_id
AND er.percent_complete > 0
ORDER BY ost.session_id
GO
(12) 0 строк, с десяток колонок.
(18) почему gui не работает? Зачем он тогда нужен?
Допустим потрачу время, найду способ восстановления с помощью скриптов.
Через какой-то время забуду или в отпуск уеду, другой человек так же должен мучатся?
в gui в раздере параметры в группе окна Состояние восстановления по умолчанию выбран флаг restore with recovery
Попробую пока скриптом и отпишусь. Но мне не нравится такой способ.
(11) можно в 2-х словах сказать как правильно обеспечить возможность восстановления базы с максимальной потерей времени 2 часа?
(18) спасибо виден конец. ))
Как последнюю строку записать? Так?
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009301500.trn’ WITH FILE = 1, RECOVERY
RESTORE DATABASE [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009300425.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009300700.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009300900.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009301100.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009301300.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N’F:\BackUp_sql\МояБаза_backup_201009301500.trn’ WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N’2010-09-30T15:24:36′
GO
(21) 8Гб SQL база, 10Гб лог
через день сжатие базы данных
+(20) первая и последние строки, соответственно так:
WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
WITH FILE = 1, RECOVERY, NOUNLOAD, STATS = 10
База восстановилась, подключу её обратно к 1С-ке, проверю.
А как gui заставить не на момент времени восстанавливать, а. чтобы как в этом ручном скрипте? Неужели всегда руками подправлять?
(27) понятно, нужно будет потренироваться пока база не перешла на полную нагрузку 😉 Можно было поступить так. сделать бэкап лога транзакций, потом полный бэкап, а потом восстановить на нужное время до момента возникновения проблем.
Но попробовал глянуть на скрипт для другой базы. Логов там до конца дня, я задал момент времени 13 часов, вот последняя строка:
_backup_201009301400.trn’ WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N’2010-09-30T13:16:19′
(28) не проверял время, проверил объем. полный бэкап порядка 4Гб, все логи за весь день порядка 600Мб в сумме. А диск для бэкапов не резиновый ))
(34) не пробовал ещё ))
(29) спасибо за ссылку. давно подобное читал, но потерял ссылки. во времена 2000 серверов даже держал в голове 😉
(35) самым важным будет время восстановления после сбоя. В течение дня все сервера загружены делом, сжимать и разжимать нужно время и ресурсы.
Поэтапное восстановление (SQL Server)
Сведения в этом разделе распространяются на базы данных в выпуске Enterprise Edition SQL Server (оперативное восстановление) или Standard Edition (автономное восстановление), которые содержат несколько файлов или файловых групп, а в простой модели — лишь на файловые группы, предназначенные только для чтения.
Дополнительные сведения о поэтапном восстановлении и оптимизированных для памяти таблицах см. в разделе Поэтапное восстановление баз данных с таблицами, оптимизированными для памяти.
Поэтапное восстановление позволяет восстанавливать поэтапно базы данных, содержащие несколько файловых групп. Поэтапное восстановление включает в себя ряд последовательностей восстановления, начиная с первичной файловой группы и, в некоторых случаях, с одной или несколькими вторичными файловыми группами. Поэтапное восстановление поддерживает проверки, обеспечивающие согласованность базы данных. По завершении последовательности восстановления восстановленные файлы (если они правильны и согласуются с текущим состоянием базы данных) могут быть сразу использованы в режиме «в сети».
Поэтапное восстановление может использоваться со всеми моделями восстановления, но более эффективно — в сочетании с моделью восстановления с неполным протоколированием или моделью полного восстановления, чем с простой моделью.
Каждое поэтапное восстановление начинается с начальной последовательности восстановления, называемой последовательностью частичного восстановления. Последовательность частичного восстановления восстанавливает по меньшей мере первичную файловую группу и — в простой модели восстановления — файловые группы с режимом доступа «чтение и запись». Во время последовательности частичного восстановления вся база данных переводится в режим «вне сети». После этого этапа база данных переводится в режим «в сети», а все восстановленные файловые группы становятся доступны. Однако невосстановленные файловые группы будут оставаться вне сети и будут недоступны. Файловые группы можно восстановить и перевести в состояние вне сети позднее, с помощью восстановления файлов.
Вне зависимости от модели восстановления базы данных, последовательность частичного восстановления начинается с инструкции RESTORE DATABASE с параметром PARTIAL, которая восстанавливает полную резервную копию. Параметр PARTIAL запускает новое поэтапное восстановление, поэтому необходимо указать параметр PARTIAL только один раз в начальной инструкции последовательности частичного восстановления. В конце последовательности частичного восстановления, когда база данных переводится в режим «в сети», оставшиеся файлы переводятся в состояние «ожидание восстановления», потому что их восстановление было отложено.
Впоследствии поэтапное восстановление обычно состоит из одной или нескольких последовательностей восстановления, которые называются последовательностями восстановления файловых групп. Можно отложить выполнение последовательности восстановления файловых групп на любой период. Каждая последовательность восстановления файловых групп восстанавливает одну или более файловых групп к точке, согласованной с базой данных. Число и время следующих друг за другом последовательностей восстановления групп файлов зависит от цели восстановления, количества восстанавливаемых групп файлов в режиме «вне сети» и того, сколько групп файлов восстанавливается в одной последовательности восстановления.
Точные требования к выполнению поэтапного восстановления зависят от модели восстановления базы данных. Дополнительные сведения см. в разделе «Восстановление по простой модели восстановления» и «Поэтапное восстановление по модели полного восстановления» ниже.
Сценарии поэтапного восстановления
Все выпуски SQL Server поддерживают поэтапное восстановление вне сети. В выпуске Enterprise Edition поэтапное восстановление можно выполнять по сети или автономно. Следствия поэтапных восстановлений как в сети, так и вне сети, описаны ниже.
Сценарий поэтапного восстановления в режиме «вне сети».
В последовательности поэтапного восстановления вне сети база данных находится в режиме «в сети» после завершения последовательности частичного восстановления. Еще не восстановленные файловые группы остаются в режиме «вне сети», но по необходимости они могут быть восстановлены после перевода базы данных в этот режим.
Сценарий поэтапного восстановления в режиме «в сети».
Во время поэтапного восстановления в сети после завершения последовательности частичного восстановления база данных переводится в режим «в сети», и первичная файловая группа и все восстановленные вторичные группы становятся доступны. Еще не восстановленные файловые группы остаются в режиме «вне сети», но по необходимости они могут быть восстановлены, при этом база данных останется в режиме «в сети».
Поэтапное восстановление в сети может включать в себя отложенные транзакции. Если в сценарии поэтапного восстановления происходит восстановление только подмножества файловых групп, то транзакции в базе данных, которые зависят от групп файлов в режиме «в сети», откладываются. Это нормально, так как база данных должна быть полностью согласованной. Дополнительные сведения см. в разделе Отложенные транзакции (SQL Server).
SQL Server In-Memory OLTP сценарий поэтапного восстановления
Сведения о поэтапном восстановлении баз данных выполняющейся в памяти OLTP см. в разделе Поэтапное резервное копирование и восстановление баз данных с таблицами, оптимизированными для памяти.
Ограничения
Поэтапное восстановление по простой модели восстановления
В простой модели восстановления последовательность поэтапного восстановления должна начинаться с полного или частичного резервного копирования базы данных. Потом, если восстанавливаемая резервная копия является базовой копией для разностного копирования, восстановите последнюю разностную резервную копию.
Если во время выполнения первой последовательности частичного восстановления восстанавливается только подмножество файловых групп с разрешениями на чтение и запись, все невосстановленные файловые группы пропадают при восстановлении частично восстановленной базы данных. Устранение из частичного восстановления файловых групп, доступных для чтения и записи, применимо только в следующих случаях.
Планируется, что невосстановленные файловые группы должны стать нефункционирующими.
В точке восстановления, которую достигнет последовательность восстановления, все невосстановленные файловые группы стали доступны только для чтения, удалены или оказались нефункционирующими (во время предыдущего восстановления в последовательности частичного восстановления).
Полная резервная копия была создана, когда база данных использовала простую модель восстановления, но в точке восстановления база данных использовала модель полного восстановления. Дополнительные сведения см. в разделе «Выполнение поэтапного восстановления базы данных, модель восстановления которой была переключена с простой на полную» ниже.
Требования к поэтапному восстановлению по простой модели восстановления
В простой модели восстановления начальный этап восстанавливает по меньшей мере первичную файловую группу и все вторичные файловые группы с режимом доступа «чтение и запись». По завершении начального этапа восстановленные файлы (если они правильны и согласуются с текущим состоянием базы данных) могут быть сразу использованы в режиме «в сети».
После этого файловые группы, доступные только для чтения, могут восстанавливаться за один или несколько дополнительных этапов.
Поэтапное восстановление может осуществляться для вторичной файловой группы, доступной только для чтения, если по отношению к ней выполняются следующие условия.
Во время резервного копирования файловая группа была доступна только для чтения.
Файловая группа осталась доступной только для чтения (логически согласована с первичной файловой группой).
Чтобы выполнить поэтапное восстановление, необходимо выполнить следующие рекомендации.
Полный набор резервных копий для поэтапного восстановления базы данных с простой моделью восстановления должен содержать следующее.
Частичную или полную резервную копию базы данных, в которой содержатся первичная файловая группа и все файловые группы, доступные для чтения и записи во время резервного копирования.
Резервную копию каждого файла, доступного только для чтения.
Чтобы резервная копия файла, доступного только для чтения, была согласована с первичной файловой группой, вторичная файловая группа должна была быть доступной только для чтения с момента резервного копирования до завершения процедуры резервного копирования, содержащей первичную файловую группу. Можно применять разностные резервные копии файлов, если они были получены после того, как файловая группа стала доступной только для чтения.
Этапы поэтапного восстановления (простая модель восстановления)
Сценарий поэтапного восстановления состоит из двух этапов.
Начальный этап (восстановление первичной файловой группы и всех файловых групп, доступных для чтения и записи).
На начальном этапе выполняется частичное восстановление. Последовательность частичного восстановления восстанавливает первичную файловую группу, все вторичные файловые группы, доступные для чтения и записи, и (дополнительно) некоторые файловые группы, доступные только для чтения. Во время начального этапа вся база данных переводится в режим «вне сети». После завершения начального этапа база данных переводится в режим «в сети» и восстановленные файловые группы доступны. Однако все невосстановленные файловые группы, доступные только для чтения, остаются в режиме «вне сети».
Первая инструкция RESTORE начального этапа должна делать следующее.
Использовать частичную или полную резервную копию, в которой содержатся первичная файловая группа и все файловые группы, доступные для чтения и записи во время резервного копирования. Часто последовательность частичного восстановления начинают с восстановления из частичной резервной копии.
Задавать параметр PARTIAL, который указывает на начало поэтапного восстановления.
Параметр PARTIAL выполняет проверку безопасности на предмет возможности использования восстановленной базы данных в качестве рабочей.
Пока база данных находится в режиме «в сети», можно применить одно или несколько восстановлений файлов, чтобы восстановить файлы вне сети, доступные только для чтения, которые были доступны только для чтения во время резервного копирования. Выбор времени восстановлений файлов в сети зависит от того, когда данные необходимо перевести в режим «в сети».
Нужно ли восстанавливать данные в файл? Это зависит от следующих соображений:
Правильные файлы, доступные только для чтения, согласованные с базой данных, могут быть использованы в режиме «в сети» сразу после восстановления файлов без восстановления каких-либо данных с резервных копий.
Поврежденные и несогласованные с базой данных файлы восстанавливаются с резервной копии перед восстановлением данных по журналу транзакций.
Примеры
Поэтапное восстановление по модели полного восстановления
В модели полного восстановления или восстановления с неполным протоколированием поэтапное восстановление доступно для всех баз данных, содержащих по несколько файловых групп, и базу данных можно восстановить до любого момента времени. Последовательности восстановления поэтапного восстановления ведут себя следующим образом.
последовательностью частичного восстановления
Последовательность частичного восстановления восстанавливает первичную файловую группу и, возможно, некоторые из вторичных групп.
Первая инструкция RESTORE RESTORE DATABASE начального этапа должна делать следующее.
Задавать параметр PARTIAL. Он указывает на начало поэтапного восстановления.
Использовать любую полную резервную копию, содержащую первичную файловую группу. Часто последовательность частичного восстановления начинают с восстановления из частичной резервной копии.
Чтобы выполнить восстановление на момент времени, необходимо задать время в последовательности частичного восстановления. Каждый последующий этап последовательности восстановления должен задавать тот же самый момент времени.
Последовательности восстановления групп файлов переводят дополнительные группы файлов в режиме «в сети» до достижения согласованности с базой данных.
В выпуске Enterprise Edition любая автономная вторичная файловая группа может быть восстановлена, пока база данных остается в сети. Если данный доступный только для чтения файл не поврежден и согласуется с текущим состоянием базы данных, его восстанавливать не нужно. Дополнительные сведения см. в разделе Восстановление базы данных без восстановления данных (Transact-SQL).
Применение резервных копий журнала
Если файловая группа доступна только для чтения с момента, предшествующего созданию резервной копии файловых групп, использование резервных копий журналов не нужно, и эта группа пропускается при восстановлении файлов. Если файловая группа доступна для чтения и для записи, то с целью перевода файловой группы в состояние, соответствующее текущему файлу журнала, необходимо применить непрерывную последовательность резервных копий журнала к последнему экземпляру, полученному в результате полного или разностного восстановления. Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).
Примеры
Выполнение поэтапного восстановления базы данных, модель восстановления которой была переключена с простой на полную
Можно выполнить поэтапное восстановление базы данных, модель восстановления которой была переключена с простой на полную с момента полного частичного резервного копирования или резервного копирования базы данных. Например, рассмотрим базу данных, для которой можно выполнить следующее:
создать частичную резервную копию (backup_1);
через некоторый период времени изменить модель восстановления на полную;
создать разностную резервную копию;
начать создание резервных копий журналов.
Следовательно, верна следующая последовательность:
частичное восстановление, в котором пропущены некоторые вторичные файловые группы;
разностное восстановление, за которым следуют другие необходимые восстановления;
последующее восстановление файлов из доступных для чтения и записи вторичных файловых групп из частичной резервной копии backup_1 с параметром WITH NORECOVERY;
разностные резервные копии, следующие за любыми другими резервными копиями, восстановленными в исходной последовательности поэтапного восстановления, чтобы восстановить данные до первоначальной точки восстановления.