Як відновити SQL Server

Як відновити SQL Server: найкращі методи та інструкція з відновлення бази даних

SQL Server є одним з найпопулярніших рішень для зберігання та керування базами даних. Однак, навіть найнадійніша система може потребувати відновлення відновлення. SQL Server і надамо корисні поради та інструкції.

Першим кроком при відновленні SQL Server є створення резервної копії бази даних. Резервні копії дають змогу зберегти дані в разі збою або втрати інформації.

Після створення резервної копії ви можете приступити до відновлення SQL Server. .

Важливо пам'ятати, що відновлення SQL Server може бути складним процесом, який потребує певних навичок і знань. даних.

Підготовка до відновлення SQL Server

Відновлення SQL Server може бути складним завданням, яке потребує уважності та акуратності.Правильна підготовка перед початком відновлення може значно полегшити роботу і допомогти уникнути втрати даних. У цьому розділі ми розглянемо кілька важливих кроків, які потрібно виконати перед початком відновлення SQL Server.

Створіть резервні копії даних та журналів транзакцій: Перш ніж приступити до відновлення SQL Server, необхідно переконатися, що у вас є актуальні резервні копії даних та журналів транзакцій. Це допоможе відновити базу даних до останнього стану та мінімізувати втрату даних.
Визначте режим відновлення: Залежно від ситуації та вимог до відновлення необхідно визначити режим відновлення SQL Server. Режими включають повне відновлення, просте відновлення та змішане відновлення.
Перевірте стан журналу транзакцій: Журнал транзакцій відіграє у відновленні SQL Server. Переконайтеся, що стан журналу транзакцій відповідає вашим очікуванням та вимогам.
Встановіть необхідні компоненти: Перед початком відновлення SQL Server переконайтеся, що у вас встановлені необхідні програмні компоненти, такі як SQL Server Management Studio (SSMS) та SQL Server Database Engine.
Визначте порядок відновлення: Якщо вам необхідно відновити декілька баз даних, визначте порядок їх відновлення. Врахуйте залежності та вимоги кожної бази даних.

Правильна підготовка перед початком відновлення SQL Server допоможе вам впоратися із завданням ефективно та мінімізувати втрату даних. Не поспішайте і дотримуйтесь інструкцій, щоб досягти успішного відновлення SQL Server.

Резервне копіювання бази даних SQL Server

При плануванні резервного копіювання бази даних необхідно враховувати такі аспекти:

1. Частота створення резервної копії

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

2. Методи резервного копіювання

SQL Server надає кілька методів резервного копіювання, включаючи повне, диференціальне та журнальне копіювання. Повне копіювання резервує всю базу даних, тоді як диференціальне копіювання зберігає лише змінені дані з останнього повного копіювання. Журнальне копіювання резервує лише зміни після останнього повного або диференціального копіювання.

3. Місце зберігання резервних копій

Виберіть місце для зберігання резервних копій бази даних SQL Server. Це може бути локальний або мережевий диск, віддалений сервер або хмарне сховище. Переконайтеся, що вибране місце має достатній обсяг зберігання та безпеку даних.

Для створення резервної копії бази даних SQL Server можна використовувати SQL Server Management Studio, команди T-SQL або спеціалізовані програми резервного копіювання. Переважний метод вибирається на основі вимог та рівня складності кожної конкретної ситуації.

Важливо пам'ятати, що резервне копіювання бази даних SQL Server - це лише одна сторона безпеки даних.Необхідно також регулярно перевіряти та тестувати процедури відновлення, щоб бути впевненим, що у разі потреби можна буде успішно відновити дані.

Вибір методу відновлення бази даних

При відновленні бази даних SQL Server важливо вибрати відповідний метод, який дозволить успішно відновити дані та мінімізувати втрати інформації. Залежно від ситуації, ви можете застосувати один із таких методів відновлення:

Повне відновлення з резервної копії (FULL) - Даний метод дозволяє відновити базу даних, використовуючи останню повну резервну копію, а також всі доступні диференціальні та подальші файли журналу транзакцій. Цей метод дозволяє відновити базу даних точного моменту збою.
Диференційне відновлення (DIFFERENTIAL) - за допомогою цього можна відновити базу даних, використовуючи останню повну резервну копію і останній доступний диференціальний файл резервного копіювання. Цей метод дозволяє заощаджувати час, оскільки відновлюються лише зміни після повної резервної копії.
Точкове відновлення (POINT-IN-TIME) - Ця опція дозволяє відновити базу даних до конкретного моменту часу. Для цього необхідно мати повну резервну копію бази даних, а також усі подальші файли журналу транзакцій. Точкове відновлення корисно за необхідності відновити лише певні дані або при виправленні помилок, допущених у певний момент часу.

При виборі методу відновлення бази даних SQL Server слід враховувати як типи резервних копій, а й доступний час відновлення, обсяг даних, ступінь критичності інформації, і навіть додаткові вимоги до відновлення.

Відновлення бази даних у новому розташуванні (SQL Server)

У цій статті описано, як відновити базу даних SQL Server на нове розташування та за необхідності перейменувати базу даних на SQL Server за допомогою SQL Server Management Studio (SSMS) або Transact-SQL. Ця процедура дозволяє перемістити базу даних новим шляхом каталогу або створити копію бази даних на тому ж чи іншому екземплярі сервера.

Підготовка до роботи

обмеження

При відновленні бази даних із повної резервної копії системний адміністратор має бути єдиним користувачем, який працює з базою даних.

Необхідні компоненти

Модель відновлення з повним резервним копіюванням або з неповним протоколюванням регламентує, що перед відновленням бази даних необхідно створити резервну копію активного журналу транзакцій. Для отримання додаткових відомостей див. у розділі Створення резервної копії журналу транзакцій (SQL Server).
Щоб відновити зашифровану базу даних, необхідно мати доступ до сертифіката або асиметричного ключа, використовується для шифрування бази даних! Без цього сертифіката або асиметричного ключа неможливо відновити базу даних. Цей сертифікат повинен зберігатися для шифрування ключа шифрування бази даних, поки не потрібно резервне копіювання. Для отримання додаткових відомостей див. у статті SQL Server Certificates and Asymmetric Keys.

Безпека

З метою безпеки рекомендується не підключати чи відновлювати бази даних із невідомих чи ненадійних джерел. У цих базах даних може бути шкідливий код, що викликає виконання непередбачених інструкцій Transact-SQL або поява помилок через зміну схеми або фізичної структури бази даних. Перед тим як використовувати базу даних, отриману з невідомого або ненадійного джерела, виконайте на тестовому сервері інструкцію DBCC CHECKDB для цієї бази даних, а також вивчіть вихідний код у базі даних, наприклад процедури, що зберігаються, і інший користувальницький код.

Дозволи

Якщо відновлена база даних не існує, користувач повинен мати роздільну здатність CREATE DATABASE, щоб мати можливість виконати RESTORE. Якщо база даних існує, дозволи на виконання інструкції RESTORE за умовчанням надані членам визначених ролей сервера sysadmin і dbcreator , а також власнику бази даних (dbo).

Дозволи на виконання інструкції RESTORE надаються ролям, у яких дані про членство завжди доступні серверу. Так як членство в визначеній ролі бази даних можна перевірити лише в тому випадку, якщо база даних доступна і не пошкоджена, що не завжди відбувається при виконанні RESTORE, члени зумовленої ролі бази даних db_owner не мають дозволів RESTORE.

Відновлення бази даних у нову папку та за необхідності її перейменування за допомогою SSMS

Підключіться до відповідного екземпляра SQL Server ядро СУБД, а потім в браузер об'єктів виберіть ім'я сервера, щоб розгорнути дерево сервера.
Клацніть правою кнопкою миші бази даних та виберіть пункт "Відновити базу даних". Відкриється діалогове вікно Відновлення бази даних .
Щоб вказати джерело та розташування резервних наборів даних, що відновлюються, використовуйте сторінку Загальні , розділ Джерело . Виберіть із наведеного нижче.
- База даних Виберіть зі списку базу даних для відновлення. Цей список містить лише бази даних, резервне копіювання яких було виконано відповідно до журналу резервного копіювання msdb .

Якщо резервну копію було отримано з іншого сервера, на цільовому сервері не буде журналу резервного копіювання для вказаної бази даних. У цьому випадку клацніть пункт Пристрій , щоб вручну вказати файл або пристрій відновлення.

Пристрій Натисніть кнопку огляду (. ), щоб відкрити діалогове вікно "Вибір пристроїв резервного копіювання". У вікні Тип носія резервної копії виберіть один із перелічених типів пристроїв. Щоб вибрати один або кілька пристроїв для резервного поля мультимедіа копіювання, натисніть кнопку "Додати". Після додавання пристроїв до списку носіїв резервного копіювання натисніть кнопку "ОК", щоб повернутися на сторінку "Загальні". У списку Джерело > Пристрій > База даних виберіть назву бази даних, яку потрібно відновити. Примітка. Цей список доступний, лише якщо вибрано Пристрій . Виберіть лише бази даних, резервні копії яких доступні на вибраному пристрої.

Відновлення бази даних у нову папку та за необхідності її перейменування за допомогою T-SQL

За потреби визначте логічні та фізичні імена файлів у резервному наборі, що містить повну резервну копію бази даних, яку потрібно відновити. Ця інструкція повертає список файлів бази даних та журналу, які містяться у резервному наборі даних. Базовий синтаксис: RESTORE FILELISTONLY FROM WITH FILE = BACKUP_SET_FILE_NUMBER У цьому випадку аргумент номер_файла_резервного_набору вказує позицію резервної копії у наборі носіїв. Положення резервного набору можна отримати за допомогою інструкції RESTORE HEADERONLY. Для отримання додаткових відомостей див. у розділі "Вказівка резервного набору даних". Ця інструкція також підтримує кілька варіантів WITH. Для отримання додаткових відомостей див. у розділі Інструкція RESTORE FILELISTONLY (Transact-SQL).
Для відновлення повної резервної копії бази даних використовуйте інструкцію RESTORE DATABASE.За промовчанням файли даних та журналів відновлюються у вихідних розташуваннях. Щоб перемістити базу даних, використовуйте параметр MOVE для переміщення кожного з файлів бази даних та запобігання конфліктам з наявними файлами.

Базовий синтаксис Transact-SQL для відновлення бази даних у новому розташуванні та нове ім'я:

RESTORE DATABASE *new_database_name* FROM *backup_device* [ . *n* ] [ WITH < [ **RECOVERY** | NORECOVERY ] [ , ] [ FILE =< *backup_set_file_number* | @*backup_set_file_number* >] [ , ] MOVE '*logical_file_name_in_backup*' TO '*operating_system_file_name*' [ . *n*] > ;

Під час підготовки до переміщення бази даних на інший диск необхідно перевірити наявність достатнього місця та визначити потенційні конфлікти з наявними файлами. Це включає використання інструкції RESTORE VERIFYONLY , яка вказує на ті ж параметри MOVE, які планується використовувати в інструкції RESTORE DATABASE.

У наступній таблиці аргументи інструкції RESTORE описані стосовно відновлення бази даних у новому місці. Додаткові відомості про ці аргументи див. у розділі RESTORE (Transact-SQL).

нове_ім'я_бази_даних
Нове ім'я бази даних.

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

backup_device [ ,. n ]
Вказує список з роздільними комами від 1 до 64 пристроїв резервного копіювання, які використовуються для відновлення бази даних із резервної копії. Можна вказати як фізичний пристрій резервного копіювання, так і відповідний логічний пристрій, якщо його визначено. Для вказівки фізичного пристрою резервного копіювання використовуйте DISK або TAPE.

< DISK | TAPE >=ім'я_фізичного_пристрою_резервного_копіювання

< RECOVERY | NORECOVERY >
Якщо у базі даних використовується модель повного відновлення, може виникнути потреба застосувати резервні копії журналів транзакцій після відновлення бази даних. У такому разі вкажіть параметр NORECOVERY.

В іншому випадку використовуйте параметр RECOVERY, який застосовується за умовчанням.

FILE =< номер_файла_резервного_набору | @номер_файла_резервного_набору >
Ідентифікує резервний набір даних для відновлення. Наприклад, аргумент номер_файла_резервного_набору , рівний 1 вказує перший резервний набір даних на носії даних резервних копій, а аргумент номер_файла_резервного_набору , рівний 2 , Вказує другий резервний набір даних. Значення номер_файла_резервного_набору резервного набору даних можна отримати за допомогою інструкції RESTORE HEADERONLY.

Якщо цей параметр не вказано, за замовчуванням використовується перший резервний набір резервного копіювання.

Додаткові відомості див. у розділі "Вказівка резервного набору даних" в аргументах RESTORE (Transact-SQL).

MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ,. n ]
Показує, що файл даних або журналу вказаний параметром логічне_ім'я_файлу_в_резервній_копії , слід відновити з копії у місці, вказаному параметром ім'я_файла_в_операційній_системі. Вкажіть інструкцію MOVE для кожного логічного файлу, який потрібно відновити із резервного набору даних у новому місці.

Варіант	Опис
логічне_ім'я_файлу_в_резервній_копії	Вказує логічне ім'я файлу даних або журналу резервного набору даних. Логічне ім'я файлу даних або журналу в резервному наборі даних відповідає його логічному імені базі даних на момент створення резервного набору даних.

Варіант

Опис

логічне_ім'я_файлу_в_резервній_копії

Вказує логічне ім'я файлу даних або журналу резервного набору даних. Логічне ім'я файлу даних або журналу в резервному наборі даних відповідає його логічному імені базі даних на момент створення резервного набору даних.

Приклад (Transact-SQL)

У наведеному нижче прикладі створюється база даних MyAdvWorks за допомогою відновлення резервної копії зразка бази даних AdventureWorks2022 , яка містить два файли: AdventureWorks2022 _Data і AdventureWorks2022 _Log. У цій базі даних використовується проста модель відновлення. База даних AdventureWorks2022 вже існує на екземплярі сервера, тому файли резервної копії повинні бути відновлені в новому місці. Кількість та імена відновлюваних файлів бази даних можна визначити за допомогою інструкції RESTORE FILELISTONLY. Резервна копія бази даних є першим резервним набором даних на пристрої резервного копіювання.

У прикладах резервного копіювання та відновлення журналу транзакцій із резервної копії, включаючи відновлення на момент часу, використовується база даних MyAdvWorks_FullRM , яка створюється з бази даних AdventureWorks2022 , як у прикладі з базою даних MyAdvWorks . Однак результуюча база даних MyAdvWorks_FullRM повинна бути змінена, щоб використовувати повну модель відновлення за допомогою наступної інструкції Transact-SQL: ALTER DATABASE SET RECOVERY FULL.

USE master; GO -- Перший визначить номер і назву файлів в backup. -- AdventureWorks2022_Backup є ім'ям backup device. RESTORE FILELISTONLY FROM AdventureWorks2022_Backup; -- Restore the files for MyAdvWorks. RESTORE DATABASE MyAdvWorks FROM AdventureWorks2022_Backup WITH RECOVERY, MOVE 'AdventureWorks2022_Data' TO 'D:\MyData\MyAdvWorks_Data.mdf', MOVE 'AdventureWorks2022_Log 'F:\MyLog\MyAdvWorks_Log.ldf'; GO

Пов'язані завдання

Див. також

Резервне копіювання та відновлення бази даних у MS SQL Server

У цій статті ми розглянемо, як настроїти резервне копіювання баз даних у Microsoft SQL Server, покажемо, як відновити базу даних із резервної копії за допомогою SQL Server Management Studio та Transact-SQL. Перша частина статті присвячена теоретичним аспектам резервного копіювання в SQL, у другій прикладі ми покажемо, як налаштувати регулярне резервне копіювання бази даних MS SQL за допомогою плану обслуговування та відновити базу з резервної копії на прикладі встановленого Microsoft SQL Server 2019 .

Вимоги до плану резервного копіювання баз даних SQL Server встановлює бізнес з огляду на кілька критеріїв:

Допустимий обсяг втрачених даних (за останній день/годину/хвилину/секунду);
Вимоги до дискового простору та його вартість;
Витрати ресурсів сервера резервного копіювання.

Слід розуміти, що за допомогою механізмів резервного копіювання неможливо досягти резервування даних у реальному часі. Для цієї мети використовуються інші технології високої доступності SQL Server - групи доступності Always On, дзеркало баз даних або реплікація.

Типи резервного копіювання SQL Server

Повне (Full Backup)

Повне резервне копіювання робить копію всієї бази даних, включаючи всі об'єкти та дані системних таблиць. Повна резервна копія не усікатиме (truncate) журнал транзакцій. Це основний тип резервних копій, який потрібно виконувати перед іншими типами резервних копій.

Повну резервну копію можна відновити за 1 крок, оскільки вона не вимагає інших диференціальних/інкрементальних копій.

Якщо модель відновлення бази SQL даних встановлена як “Повна”, при відновленні бекапа ви можете вказати параметр “ STOPAT ”, де вказується час (до секунди), на якому потрібно зупинити відновлення даних. Наприклад, співробітник вніс некоректні дані о 14:46:07, за допомогою параметра STOPAT ви можете відновити дані на момент 14:46:06

Диференційне

Диференційне або різницеве резервне копіювання — це копіювання лише даних, які з'явилися з моменту останньої повної резервної копії.

Цей тип резервного копіювання використовують разом із повною резервною копією, оскільки відновлення диференціальної копії необхідна повна резервна копія.

Зазвичай під час використання різницевого резервного копіювання використовують план типу “повне що N днів, диференціальне кожні N годин”. Якщо щоденний оборот даних досить високий, цей тип резервних копій може бути незручний у застосуванні, оскільки копії важитимуть досить багато.

Наприклад, якщо повна резервна копія важить 300 GB, а диференціальна через годину роботи 5 GB, то за добу це буде 120 GB, що робить використання цього типу копій нераціональним.

Журнал транзакцій

Резервне копіювання журналу транзакцій копіює всі транзакції, що відбулися з моменту останнього резервного копіювання, а потім урізує журнал транзакцій для звільнення дискового простору.

Відновлюючи журнал транзакцій, ви також можете вказати параметр STOPAT, як і відновлення повної резервної копії.

Цей тип бекапа є інкрементальним, тому для відновлення бази даних вам знадобиться весь ланцюжок резервних копій: Повна та всі наступні інкрементальні журнали транзакцій.

Tail-Log

Цей вид резервного копіювання виділяють як окремий, але це звичайна резервна копія журналу транзакцій з NORECOVERY опцією.

Tail-Log бекап рекомендується робити перед відновленням копій журналу транзакцій, щоб не втратити транзакції між останнім бекапом та поточним моментом часу.

Copy-only

Цей вид бекапа не може служити базою для диференціальних резервних копій і для копій журналу транзакцій. Copy-only бекап не порушує поточний ланцюжок резервних копій (повний -> диференціальний або повний -> копії журналів транзакцій) і використовується тільки в тому випадку, якщо вам потрібно зняти повну резервну копію, не зачіпаючи поточний ланцюжок бекапів.

За винятком цих нюансів – нічим не відрізняється від звичайної повної копії.

Часткова резервна копія

Partial backup цей тип резервної копії використовується для того, щоб зняти копії з read-only файлових груп. Насправді використовується рідко.

Резервне копіювання файлів та файлових груп

Використовується для резервного копіювання певних файлів або файлових груп.

Моделі відновлення бази даних SQL Server

Модель відновлення – це параметр бази даних SQL Server, який відповідає за реєстрацію транзакцій у журналі транзакцій. Усього існує три моделі відновлення:

Проста модель відновлення

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

У разі аварії дані можуть бути відновлені лише на момент зняття резервної копії.

При використанні цієї моделі відновлення наступний функціонал SQL Server недоступний:

Доставка журналів транзакцій
Always On
Point-In-Time відновлення
Резервні копії журналу транзакцій

Повна модель відновлення

Повна модель відновлення зберігає всі транзакції у журналі транзакцій до усічення журналу (за допомогою зняття резервної копії журналу).

Це "найнадійніша" модель відновлення, при аварійному збої можна ви зможете відновити всі транзакції, крім тих, які не встигли завершитися при аварії.

Ця модель потребує обслуговування журналів транзакцій (регулярні резервні копії), інакше журнали займуть весь дисковий простір.

Відновлення з неповним протоколюванням (bulk logged)

Ця модель також, як і повна, записує всі транзакції в журнал транзакцій, за винятком таких операцій як:

SELECT INTO
BULK INSERT та BCP
INSERT INTO SELECT
Операції з індексами (CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX)

В іншому ця модель працює аналогічно до повної моделі відновлення.

Налаштування резервного копіювання SQL Server за допомогою плану обслуговування

Плани обслуговування SQL Server це найпоширеніший спосіб налаштування регулярного резервного копіювання.

Розглянемо налаштування резервної бази даних на SQL Server копіювання за планом:

Повна резервна копія кожні 24 години
Копія журналу транзакцій – кожні 30 хвилин

У SSMS (SQL Server Management Studio) перейдіть до розділу Management -> Maintenance Planes і запустіть -> майстер створення плану обслуговування (Maintenance Plan Wizard).

Вкажіть ім'я плану та виберіть “Separate schedules for each task”.

Виберіть операції, які потрібно зробити у цьому плані обслуговування:

Використовуйте наступну послідовність операцій:

Виберіть базу даних SQL Server, яку потрібно бекапіті і виберіть розклад.

Вкажіть шлях до каталогу, в який потрібно зберігати резервну копію вашої бази даних.

Вкажіть скільки зберігатимуться резервні копії (наприклад, 14 днів).

Натисніть Next і аналогічно створіть розклад резервного копіювання журналу транзакцій.

Опціонально можна вказати файл ведення лога плану обслуговування.

Завершить налаштування плану обслуговування SQL Server.

Виконайте план обслуговування вручну та перевірте журнал.

Як ви бачите, була створена повна резервна копія бази даних SQL Server і слідом копія журналу транзакцій. На цьому налаштування резервного копіювання закінчено.

Відновлення бази даних SQL Server із резервної копії

Тепер розглянемо, як відновити базу даних SQL Server з резервної копії. Для відновлення бази можна використовувати графічну консоль SQL Server Management Studio або мову T-SQL.

Відновлення резервної копії за допомогою SQL Server Management Studio

Запустіть SSMS, клацніть розділ Database і виберіть Restore Database.

Виберіть базу даних. У вікні з'явиться список резервних копій, зареєстрованих у SQL Server для цієї бази даних.

Наприклад, скористаємося Point-In-Time відновленням і виберемо момент, який ми хочемо відновити базу даних. Натисніть кнопку Timeline.

Виберіть опцію “ Close existing connections to destination database ”, якщо ваша база даних перебуває у статусі Online

Натисніть кнопку ОК. Після цього база даних відновиться на вибраний час.

Відновлення бази даних MS SQL Server за допомогою T-SQL

Розглянемо невеликий Transact-SQL скрипт, який виконує ту ж послідовність дії для відновлення бази даних, що й майстер (скрипт був згенерований майстром прикладу вище).

USE [master]
ALTER DATABASE [TestDatabase2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
BACKUP LOG [TestDatabase2] TO DISK = N'E:MSSQL15.NODE2MSSQLBackupTestDatabase2_LogBackup_2020-02-17_15-39-43.bak' WITH NOFORMAT, NOINIT, NAME = N'TestDatabase2_LogBackup_2020-02-17_15-39-43', NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 5
RESTORE DATABASE [TestDatabase2] FROM DISK = N'E:MSSQL15.NODE2MSSQLBackupfull.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N'E:MSSQL15.NODE2MSSQLBackuptrans.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N'E:MSSQL15.NODE2MSSQLBackuptrans.bak' WITH FILE = 2, NOUNLOAD, STATS = 5, STOPAT = N'2020-02-17T15:38:23'
ALTER DATABASE [TestDatabase2] SET MULTI_USER
GO

В даному випадку база даних переводиться в SINGLE_USER , але потрібно бути обережним з цим параметром, тому що в деяких ситуаціях ви можете закрити собі доступ, якщо хтось відкриє сесію раніше за вас.

Далі виконується tail-log бекап, потім відновлюється повний бекап і потім відновлюються бекапи журналу транзакцій. Зверніть увагу на параметр STOPAT, база даних відновиться на момент 15:38:23