Tail log backup что это

SQL-Ex blog

Одной из основополагающих обязанностей администратора баз данных является обеспечение доступности резервных копий (бэкапов).

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

Зачем делать бэкапы?

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

Полные резервные копии SQL Server (Full Backup)

Что выполняет полный бэкап? Полный бэкап создает резервную копию всей базы данных. Это подразумевает включение всей структуры базы данных и всех данных. Когда стартует полное резервирование, записывается Log Sequence Number (LSN — последовательный номер журнала), LSN записывается и при завершении полного резервирования. Этот LSN является механизмом, используемым SQL Server, чтобы знать, в каком порядке выполнялись операторы INSERT, UPDATE или DELETE. При этом наличие записанных LSN начала и окончания, как части полного бэкапа, обеспечивает согласованное с точки зрения транзакций резервное копирование, поскольку при полном резервном копировании учитываются изменения, произошедшие во время резервного копирования. Это обеспечивает обработку таких транзакций в процессе восстановления бэкапа. Эта полная резервная копия служит базовым бэкапом или отправной точкой для всех последующих дифференциальных резервных копий или бэкапов журналов. Всякий раз, когда создается новый полный бэкап, устанавливается новая точка отсчета бэкапов.

Дифференциальные резервные копии SQL Server

Что дает вам дифференциальный бэкап? Дифференциальное резервное копирование основывается на концепции разностного растрового изображения. SQL Server оперирует 8-килобайтными страницами. Эти страницы собраны в группы по 8, называемые «экстентами» (Extents). Имеется битовая карта, которая используется для пометки каждого экстента, который подвергался изменению данных с момента последнего полного резервирования. При выполнении дифференциального бэкапа именно эта битовая карта определяет, какие данные помещать в резервную копию.

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

Когда используется полная модель восстановления, мощь дифференциала может быть очень важна. Дифференциальный бэкап сокращает число резервных копий журнала, которые должны быть восстановлены. Например, если имеется полный бэкап, сделанный в ночь воскресенья, и после этого каждые 15 минут создавались журналы транзакций, и администратору нужно восстановить базу данных ко вторнику в 5:53, ему потребуется построить процесс восстановления на базе полного бэкапа и каждого журнала транзакция, начиная с вечера воскресенья! Это потребует включения множества журналов транзакций. При ежедневном дифференциале, выполняемом в 5 часов, администратору потребуется восстановить полный воскресный бэкап, один дифференциальный, созданный во вторник в 5 часов, и только те журналы транзакций, которые создавались после 5 часов вторника. Возможность отбросить все эти журналы транзакций и обуславливает мощь этого метода.
Это значительно упрощает создание и читабельность скрипта и может сохранить массу времени администратору при написании скрипта вручную. Вам следует иметь автоматизированный процесс создания скрипта резервирования, но некоторые администраторы еще не настроили его. Мы позже поговорим об автоматизации создании скрипта резервных копий.

Резервные копии файлов и файловых групп в SQL Server

Что такое бэкапы файлов и файловых групп? Для начала это более продвинутый вариант по сравнению с другими типами бэкапов. А раз это так, менее вероятно, что вам потребуется этот тип резервной копии. Однако знание того, какие варианты существуют, всегда полезно.

Бэкапы файлов и файловых групп позволяют получить более гранулированные резервные копии и, соответственно, более детализированный процесс восстановления. То, что делается, соответствует названию. Резервируется отдельный файл или коллекция файлов, содержащихся в файловой группе. Это позволяет восстановить небольшую часть базы данных, чтобы исправить проблему, а не восстанавливать всю базу данных. Однако этот вариант вносит сложность и, на мой взгляд, на самом деле полезен только для больших баз данных, особенно в диапазоне 500Гб и более.

Эти типы резервирования файлов и файловых групп могут использоваться, когда большая база данных разбита на множество файлов. Например, большая база данных, содержащая информацию о продажах, разбивается на различные файлы Sales, возможно, по годам или даже помесячно, если база данных содержит большой объем записей о продажах. Эти файлы затем собираются в файловые группы. Ниже приведен пример создания файлов и файловых групп в базе данных. Этот пример взят из документации MS.

USE master; 
GO 
-- Создание базы данных с дефолтными 
-- файловой группой для данных, 
-- файловой группой для файлового потока 
-- файла журнала. 
-- Задан максимальный размер и его приращение 
-- для первичного файла данных 
CREATE DATABASE MyDB 
ON PRIMARY 
( NAME='MyDB_Primary', 
FILENAME= 
'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\data\MyDB_Prm.mdf', 
SIZE=4MB, 
MAXSIZE=10MB, 
FILEGROWTH=1MB), 
-- Здесь создается отдельный файл и 
-- привязывается к файловой группе, 
-- которая несколько больше, чем контейнер. 
FILEGROUP MyDB_FG1 
( NAME = 'MyDB_FG1_Dat1', 
FILENAME = 
'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\data\MyDB_FG1_1.ndf', 
SIZE = 1MB, 
MAXSIZE=10MB, 
FILEGROWTH=1MB), 
-- Здесь создается другой файл и 
-- привязывается к файловой группе. 
( NAME = 'MyDB_FG1_Dat2', 
FILENAME = 
'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\data\MyDB_FG1_2.ndf', 
SIZE = 1MB, 
MAXSIZE=10MB, 
FILEGROWTH=1MB) 
LOG ON 
( NAME='MyDB_log', 
FILENAME = 
'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\data\MyDB.ldf', 
SIZE=1MB, 
MAXSIZE=10MB, 
FILEGROWTH=1MB); 
GO 
ALTER DATABASE MyDB 
MODIFY FILEGROUP MyDB_FG1 DEFAULT; 
GO 
-- Создается таблица в файловой группе пользователя. 
USE MyDB; 
CREATE TABLE MyTable 
( cola int PRIMARY KEY, 
colb char(8) ) 
ON MyDB_FG1; 
GO

Резервные копии журналов транзакций в SQL Server

Что такое бэкап журнала транзакций? Бэкап журнала транзакций будет создавать резервную копию журнала транзакций SQL Server, чтобы изменения данных, хранящиеся в нем, можно было воспроизвести в процессе восстановления. И здесь упомянутая ранее концепция Log Sequence Number является ключевой. Поскольку транзакции происходят в определенном порядке, бэкап журнала поддерживает этот порядок транзакций. Бэкапы журналов транзакций должны восстанавливаться по порядку. Если вы попытаетесь восстановить ряд бэкапов журналов в неверном порядке, SQL Server сгенерирует ошибку. Наличие бэкапов журналов позволяет выполнить так называемое восстановление к заданной точке во времени (point in time restore). Возможность восстановления к заданной точке времени может быть критичным для бизнеса. Предположим, что некто внес изменения непосредственно в одну или более таблиц. Если была допущена ошибка и произошло непредусмотренное изменение данных, восстановление к точке времени позволит администратору восстановить данные к моменту, предшествующему выполнению ошибочных изменений.

Только копирование резервных копий (Copy Only Backups)

Что такое копирование только бэкапов? Копирование бэкапов не влияет или не отслеживает информацию Log Sequence Number. Зачем это может понадобиться? Ну, предположим, что вы уже сделали полный, дифференциальные бэкапы и бэкапы журналов. Вас просят предоставить файл бэкапа баы данных в другой отдел или, возможно, отдельному разработчику, работающему на проектом. Этот отдел предположительно не имеет доступа к каталогу, где находятся резервные копии. Вместо того, чтобы попытаться скопировать множество бэкапов для предоставления общего доступа или размещения его в другом месте, к которому имеет доступ разработчик, вы могли бы просто создать полный бэкап Copy Only, который записывается в место общего доступа. Затем разработчик может использовать этот бэкап для восстановления на локальной машине, а вы получаете то преимущество, что не меняете базовую резервную копию для своей цепочки бэкапов.

Что дальше

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

Резервные копии журналов транзакций (SQL Server)

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

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

Рекомендуется периодически производить резервное копирование журнала для снижения вероятности потери результатов работы и для усечения журнала транзакций.

Обычно администратор базы данных время от времени создает полную резервную копию базы данных (например, еженедельно) и дополнительно создает разностные резервные копии через более короткие интервалы, например ежедневно. Независимо от резервного копирования базы данных администратор с высокой периодичностью создает резервные копии журнала транзакций. При таком подходе к резервному копированию оптимальный интервал между моментами выполнения резервного копирования зависит от множества факторов: важности данных, размера базы данных и рабочей нагрузки сервера. Дополнительные сведения о реализации хорошей стратегии см. в Рекомендации в этой статье.

Работа последовательности резервных копий журнала

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

Time	Событие
8:00	Резервное копирование базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Резервное копирование базы данных.
20:00	Резервное копирование журнала транзакций.

Резервная копия журнала транзакций, созданная в 8:00 вечера, содержит записи журнала транзакций с 4:00 по 8:00, охватывая время создания полной резервной копии базы данных в 6:00. Последовательность резервных копий журналов транзакций выполняется непрерывно, начиная с исходной полной резервной копии базы данных, созданной в 8:00 утра, до последней резервной копии журнала транзакций, созданной в 8:00. Сведения о применении этих резервных копий журналов см. в примере в разделе «Применение резервных копий журналов транзакций» (SQL Server).

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

Резервное копирование журнала транзакций
SqlBackup (SMO)
Использование мастера планов обслуживания

Связанный контент

Журнал транзакций
Раздел «Резервные копии журналов транзакций» в руководстве по архитектуре журнала транзакций SQL Server и управлению им
Резервное копирование и восстановление баз данных SQL Server
Резервные копии журналов (SQL Server)
Применение резервных копий журналов транзакций (SQL Server)

Резервные копии журналов (SQL Server)

Эта статья относится только к резервному копированию и восстановлению баз данных SQL Server, использующих полные или массовые модели восстановления.

Резервная копия tail-log записывает все записи журнала, которые еще не были сохранены ( хвост журнала), чтобы предотвратить потерю работы и сохранить цепочку журналов без изменений. Прежде чем восстановить базу данных SQL Server до последней точки во времени, необходимо создать резервную копию хвоста журнала транзакций. Резервная копия tail-log — это последняя резервная копия плана восстановления для базы данных.

Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Если точка восстановления содержится в более ранней резервной копии журналов, вам не нужна резервная копия журналов. Резервная копия tail-log не требуется при перемещении или замене (перезаписи) базы данных и не требуется восстановить ее до точки времени после последней резервной копии.

Сценарии, для которых требуется резервное копирование журналов хвоста

Рекомендуется формировать резервную копию заключительного фрагмента журнала в следующих сценариях.

Если база данных находится в режиме «в сети» и следующим действием над базой данных должна быть операция восстановления, то прежде необходимо выполнить резервное копирование заключительного фрагмента журнала. Чтобы избежать ошибки для веб-базы данных, необходимо использовать WITH NORECOVERY параметр инструкции BACKUP Transact-SQL.
Если база данных, работающая в режиме «вне в сети», не запускается и необходимо восстановить базу данных, то в первую очередь необходимо выполнить резервное копирование заключительного фрагмента журнала. Так как в настоящее время транзакции не могут выполняться, используйте WITH NO_TRUNCATE этот параметр. NO_TRUNCATE фактически совпадает с резервным копированием журнала транзакций только для копирования. Использование WITH NORECOVERY является необязательным, так как в настоящее время транзакции не могут возникать.
Если база данных повреждена, попробуйте создать резервную копию tail-log с помощью WITH CONTINUE_AFTER_ERROR параметра инструкции BACKUP . В поврежденной базе данных резервное копирование хвоста журнала может быть выполнено только в том случае, если файлы журналов не повреждены, база данных находится в состоянии, поддерживающем резервные копии tail-log, и база данных не содержит никаких массовых изменений. Если не удается создать резервную копию tail-log, все транзакции, зафиксированные после последней резервной копии журнала, будут потеряны.

В следующей таблице перечислены NORECOVERY NO_TRUNCATE параметры и CONTINUE_AFTER_ERROR параметры BACKUP .

Параметр BACKUP LOG	Комментарии
NORECOVERY	Используйте NORECOVERY всякий раз, когда вы планируете продолжить операцию восстановления в базе данных. NORECOVERY принимает базу данных в состояние восстановления. Этот шаг гарантирует, что база данных не изменяется после резервного копирования журналов хвоста. Журнал усечен, если NO_TRUNCATE параметр или COPY_ONLY параметр также не указан.

Параметр BACKUP LOG

Комментарии

NORECOVERY

Используйте NORECOVERY всякий раз, когда вы планируете продолжить операцию восстановления в базе данных. NORECOVERY принимает базу данных в состояние восстановления. Этот шаг гарантирует, что база данных не изменяется после резервного копирования журналов хвоста. Журнал усечен, если NO_TRUNCATE параметр или COPY_ONLY параметр также не указан.

Резервные копии tail-log с неполными метаданными резервного копирования

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

Если резервная копия tail-log содержит неполные метаданные, в таблице has_incomplete_metadata набора резервных копий задано значение 1 . Кроме того, в выходных данных RESTORE HEADERONLY HasIncompleteMetadata задано значение 1 .

Если метаданные в резервном копировании tail-log неполны, таблица backupfilegroup отсутствует большая часть сведений о файловых группах во время резервного копирования tail-log. backupfilegroup Большинство столбцов таблицы : NULL единственные значимые столбцы:

backup_set_id
filegroup_id
type
type_desc
is_readonly

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

Сведения о создании резервного копирования в журнале tail-log см. в статье Резервное копирование журнала транзакций при повреждении базы данных (SQL Server).

Связанный контент

BACKUP (Transact-SQL)
Инструкции RESTORE (Transact-SQL)
Резервное копирование и восстановление баз данных SQL Server
Резервные копии только для копирования (SQL Server)
Резервные копии журналов транзакций (SQL Server)
Применение резервных копий журналов транзакций (SQL Server)
Руководство по архитектуре журнала транзакций SQL Server и управлению

Tail log backup что это

Резервная копия, созданная по команде BACKUP, сохраняется по умолчанию в набор носителей, созданный ранее или созданный при первом копировании. Все копии, созданные до этого, сохраняются, если указан параметр NOINIT и удаляются, если указан параметр INIT.
Для форматирования носителя копии используется параметр FORMAT в следующем предложении:

 FORMAT [, MEDIANAME = < media_name | @ media_name_variable >] [ , MEDIADESCRIPTION = < text | @ text_variable >]

Полное копирование с помощью PowerShell

Чтобы создать полный бэкап в PowerShell, следует использовать упрощённую команду Backup-SqlDatabase. Чтобы отметить, что эта резервная копия является полной, необходимо задать параметр BackupAction вместе с Database (оно применяется по умолчанию). Этот параметр не относится к обязательным при полном резервировании БД.
Для использования PowerShell понадобится специальный модуль SqlServer. Выполнение команды Get-Module-Name SqlServer поможет понять, установлен модуль или нет. Для установки модуля понадобится в сеансе PowerShell на правах администратора выполнить команду Install-Module-Name SqlServer.

Дифференциальное (разностное) копирование данных

Tail log backup что это

SQL-Ex blog

Зачем делать бэкапы?

Полные резервные копии SQL Server (Full Backup)

Дифференциальные резервные копии SQL Server

Резервные копии файлов и файловых групп в SQL Server

Резервные копии журналов транзакций в SQL Server

Только копирование резервных копий (Copy Only Backups)

Что дальше

Резервные копии журналов транзакций (SQL Server)

Работа последовательности резервных копий журнала

Рекомендации

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

Связанный контент

Резервные копии журналов (SQL Server)

Сценарии, для которых требуется резервное копирование журналов хвоста

Резервные копии tail-log с неполными метаданными резервного копирования

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

Связанный контент

Tail log backup что это

Добавить комментарий Отменить ответ