Как восстановить sql windows

При необходимости восстановите компьютер Windows.

После завершения восстановления системы Windows либо после запуска нового экземпляра сервера можно начать восстановление баз данных SQL.

Для восстановления баз данных SQL должен быть запущен; однако запуск SQL невозможен без наличия главной и модельной баз данных.

Восстановить главную и модельную базы данных и запустить SQL можно одним из следующих способов:

Переименуйте файлы, созданные программой Backup Exec для замены главной и модельной баз данных. После появления главной и модельной баз данных в SQL следует запустить SQL, восстановить главную базу данных с помощью опции «Автоматическое восстановление главной базы данных», а затем восстановить остальные базы данных.

Запустите утилиту Rebuild Master ( \Program Files\Microsoft SQL Server\80\Tools\Binn\rebuildm.exe для SQL 2000 или \MSSQL7\binn\rebuildm.exe для SQL 7.0) для повторного создания главной базы данных.

Утилита Rebuild Master не поддерживается в SQL 2005. Параметры настройки описаны в документации MS SQL 2005.

Заново установите SQL.

В этом разделе описана только процедура перезапуска SQL при использовании копий главной и модельной баз данных, созданных программой Backup Exec. Дополнительная информация о работе с утилитой Rebuild Master и повторной установке SQL приведена в документации по MS SQL.

В случае восстановления нового экземпляра SQL запустите операцию восстановления главной базы данных.

Как перезапустить SQL 2000, 2005 или SQL 2008 с использованием копий баз данных

Убедитесь, что имеются копии баз данных.

Копии базы данных называются master$4idr, mastlog$4idr, model$4idr и modellog$4idr и находятся в следующих каталогах:

Экземпляр SQL 2000 по умолчанию

C:\Program Files\Microsoft SQL Server\MSSQL\Data\*.*

Именованный экземпляр SQL 2000

C:\Program Files\Microsoft SQL Server\MSSQL$Instance_Name\Data\*.*

Первый экземпляр SQL 2005/2008

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\*.*

Второй экземпляр SQL 2005/2008

C:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\Data\*.*

При необходимости восстановите копии главной и модельной баз данных из наборов данных резервного копирования в исходный каталог этих баз данных.

С помощью Проводника Windows откройте каталог данных по умолчанию и удалите следующие файлы:

Переименуйте копии баз данных, восстановив исходные имена. Эти имена указаны ниже:

Имя копии базы данных

Исходное имя базы данных

Не используйте файлы, доступные только для чтения. Это приведет к сбою при запуске служб SQL.

С помощью SQL Service Control Manager запустите сервер SQL Server.

Для восстановления последних изменений в главной базе данных выполните следующие действия:

Как перезапустить SQL 7.0 с использованием копий баз данных

Убедитесь, что имеются копии баз данных.

Копиям баз данных присваиваются имена master$4idr, mastlog$4idr, model$4idr и modellog$4idr.

В установке SQL 7.0 по умолчанию базы данных находятся в каталоге C:\MSSQL7\Data.

При необходимости восстановите копии главной и модельной баз данных из наборов данных резервного копирования в исходный каталог этих баз данных.

С помощью Проводника Windows откройте каталог данных по умолчанию и удалите следующие файлы:

Переименуйте копии баз данных, восстановив исходные имена. Эти имена указаны ниже:

Имя копии базы данных

Исходное имя базы данных

Не используйте файлы, доступные только для чтения. Это приведет к сбою при запуске служб SQL.

С помощью SQL Server Service Manager запустите SQL.

Для восстановления последних изменений в главной базе данных выполните следующие действия:

Как восстановить главную базу данных

На панели навигации щелкните на стрелке рядом со значком Восстановление.

Выберите Создать задание восстановления .

На панели свойств найдите раздел «Источник» и нажмите Выбранные ресурсы .

В списке выбранных ресурсов для восстановления выберите набор данных резервного копирования, содержащий последнюю резервную копию главной базы данных.

На панели «Свойства» в разделе «Параметры» выберите Microsoft SQL .

В окне Свойства задания восстановления для SQL выберите Автоматическое восстановление главной базы данных .

Все текущие сеансы других пользователей завершаются, и сервер SQL переводится в однопользовательский режим.

При выборе этой опции можно восстановить только главную базу данных; если эта опция выбрана для какой-либо другой базы данных, произойдет сбой задания.

Если у программы Backup Exec нет доступа к записям реестра SQL HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server и HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer , может оказаться невозможным восстановление в каталог по умолчанию и будет недоступна опция «Автоматическое восстановление главной базы данных» в окне свойств задания восстановления для SQL. Для того чтобы убедиться в наличии прав доступа у программы Backup Exec, проверьте, используются ли в учетной записи права доступа администратора к системе, в которой запущен экземпляр SQL.

Выберите способ проверки целостности, выполняемой после восстановления.

Запустите задание восстановления.

После восстановления SQL перезапускается в многопользовательском режиме.

Выполните следующие действия для восстановления остальных баз данных SQL.

Как восстановить остальные базы данных SQL

На панели навигации щелкните на стрелке рядом со значком «Восстановление».

Выберите Создать задание восстановления .

На панели свойств найдите раздел «Источник» и нажмите Выбранные ресурсы .

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

При этом не выбирайте главную базу данных для восстановления.

В случае восстановления баз данных SQL из резервной копии группы файлов следует помнить о следующих условиях:

На панели «Свойства» в разделе «Параметры» выберите Microsoft SQL .

Выберите параметр Оставить базу данных в рабочем состоянии ; не восстанавливать другие журналы транзакций или дифференциальные резервные копии .

Выберите опцию Заменить существующую базу данных .

В поле «Проверка целостности после восстановления базы данных» выберите опцию Полная проверка, включая индексы .

Запустите задание восстановления или выберите другие опции на панели «Свойства».

После успешного завершения всех операций восстановления восстановление баз данных SQL завершено.

После завершения восстановления настоятельно рекомендуется выполнить полное резервное копирование баз данных при первой возможности.

Восстановление служебных баз SQL сервера

Материал из Info

В процессе работы Microsoft SQL Server 2005/2008/2012/2014/2017 из ресурсов в основном полагается на память и жёсткий диск. При внештатной ситуации со службой сервера, данные в памяти могут быть потеряны. То же самое касается и самих баз — при наличии проблемы чтении-записи на диск, база может быть отмечена как подозрительная (suspected). Чаще всего слетает индекс (минимальный урон) или одна последняя транзакция, которая не записана на диск,- делается roll forward при возможности или roll back при невозможности зафиксировать(применить) транзакцию (средний урон, в зависимости от объёма транзакции). В случае с потерянными данными в индексе, есть возможность их восстановить методом реиндексации из информации соответствующей таблицы, индекс которой нарушен.

Содержание

Причины

Причина нарушения целостности данных базы (обычно ошибка сопровождается аббревиатурой CRC) является отказ в системе чтения-записи жёсткого диска (I/O).
К примеру:

• Битые сектора жёсткого диска, с которых нельзя считать данные;
• Потеря питания жёсткого диска — скачёк напряжения или, наоборот, полная его потеря;
• Вмешательство внешних факторов — вирус, торрент-клиент, который занимает 100% ресурсов диска;
• Другие ресурсоёмкие задачи, которые мешают свободному функционированию важной службы Microsoft SQL Server: виртуальные машины, рендеринг/конвертирование видео, запись потока с видеокамер.

Системные базы

Возвращение пользовательской базы к нормальному состоянию описано в соответствующей статье Исправление базы данных.
А что делать, если база системная? Системными базами являются базы, которые создаются с установкой Microsoft SQL Server и содержат служебные данные: master, model, msdb, tempdb и, при наличии репликации,- distribution. Выход из строя одной из системных баз влечёт за собой отказ в полноценной работе службы или её запуске.
База master не переводится в режим SINGLE_USER/MULTI_USER, что автоматически не позволит её восстановить при сбое.
База tempdb пересоздаётся при каждой перезагрузке службы.
База model может быть восстановлена только запросами из командной строки OSQL/SQLCMD.
Базы msdb и distribution могут быть восстановлены как и пользовательские.

Восстановление базы master

При установке Microsoft SQL Server в папке C:\Program Files\Microsoft SQL Server\[instance]\MSSQL\Binn\Templates создаются файловые шаблоны баз. Данные шаблоны являются минимально настроенными и позволяют частично или полностью восстановить работоспособность сервера в полевых условиях без необходимости долгого удаления и установки сервера в целом. Здесь и далее [instance] = наименование установленной инстанции в корневой папке Microsoft SQL Server, например MSSQL11.MSSQLSERVER.

Процедура восстановления базы master:

• Заменить базу master, заменив файлы master.mdf и mastlog.ldf из ранее указанной папки Templates.
• Запустить командную строку cmd с правами администратора (далее Командная строка №1).
• Перейти в «C:\Program Files\Microsoft SQL Server\[instance]\MSSQL\Binn\».
• Запустить sqlservr.exe с командным параметром -m. Данный параметр заставит сервер запуститься в монопольном режиме.
• Поcле запуска будут выполняться скрипты обновления базы и настройки сервера.
• При появлении следующей записи необходимо приступать к корректировке реальных путей к файлам

• Для корректировки сервер должен быть запущен с параметрами -m -t3608. Параметр запрещает автоматический запуск SQL Server и восстановление любых баз данных, кроме базы данных master. Если инициируются действия, для которых требуется tempdb, то база model восстанавливается, и создается tempdb. Другие базы данных будут запущены и восстановлены при открытии. Параметр может быть использован и для перемещения системных баз данных. Внимание: Данный параметр должен быть использован только при условии выполнения всех предыдущих пунктов!
• После старта в режиме «изоляции», производится корректировка путей и создание пользователя. Для этого необходимо запустить новый экземпляр командной строки с правами администратора (далее Командная строка №2), подключиться к серверу с помощью команды SQLCMD -E и выполнить следующие скрипты одновременно или по очереди, предварительно подставив свои значения:

• Переключиться в Командную строку №1 и опять запустить сервер sqlservr.exe. Будет выполнен набор служебных скриптов, которые настроят базу master.
• После запуска сервера можно выполнять attach пользовательской базы Microinvest, вне зависимости от того была база в репликации или нет.
• При необходимости можно установить имя сервера запросом в Management Studio, после чего выполнить перезагрузку службы

Если в процессе сервер ругается сообщением Msg 18461, Level 14, State 1, Server PCNAME, Line 1. Login failed for user ‘PCNAME\USERNAME’. Reason: Server is in single user mode. Only one administrator can connect at this time. , то добавьте параметр -t902 к старту сервера. Этот параметр предотвращает запуск скрипта обновления базы. Дл

Восстановление базы msdb

• Заменить базу msdb, заменив файлы MSDBData.mdf и MSDBLog.ldf из ранее указанной папки Templates.
• Запустить командную строку cmd с правами администратора.
• Перейти в «C:\Program Files\Microsoft SQL Server\[instance]\MSSQL\Binn\».
• Запустить sqlservr.exe с командным параметром -m. Данный параметр заставит сервер запуститься в монопольном режиме.
• Поcле запуска будут выполняться скрипты обновления базы и настройки сервера.
• После этого понадобится сделать Attach для всех баз, которые были на сервере ранее

Восстановление базы model

• Заменить базу model, заменив файлы model.mdf и modellog.ldf из ранее указанной папки Templates.
• Запустить командную строку cmd с правами администратора.
• Перейти в «C:\Program Files\Microsoft SQL Server\[instance]\MSSQL\Binn\».
• Запустить sqlservr.exe с командным параметром -m. Данный параметр заставит сервер запуститься в монопольном режиме.
• Поcле запуска будут выполняться скрипты обновления базы и настройки сервера.
• После этого понадобится сделать Attach для всех баз, которые были на сервере ранее

Предотвращение проблем

В предотвращении потери времени на восстановление работы остановившегося сервера рекомендуется заранее предпринять следующие действия:

1. Выполнять плановую поддержку SQL серверов
2. Установить источник бесперебойного питания и/или стабилизатор напряжения.
3. Создать планы обслуживания баз: Server — Management — Maintenance plans (при наличии SQL версии Standard и выше).
4. Выполнять периодически резервные копии системных баз как bak или файловая копия.

Выводы

Данная процедура восстановления базы master занимает на разных серверах от 3 до 5 минут. Удаление и установка нового сервера займёт многократно большее времени. При нежелании или отсутствии времени возиться с восстановлением сервера вы можете оплатить удаленное подключение наших специалистов Microinvest, которые всё сделают за вас.
Восстановление базы не потребуется, если у вас есть все факторы, чтобы этого избежать, однако если всё же пришлось восстановить и запустить сервер по вышеописанной технологии, примите меры на будущее. Также важно знать, что кодовая страница (collation) стандартной базы master устанавливает для целого сервера SQL_Latin1_General_CP1_CI_AI, что отличается от рекомендуемой Microinvest Cyrillic_General_CI_AS

Выполнение полного восстановления базы данных (модель полного восстановления) Complete Database Restores (Full Recovery Model)

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions)

Задача полного восстановления — восстановить базу данных целиком. In a complete database restore, the goal is to restore the whole database. В период восстановления база данных находится вне сети. The whole database is offline for the duration of the restore. Прежде чем какая-либо часть базы данных перейдет в режим «в сети», все данные восстанавливаются до точки согласования, в которой все части базы данных находятся в одном и том же моменте времени и в которой нет незафиксированных транзакций. Before any part of the database can come online, all data is recovered to a consistent point in which all parts of the database are at the same point in time and no uncommitted transactions exist.

При работе в режиме модели полного восстановления после восстановления резервных копий данных необходимо восстановить все последующие резервные копии журнала транзакций, а затем саму базу данных. Under the full recovery model, after you restore your data backup or backups, you must restore all subsequent transaction log backups and then recover the database. Базу данных можно восстановить до определенной точки восстановления в одной из этих резервных копий журналов. You can restore a database to a specific recovery point within one of these log backups. Этой точкой восстановления может быть заданная дата и время, помеченная транзакция или регистрационный номер транзакции в журнале (LSN). The recovery point can be a specific date and time, a marked transaction, or a log sequence number (LSN).

При восстановлении базы данных, в особенности при использовании модели полного восстановления или модели восстановления с неполным протоколированием, следует использовать одну последовательность восстановления. When restoring a database, particularly under the full recovery model or bulk-logged recovery model, you should use a single restore sequence. Последовательность восстановления состоит из одной или нескольких операций восстановления, которые выполняют перемещение данных в одном или нескольких этапах восстановления. A restore sequence consists of one or more restore operations that move data through one or more of the phases of restore.

Ненадежные источники Untrusted sources

Не рекомендуется подключать или восстанавливать базы данных, полученные из неизвестных или ненадежных источников. We recommend that you do not attach or restore databases from unknown or untrusted sources. В этих базах данных может содержаться вредоносный код, вызывающий выполнение непредусмотренных инструкций Transact-SQL Transact-SQL или появление ошибок путем изменения схемы или физической структуры базы данных. These databases could contain malicious code that might execute unintended Transact-SQL Transact-SQL code or cause errors by modifying the schema or the physical database structure. Перед тем как использовать базу данных, полученную из ненадежного источника, выполните для нее инструкцию DBCC CHECKDB на тестовом сервере. Before you use a database from an unknown or untrusted source, run DBCC CHECKDB on the database on a non-production server. Также изучите содержащийся в ней код, написанный пользователем: хранимые процедуры и другой пользовательский код. Also, examine the user-written code in the database, such as stored procedures or other user-defined code.

Резервные копии из предыдущих версий Backups from earlier versions

Сведения о поддержке резервных копий более ранних версий SQL Server SQL Server см. в подразделе «Поддержка совместимости» раздела RESTORE (Transact-SQL). For information about support for backups from earlier versions of SQL Server SQL Server , see the «Compatibility Support» section of RESTORE (Transact-SQL).

Восстановление базы данных до точки сбоя Restoring a Database to the Point of Failure

Обычно восстановление базы данных до точки сбоя включает следующие основные шаги: Typically, recovering a database to the point of failure involves the following basic steps:

Произведите резервное копирование активного журнала транзакций (также известного как заключительный фрагмент журнала). Back up the active transaction log (known as the tail of the log). На этом шаге создается резервная копия заключительного фрагмента журнала. This creates a tail-log backup. Если активный журнал транзакций недоступен, все транзакции этой части журнала будут потеряны. If the active transaction log is unavailable, all transactions in that part of the log are lost.

При использовании модели восстановления с неполным протоколированием для создания резервной копии для журнала, содержащего операции с неполным протоколированием, требуется доступ ко всем файлам базы данных. Under the bulk-logged recovery model, backing up any log that contains bulk-logged operations requires access to all data files in the database. Если файлы данных недоступны, резервное копирование журнала транзакций невозможно. If the data files cannot be accessed, the transaction log cannot be backed up. В этом случае необходимо вручную внести все изменения, произошедшие с момента последнего резервного копирования журнала. In that case, you have to manually redo all changes that were made since the most recent log backup.

Восстановите самую последнюю полную резервную копию базы данных без восстановления самой базы данных (RESTORE DATABASE имя_базы_данных FROM устройство_резервного_копирования WITH NORECOVERY). Restore the most recent full database backup without recovering the database (RESTORE DATABASE database_name FROM backup_device WITH NORECOVERY).

Если существуют разностные резервные копии, восстановите самую последнюю из них без восстановления базы данных (RESTORE DATABASE имя_базы_данных FROM устройство_разностного_резервного_копирования WITH NORECOVERY). If differential backups exist, restore the most recent one without recovering the database (RESTORE DATABASE database_name FROM differential_backup_device WITH NORECOVERY).

При восстановлении последней разностной резервной копии уменьшается число подлежащих восстановлению резервных копий журнала. Restoring the most recent differential backup reduces the number of log backups that must be restored.

Начиная с первой резервной копии журнала транзакций, созданной после только что восстановленной резервной копии, последовательно восстановите журналы с параметром NORECOVERY. Starting with the first transaction log backup that was created after the backup you just restored, restore the logs in sequence with NORECOVERY.

Восстановите базу данных (RESTORE DATABASE имя_базы_данных WITH RECOVERY). Recover the database (RESTORE DATABASE database_name WITH RECOVERY). Этот шаг можно объединить с восстановлением последней резервной копии журнала. Alternatively, this step can be combined with restoring the last log backup.

На следующем рисунке показана эта последовательность восстановления. The following illustration shows this restore sequence. После сбоя (1) создается резервная копия заключительного фрагмента журнала (2). After a failure occurs (1), a tail-log backup is created (2). Затем база данных восстанавливается до точки сбоя. Next, the database is restored to the point of the failure. Это включает восстановление резервной копии базы данных, последующей разностной резервной копии и всех резервных копий журналов, сохраненных после разностной резервной копии, в том числе резервной копии заключительного фрагмента журнала. This involves restoring a database backup, a subsequent differential backup, and every log backup taken after the differential backup, including the tail-log backup.

Если база данных восстанавливается на другой экземпляр сервера, см. раздел Копирование баз данных путем создания и восстановления резервных копий. When you restore a database backup onto a different server instance, see Copy Databases with Backup and Restore.

Базовый синтаксис инструкции Transact-SQL RESTORE Basic Transact-SQL RESTORE Syntax

Базовый синтаксис инструкции RESTORE Transact-SQL Transact-SQL для последовательности восстановления в предыдущей иллюстрации выглядит следующим образом: The basic RESTORE Transact-SQL Transact-SQL syntax for the restore sequence in the preceding illustration is as follows:

RESTORE DATABASE база_данных FROM full database backup WITH NORECOVERY; RESTORE DATABASE database FROM full database backup WITH NORECOVERY;

RESTORE DATABASE база_данных FROM полная_разностная_резервная_копия WITH NORECOVERY; RESTORE DATABASE database FROM full_differential_backup WITH NORECOVERY;

RESTORE LOG база_данных FROM резервная_копия_журнала WITH NORECOVERY; RESTORE LOG database FROM log_backup WITH NORECOVERY;

Повторите шаг по восстановлению журнала из резервной копии для каждой резервной копии журнала. Repeat this restore-log step for each additional log backup.

RESTORE DATABASE база_данных WITH RECOVERY; RESTORE DATABASE database WITH RECOVERY;

Пример. Восстановление до точки сбоя (Transact-SQL) Example: Recovering to the Point of Failure (Transact-SQL)

В следующем примере Transact-SQL Transact-SQL показаны важные параметры в последовательности восстановления для восстановления базы данных до точки сбоя. The following Transact-SQL Transact-SQL example shows the essential options in a restore sequence that restores the database to the point of failure. На этом шаге создается резервная копия заключительного фрагмента журнала базы данных. The example creates a tail-log backup of the database. Далее в примере восстанавливается полная резервная копия базы данных и резервная копия журнала, а затем восстанавливается резервная копия заключительного фрагмента журнала. Next, the example restores a full database backup and log backup and then restores the tail-log backup. В этом примере показан отдельный последний шаг восстановления базы данных. The example recovers the database in a separate, final step.

В примере используется резервная копия базы данных и резервная копия журнала, созданные в подразделе «Использование резервных копий при модели полного восстановления» раздела Полные резервные копии баз данных (SQL Server). This example uses a database backup and log backup that is created in the «Using Database Backups Under the Full Recovery Model» section in Full Database Backups (SQL Server). До создания резервной копии базы данных образец базы данных AdventureWorks2012 AdventureWorks2012 был настроен на использование модели полного восстановления. Before the database backup, the AdventureWorks2012 AdventureWorks2012 sample database was set to use the full recovery model.

Восстановление базы данных на момент времени в пределах резервной копии журнала Restoring a Database to a Point Within a Log Backup

При работе в режиме полного восстановления можно провести полное восстановление базы данных до состояния на момент времени, до помеченной транзакции или до номера LSN в резервной копии журнала. Under the full recovery model, a complete database restore can usually be recovered to a point of time, a marked transaction, or an LSN within a log backup. Однако в модели восстановления с неполным протоколированием, если в резервной копии журнала содержатся изменения с неполным протоколированием, восстановление до момента времени невозможно. However, under the bulk-logged recovery model, if the log backup contains bulk-logged changes, point-in-time recovery is not possible.

Образцы сценариев восстановления на определенный момент времени Sample Point-in-Time Restore Scenarios

В следующем примере предполагается использование критически важной системы баз данных, в которой полная резервная копия баз данных создается ежедневно в полночь, разностная резервная копия — каждый час, с понедельника до субботы. Резервные копии журнала создаются каждые 10 минут в течение дня. The following example assumes a mission-critical database system for which a full database backup is created daily at midnight, a differential database backup is created on the hour, Monday through Saturday, and transaction log backups are created every 10 minutes throughout the day. Чтобы восстановить базу данных до ее состояния на 05:19 To restore the database to the state is was in at 5:19 A.M. среды, необходимо выполнить следующие действия. Wednesday, do the following:

Восстановить полную резервную копию базы данных, полученную в полночь вторника. Restore the full database backup that was created Tuesday at midnight.

Восстановление разностной резервной копии базы данных, созданной в 5:00 Restore the differential database backup that was created at 5:00 A.M. в среду. on Wednesday.

Применение резервной копии журнала транзакций, созданной в 5:10 Apply the transaction log backup that was created at 5:10 A.M. в среду. on Wednesday.

Применение резервной копии журнала транзакций, созданной в 5:20 Apply the transaction log backup that was created 5:20 A.M. в среду, с указанием того, что процесс восстановления относится лишь к происшедшим до 5:19 транзакциям. on Wednesday, specifying that the recovery process applies only to transactions that occurred before 5:19 A.M.

В случае если нужно восстановить базу данных до ее состояния на 03:04 Alternatively, if the database needs to be restored to its state at 3:04 A.M. четверга, но разностная резервная копия базы данных, созданная в 3:00 Thursday, but the differential database backup that was created at 3:00 A.M. четверга недоступна, выполните следующие действия. Thursday is unavailable, do the following:

Восстановить резервную копию базы данных, полученную в полночь в среду. Restore the database backup that was created Wednesday at midnight.

Восстановление разностной резервной копии базы данных, созданной в 2:00 Restore the differential database backup that was created at 2:00 A.M. в четверг. on Thursday.

Применение всех резервных копий журнала транзакций, созданных за время от 2:10 Apply all the transaction log backups created from 2:10 A.M. до 3:00 to 3:00 A.M. в четверг. on Thursday.

Применение резервной копии журнала транзакций, созданной в 3:10 Apply the transaction log backup that was created at 3:10 A.M. в четверг с остановкой процесса восстановления на момент 3:04. on Thursday, stopping the recovery process at 3:04 A.M.

Связанные задачи Related Tasks

Восстановление полной резервной копии базы данных To restore a full database backup

Восстановление разностной резервной копии базы данных To restore a differential database backup

Восстановление резервной копии журнала транзакций To restore a transaction log backup

Восстановление резервной копии с помощью управляющих объектов SQL Server (SMO) To restore a backup by using SQL Server Management Objects (SMO)

Восстановление базы данных до точки в резервной копии журнала To restore a database to a point within a log backup