Take tail log backup before restore что это
Резервные копии заключительного фрагмента журнала (SQL Server)
В резервную копию заключительного фрагмента журнала попадают все записи, резервная копия которых еще не была создана ( заключительный фрагмент журнала), что позволяет предотвратить потерю работы и сохранить неповрежденную цепочку журналов. Для восстановления базы данных SQL Server на последний момент времени необходимо предварительно выполнить резервное копирование заключительного фрагмента журнала ее транзакций. Заключительный фрагмент журнала является становится последней рассматриваемой частью резервной копии в плане восстановления базы данных.
ПРИМЕЧАНИЕ. Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Резервная копия заключительного фрагмента журнала не нужна, если точка восстановления содержится в более ранней резервной копии журнала. Кроме того, резервная копия заключительного фрагмента журнала не требуется при перемещении или замещении (перезаписи) базы данных, при котором не нужно восстанавливать ее на определенный момент времени после создания ее последней резервной копии.
Сценарии, в которых требуется резервная копия заключительного фрагмента журнала.
Рекомендуется формировать резервную копию заключительного фрагмента журнала в следующих сценариях.
Если база данных находится в режиме «в сети» и следующим действием над базой данных должна быть операция восстановления, то прежде необходимо выполнить резервное копирование заключительного фрагмента журнала. Во избежание ошибок для базы данных в режиме «в сети» необходимо использовать параметр WITH NORECOVERY инструкции BACKUP Transact-SQL.
Если база данных, работающая в режиме «вне в сети», не запускается и необходимо восстановить базу данных, то в первую очередь необходимо выполнить резервное копирование заключительного фрагмента журнала. Так как в это время никакие транзакции не выполняются, параметр WITH NORECOVERY использовать не обязательно.
Если база данных повреждена, попытайтесь получить резервную копию заключительного фрагмента журнала, используя параметр WITH CONTINUE_AFTER_ERROR инструкции BACKUP.
Резервное копирование заключительного фрагмента журнала поврежденной базы данных может быть успешно выполнено только в том случае, если файлы журнала не повреждены, а база данных находится в режиме, который поддерживает резервное копирование заключительного фрагмента журнала, и не содержит какие-либо изменения с неполным протоколированием. Если резервная копия заключительного фрагмента журнала не может быть создана, то любые транзакции, зафиксированные после создания последней резервной копии журнала, будут потеряны.
В следующей таблице представлена сводка параметров BACKUP NORECOVERY и CONTINUE_AFTER_ERROR.
| Параметр BACKUP LOG | Комментарии |
|---|---|
| NORECOVERY | Если планируется продолжить операцию восстановления базы данных, используйте параметр NORECOVERY. NORECOVERY переводит базу данных в состояние восстановления. Это гарантирует, что после создания резервной копии заключительного фрагмента журнала база данных не изменится. Если параметры NO_TRUNCATE или COPY_ONLY не заданы, журнал усекается. Внимание! Параметр NO_TRUNCATE рекомендуется использовать, только если база данных повреждена. Возможно, потребуется перевести базу данных в однопользовательский режим, чтобы получить монопольный доступ до выполнения RESTORE WITH NORECOVERY. После восстановления снова задайте для базы данных многопользовательский режим. |
| CONTINUE_AFTER_ERROR | Параметр CONTINUE_AFTER_ERROR следует указывать только в том случае, если создается резервная копия заключительного фрагмента журнала поврежденной базы данных. При резервном копировании заключительного фрагмента журнала поврежденной базы данных, некоторые метаданные, захватываемые обычно в резервные копии журналов, могут быть недоступны. Дополнительные сведения см. в подразделе Резервное копирование заключительного фрагмента журнала с неполными метаданными резервной копииэтого раздела. |
Резервные копии заключительного фрагмента журнала с неполными метаданными
Резервное копирование заключительного фрагмента журнала захватывает конец журнала даже в тех случаях, когда база данных работает вне сети, повреждена или в ней не хватает файлов данных. В результате этого метаданные команд восстановления данных и базы данных msdb могут быть неполными. Однако несмотря на неполноту метаданных, захваченный журнал будет полным и готовым к использованию.
Если резервная копия заключительного фрагмента журнала содержит неполные метаданные, то параметр has_incomplete_metadata в таблице backupset принимает значение 1. Кроме того, выходной аргумент HasIncompleteMetadataинструкции RESTORE HEADERONLY принимает значение 1.
Если метаданные в резервной копии заключительного фрагмента журнала неполные, то в таблице backupfilegroup большая часть сведений о файловых группах того времени в резервной копии заключительного фрагмента журнала будет утеряна. Большинство столбцов таблицы backupfilegroup содержит значение NULL, другие значения имеют следующие столбцы:
Связанные задачи
Инструкции по восстановлению резервной копии журнала транзакций см. в разделе Восстановление резервной копии журнала транзакций (SQL Server).
Tail-Log Backups (SQL Server)
This topic is relevant only for backup and restore of SQL Server databases that are using the full or bulk-logged recovery models.
A tail-log backup captures any log records that have not yet been backed up (the tail of the log) to prevent work loss and to keep the log chain intact. Before you can recover a SQL Server database to its latest point in time, you must back up the tail of its transaction log. The tail-log backup will be the last backup of interest in the recovery plan for the database.
NOTE: Not all restore scenarios require a tail-log backup. You do not need a tail-log backup if the recovery point is contained in an earlier log backup. Also, a tail-log backup is unnecessary if you are moving or replacing (overwriting) a database and do not need to restore it to a point of time after its most recent backup.
Scenarios That Require a Tail-Log Backup
We recommend that you take a tail-log backup in the following scenarios:
If a database is offline and fails to start and you need to restore the database, first back up the tail of the log. Because no transactions can occur at this time, using the WITH NORECOVERY is optional.
If a database is damaged, try to take a tail-log backup by using the WITH CONTINUE_AFTER_ERROR option of the BACKUP statement.
On a damaged database backing up the tail of the log can succeed only if the log files are undamaged, the database is in a state that supports tail-log backups, and the database does not contain any bulk-logged changes. If a tail-log backup cannot be created, any transactions committed after the latest log backup are lost.
The following table summarizes the BACKUP NORECOVERY and CONTINUE_AFTER_ERROR options.
| BACKUP LOG option | Comments |
|---|---|
| NORECOVERY | Use NORECOVERY whenever you intend to continue with a restore operation on the database. NORECOVERY takes the database into the restoring state. This guarantees that the database does not change after the tail-log backup. The log will be truncated unless the NO_TRUNCATE option or COPY_ONLY option is also specified. Important: Avoid using NO_TRUNCATE, except when the database is damaged. You may need to put the database into single-user mode to obtain exclusive access before performing the restore with NORECOVERY. After the restore, set the database back to multi-user mode. |
| CONTINUE_AFTER_ERROR | Use CONTINUE_AFTER_ERROR only if you are backing up the tail of a damaged database. When you use back up the tail of the log on a damaged database, some of the metadata ordinarily captured in log backups might be unavailable. For more information, see Tail-Log Backups That Have Incomplete Backup Metadata, in this topic. |
Tail-Log backups that have incomplete backup metadata
Tail log backups capture the tail of the log even if the database is offline, damaged, or missing data files. This might cause incomplete metadata from the restore information commands and msdb. However, only the metadata is incomplete; the captured log is complete and usable.
If a tail-log backup has incomplete metadata, in the backupset table, has_incomplete_metadata is set to 1. Also, in the output of RESTORE HEADERONLY, HasIncompleteMetadata is set to 1.
If the metadata in a tail-log backup is incomplete, the backupfilegroup table will be missing most of the information about filegroups at the time of the tail-log backup. Most of the backupfilegroup table columns are NULL; the only meaningful columns are as follows:
Восстановление базы данных из резервной копии в MS SQL Server 2012
Раннее я уже писал о создании резервных копий в MS SQL Server 2012. В данной статье подробно рассмотрим процессе восстановления базы данных из имеющейся резервной копии (резервных копий) в MS SQL Server 2012 (в более ранних версиях, например в MS SQL Server 2008 набор действий аналогичен).
0. Оглавление
1. Восстановление базы данных
Подключаемся к MS SQL Server c помощью программы «SQL Server Management Studio». В Microsoft Windows Server 2012 R2 ее можно найти в списке всех программ.
В Microsoft Windows Server 2008 R2 в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Среда SQL Server Management Studio».
Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).
Слева, в обозревателе объектов (Object Explorer), раскрываем вкладку «Базы данных» (Server Oblects), находим в списке базу данных из которой (или в которую) необходимо восстановить данные, кликаем по ней правой кнопкой мыши, затем в появившемся контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…)
Запустится мастер восстановления базы данных (Restore Database). Выбираем базу источник (Source for restore), при этом мастер попробует автоматически подобрать последовательность файлов резервных копий для восстановления базы на текущий момент времени.
Если же требуется загрузить данные из конкретного файла или устройства резервного копирования, то необходимо установить соответствующий переключатель в положение «Устройство» (From device) и вручную указать источник для восстановления.
Затем необходимо выбрать базу данных назначения (Destination for restore), т. е. ту информационную базу в которую будут загружаться данные. Эта может быть как база с которой делалась резервная копия, так и любая другая база данных, зарегистрированная на текущем экземпляре SQL Server.
Нажав кнопку «Временная шкала…» (Timeline) можно указать время на которое необходимо восстановить данные. При имеющейся копии журнала транзакций время восстановления можно выбрать с точностью до секунды (или имеющегося checkpoint’а в журнале транзакций).
Очень важно (!) также помнить о том, что если восстановление данных осуществляется в информационную базу отличную от той с которой производилось резервное копирование (т. е. необходимо скопировать базу данных) то на вкладке «Файлы» (Files) необходимо указать путь к файлам этой информационной базы.
На вкладке «Параметры» (Options) можно указать дополнительные параметры резервного копирования. В частности:
Когда все необходимые параметры установлены нажимаем «ОК» для запуска процесса восстановления базы данных. После того, как все операции по восстановлению будут завершены увидим соответствующее уведомление.
2. Просмотр информации о событиях резервного копирования и восстановления для базы данных
Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).
Сформировавшийся отчет содержит в себе следующие данные:
Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.
Смотрите также:
Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…
Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…
Ниже будет подробно рассказано о том, как создать резервную копию базы данных в MS SQL Server 2012. В младших версиях (например в MS SQL Server 2008) алгоритм получения резервной копии…
Резервное копирование и восстановление базы данных в 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
За исключением этих нюансов – ничем не отличается от обычной полной копии.
Частичная резервная копия
Partial backup этот тип резервной копии используется для того, чтобы снять копии с read-only файловых групп. На практике используется редко.
Резервное копирование файлов и файловых групп
Используется для снятия резервных копий определенных файлов или файловых групп.
Модели восстановления базы данных SQL Server
Модель восстановления – это параметр базы данных SQL Server, который отвечает за регистрацию транзакций в журнале транзакций. Всего существует три модели восстановления:
Простая модель восстановления
Автоматически урезает журналы транзакций, освобождая место на диске. Вручную журналы транзакций обслуживать не нужно.
В случае аварии, данные могут быть восстановлены только на момент снятия резервной копии.
При использовании этой модели восстановления, следующий функционал SQL Server недоступен:
Полная модель восстановления
Полная модель восстановления хранит все транзакции в журнале транзакций до усечения журнала (посредством снятия резервной копии журнала).
Это самая “надежная” модель восстановления, при аварийном сбое можно вы сможете восстановить все транзакции, кроме тех, которые не успели завершиться при аварии.
Эта модель нуждается в обслуживании журналов транзакций (регулярные резервные копии), иначе журналы займут всё дисковое пространство.
Восстановление с неполным протоколированием (bulk logged)
Эта модель, также, как и полная, записывает все транзакции в журнал транзакций, за исключением таких операций как:
В остальном эта модель работает аналогично полной модели восстановления.
Настройка резервного копирования SQL Server с помощью плана обслуживания
Планы обслуживания SQL Server это самый распространенный способ настройки регулярного резервного копирования.
Рассмотрим настройку резервного базы данных на SQL Server копирования по плану:
Укажите имя плана и выберите режим “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.NODE2\MSSQL\Backup\TestDatabase2_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.NODE2\MSSQL\Backup\full.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\trans.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\trans.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