Резервное копирование sql server: Создание полной резервной копии базы данных — SQL Server

Содержание

Резервное копирование баз данных Microsoft SQL Server.

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

Модели восстановления

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

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

Для использования в производственных средах предлагается две модели восстановления: простая и полная. Существует также модель с неполным протоколированием, но она рекомендуется только как дополнение к полной модели на период крупномасштабных массовых операций, когда нет необходимости восстановления базы на определенный момент времени.

Простая модель предусматривает резервное копирование только базы данных, соответственно восстановить состояние БД мы можем только на момент создания резервной копии, все изменения в промежуток времени между созданием последней резервной копии и сбоем будут потеряны. В тоже время простая схема имеет небольшие накладные расходы: вам необходимо хранить только копии базы данных, лог транзакций при этом автоматически усекается и не растет в размерах. Также процесс восстановления наиболее прост и не занимает много времени.

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

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

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

Виды резервных копий

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

Разностная копия базы данных — полная копия имеет один существенный недостаток, она содержит всю информацию базы данных. Если резервные копии нужно делать довольно часто, то сразу возникает вопрос неэкономного использования дискового пространства, так как большую часть хранилища будут занимать одинаковые данные. Для устранения этого недостатка можно использовать разностные копии базы данных, которые содержат только изменившуюся со времени последнего полного копирования информацию.

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

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

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

Посмотрим на рисунок выше, если будет утрачена первая копия файла журнала, то вы сможете восстановить состояние базы только на момент полного копирования, что будет аналогично простой модели восстановления, восстановить состояние базы на любой момент времени вы сможете только после следующего разностного (или полного) копирования, при условии, что цепочка копий журналов начиная с предшествующего копированию базы и далее будет непрерывна (на рисунке — от третьего и далее).

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

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

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

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

Та часть журнала, которая содержит активные транзакции и используется для восстановления данных называется активной частью журнала. Она начинается с номера, который называется минимальным номером восстановления (MinLSN).

В простейшем случае MinLSN — это номер записи первой незавершенной транзакции. Если посмотреть на рисунок выше, то открыв синюю транзакцию мы получим MinLSN равную 321, после ее фиксации в записи 324, номер MinLSN изменится на 323, что будет соответствовать номеру зеленой, еще не зафиксированной, транзакции.

На практике все немного сложнее, например, данные закрытой синей транзакции могут быть еще не сброшены на диск и перемещение MinLSN на 323 сделает восстановление этой операции невозможной. Для того, чтобы избежать таких ситуации было введено понятие контрольной точки. Контрольная точка создается автоматически при наступлении следующих условий:

При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
При выполнении в базе данных операции с минимальной регистрацией, например, при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
При остановке экземпляра SQL Server с помощью инструкции SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка каждой базы данных в экземпляре SQL Server.
Если экземпляр SQL Server периодически создает в каждой базе данных автоматические контрольные точки для сокращения времени восстановления базы данных.
При создании резервной копии базы данных.
При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.

В зависимости от того, какое событие произошло раньше, MinLSN будет присвоено значение либо номера записи контрольной точки, либо начала самой старой незавершенной транзакции.

Усечение журнала транзакций

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

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

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

Если количество транзакций велико и к моменту достижения 70% размера физического файла не окажется неактивных логических журналов, то размер физического файла будет увеличен.

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

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

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

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

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

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

Резервное копирование выполнялось раз в сутки и последняя копия была создана ночью с 21-го на 22-е. Сбой происходит вечером 22-го до создания очередной копии. В этом случае нам потребуется последовательно восстановить полную и последнюю разностные копии, при этом данные за последний рабочий день будут утеряны. Если по каким-либо причинам копия от 21-го также окажется повреждена, то мы можем восстановить предыдущую копию, потеряв еще день работы, в тоже время повреждение копии за 20-е число никак не помешает успешно восстановить данные на вечер 21-го, при наличии соответствующей копии.

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

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

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

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

При этом повреждение файла копии журнала за предыдущий день не помешает нам восстановить актуальное состояние базы, но ограничит нас моментом создания последней копии, т. е. текущими сутками.

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

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

С другой стороны, если одна из копий лога транзакций будет повреждена, скажем, предпоследняя, то восстановить данные мы сможем только на момент последней резервной копии + период в неповрежденной цепочке копий журналов. Например, если журналы делались в 12, 14 и 16 часов и поврежден журнал, созданный в 14 часов, то располагая суточной копией мы сможем восстановить базу до момента окончания непрерывной цепочки, т. е. до 12 часов.

источник: http://interface31.ru/tech_it/2015/02/rezervnoe-kopirovanie-baz-dannyh-m…

Резервное копирование MS SQL Server

Обновлено: 23.12.2019 Опубликовано: 22.06.2017

Есть несколько способов создания резервной копии MS SQL. Для разовых операций прекрасно подойдет графический инструмент SQL Management Studio. Для автоматизации — Powershell или cmd. Данные операции применяются к любым базам, как для 1С, так и любых других приложений.

С помощью графического интерфейса

Открываем MS SQL Management Studio. Кликаем правой кнопкой мыши по базе, для которой хотим сделать резервную копию — Задачи — Создать резервную копию:

В открывшемся окне оставляем полный тип копий и путь к резервному файлу (при необходимости, можно его поменять, удалив и создав снова. Можно указать как локальный диск, так и сетевой):

После завершения процесса мы увидим сообщение «Резервное копирование базы … успешно завершено».

С помощью командной строки (cmd)

Данный способ удобно использовать для автоматизации резервного копирования. Более того, команды подходят как для Windows, так и Linux. Выполняется при помощи утилиты sqlcmd.

Синтаксис:

sqlcmd -S <server> -U <user> -P <password> -Q «BACKUP DATABASE [<database>] TO DISK = N'<file path>’ <options>»

Пример готового скрипта

@echo off

set dd=%DATE:~0,2%

set mm=%DATE:~3,2%

set yyyy=%DATE:~6,4%

set curdate=%dd%-%mm%-%yyyy%

set username=sa

set password=my_pass

set db=work1

sqlcmd -S localhost -U %username% -P %password% -Q «BACKUP DATABASE [%db%] TO DISK = N’D:\Backup\MSSQL\%db%_%curdate%.bak’ WITH NOFORMAT, NOINIT, NAME = N’%db%-full’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10»

set db=work2

sqlcmd -S localhost -U %username% -P %password% -Q «BACKUP DATABASE [%db%] TO DISK = N’D:\Backup\MSSQL\%db%_%curdate%. bak’ WITH NOFORMAT, NOINIT, NAME = N’%db%-full’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10″

* в данном примере мы подключаемся к локальному SQL серверу под учетной записью sa с паролем my_pass и делаем резервную копию баз work1 и work2. Резервные копии размещаем по пути D:\Backup\MSSQL. Имя файлов резервных копий work1_<текущая дата>.bak и work2_<текущая дата>.bak
* некоторые опции могут не работать, в зависимости от используемой редакции MS SQL.

Для автоматизации скрипта, создайте задание в планировщике, чтобы скрипт запускался по расписанию.

Типы резервных копий

Хорошей практикой является создание разных типов копий:

1) Полное копирование — резервирование всей базы. Выполняется командой, рассмотренной выше, например:

sqlcmd -S localhost -U sa -P my_pass -Q «BACKUP DATABASE work1 TO DISK = N’D:\Backup\MSSQL\bak_full. bak’ WITH NOFORMAT, NOINIT, NAME = N’bak-full’, SKIP, NOREWIND, NOUNLOAD, STATS = 10″

* в данном примере мы подключаемся к локальному серверу под пользователем sa с паролем my_pass и делаем полную копию базы work1; саму копию сохраняем в виде файла D:\Backup\MSSQL\bak_full.bak.

2) Разностное (дифференциальное) — резервирование базы данных с момента создания последней полной копии. Выполняется командой для резервного копирования с добавлением опции DIFFERENTIAL:

sqlcmd -S localhost -U sa -P my_pass -Q «BACKUP DATABASE work1 TO DISK = N’D:\Backup\MSSQL\bak_diff.bak’ WITH DIFFERENTIAL, NOFORMAT, NOINIT, NAME = N’bak-diff’, SKIP, NOREWIND, NOUNLOAD, STATS = 10»

3) Инкрементальное или копирование логов. Выполняется Transact-SQL:

sqlcmd -S localhost -U sa -P my_pass -Q «BACKUP LOG work1 TO DISK = N’D:\Backup\MSSQL\bak_log.bak’ WITH NOFORMAT, NOINIT, NAME = N’bak-log’, SKIP, NOREWIND, NOUNLOAD, STATS = 10»

* обратите внимение, команда похожа на команду для полного резервного копирования — вместо DATABASE пишем LOG.

С помощью Powershell

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

Для выполнения команды, сначала импортируем модуль:

import-module sqlps -DisableNameChecking

Синтаксис:

Backup-SqlDatabase -ServerInstance <имя SQL сервера> -Database <имя базы> -BackupFile <путь к файлу с резервной копией>

Пример скрипта на powershell

$server = «SQL01»

$curdate = Get-Date -Format yyyyMMdd

import-module sqlps -DisableNameChecking

$db = work1

Backup-SqlDatabase -ServerInstance $server -Database $db -BackupFile $db_$curdate.bak

* где выполняется резервное копирования базы work1 на сервере SQL01

Также как и для cmd, данный скрипт можно поместить в планировщик для запуска по расписанию.

Срок действия резервного набора данных

Данная настройка позволяет указать, через какой промежуток времени резервную копию можно удалить (перезаписать). Важно понимать, что настройка не влияет на сам период восстановления — если срок истек, восстановиться из набора можно.

Задать параметр можно в основном окне при создании резервной копии:

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

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

Кликаем правой кнопкой мыши по корневому разделу SQL Server и выбираем свойства:

Переходим в раздел Параметры баз данных (1) — в подразделе «Места хранения, используемые базой данных по умолчанию» мы увидим путь до места размещения резервных копий (2), который можно поменять кнопкой справа (3):

Команда SQL Server BACKUP DATABASE

Автор: Грег Робидоукс

Обзор

Есть только две команды для резервного копирования, основная — BACKUP DATABASE. Это позволяет вам делать полную резервную копию вашей базы данных, а также дифференциальные резервные копии, резервные копии файлов и т. д. в зависимости от используемых вами параметров.

Пояснение

Команда BACKUP DATABASE предоставляет множество возможностей для создания резервных копий. Ниже приведены различные примеры.

Создать полную резервную копию SQL Server на диск

Команда — BACKUP DATABASE имя_базы_данных. Параметр «НА ДИСК» указывает, что резервная копия должна быть записана на диск, а также указывается расположение и имя файла для создания резервной копии.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'

Создать дифференциальную резервную копию SQL Server

Эта команда добавляет параметр «С ДИФФЕРЕНЦИАЛОМ».

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
С ДИФФЕРЕНЦИАЛОМ
ВПЕРЕД

Создать резервную копию SQL Server на уровне файлов

Эта команда использует параметр «С ФАЙЛОМ», чтобы указать резервную копию файла. Вам необходимо указать логическое имя файла в базе данных, которое можно получить с помощью команды sp_helpdb ‘databaseName’, указав имя вашей базы данных.

 ФАЙЛ РЕЗЕРВНОЙ БАЗЫ ДАННЫХ TestBackup = 'TestBackup'
НА ДИСК = 'C:\TestBackup_TestBackup.FIL'

Создать резервную копию файловой группы SQL Server

Эта команда использует опцию «WITH FILEGROUP» для указания резервной копии файловой группы. Вам необходимо указать имя файловой группы из базы данных, которую можно получить с помощью команды sp_helpdb ‘databaseName’, указав имя вашей базы данных.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ TestBackup FILEGROUP = 'Только для чтения'
НА ДИСК = 'C:\TestBackup_ReadOnly.FLG'

Создать полную резервную копию SQL Server для нескольких файлов на диске

Эта команда несколько раз использует параметр «DISK» для записи резервной копии в три файла меньшего размера одинакового размера вместо одного большого файла.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks_1.BAK',
ДИСК = 'D:\AdventureWorks_2.BAK',
ДИСК = 'E:\AdventureWorks_3.BAK'
ВПЕРЕД

Создать полную резервную копию SQL Server с паролем

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

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
С ПАРОЛЕМ = '[электронная почта защищена]#R$'

Создать полную резервную копию SQL Server со статистикой выполнения

Эта команда создает полную резервную копию, а также отображает ход резервного копирования. По умолчанию прогресс отображается через каждые 10%.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
СТАТИСТИКА

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

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
СО СТАТИСТИКОЙ = 1

Создайте резервную копию SQL Server и дайте ей описание

Эта команда использует параметр описания, чтобы дать резервной копии имя. Позже это можно использовать с некоторыми командами восстановления, чтобы увидеть, что содержится в резервной копии. Максимальный размер — 255 символов.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks. BAK'
WITH DESCRIPTION = 'Полная резервная копия для AdventureWorks'

Создать зеркальную резервную копию SQL Server

Этот параметр позволяет создавать несколько копий резервных копий, предпочтительно в разных местах.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
ЗЕРКАЛО НА ДИСК = 'D:\AdventureWorks_mirror.BAK'
С ФОРМАТОМ

Указание нескольких параметров для резервных копий SQL Server

В следующем примере показано, как можно использовать несколько параметров одновременно.

 РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks
НА ДИСК = 'C:\AdventureWorks.BAK'
ЗЕРКАЛО НА ДИСК = 'D:\AdventureWorks_mirror.BAK'
С ФОРМАТОМ, СТАТИСТИКОЙ, ПАРОЛЕМ = '[электронная почта защищена]#R$'

Рекомендации по резервному копированию и восстановлению SQL Server

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

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

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

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

Полная резервная копия

Полная резервная копия — это полная резервная копия базы данных SQL Server. Он выполняет резервное копирование всех объектов базы данных: таблиц, процедур, функций, представлений, индексов и т. д.

Вы можете создать полную резервную копию базы данных SQL Server с помощью SQL Server Management Studio, Transact-SQL или PowerShell (Microsoft предлагает подробное руководство здесь). Однако если вы хотите упростить управление резервным копированием, а также использовать облачное или гибридное хранилище резервных копий, узнайте, как MSP360 Backup может помочь вам в этой статье:

Дальнейшее чтение Резервное копирование базы данных SQL Server с помощью MSP360

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

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

Дифференциальная резервная копия

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

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

Узнайте больше о дифференциальном резервном копировании и узнайте, как его выполнять с помощью встроенных инструментов SQL Server и резервного копирования MSP360 в этой статье:

Дальнейшее чтение Дифференциальное резервное копирование SQL Server

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

БЕСПЛАТНЫЙ ТЕХНИЧЕСКИЙ ДОКУМЕНТ

Руководство по типам резервного копирования

Какой тип резервного копирования подходит для ваших нужд?
Узнайте из нашего технического описания:

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

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

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

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

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

Восстановление на момент времени

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

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

Модели восстановления SQL Server

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

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

Simple Recovery

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

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

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

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

Полное восстановление

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

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

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

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

Восстановление с массовым протоколированием

Модель Восстановление с массовым протоколированием аналогична модели полного восстановления, за исключением того, что некоторые массовые операции не полностью регистрируются в журнале транзакций (это называется минимальным ведением журнала). Такие операции, как SELECT INTO, BULK import и TRUNCATE, являются примерами минимально регистрируемых операций. При использовании модели восстановления с неполным протоколированием ваши журналы транзакций могут быть не такими большими, как в модели полного восстановления.

Недостатком, однако, является то, что операции с неполным протоколированием в этой модели не позволяют выполнить восстановление на определенный момент времени. Таким образом, существует вероятность большей потери данных. Если вы не уверены, что Bulk-Logged — это подходящая модель восстановления для ваших нужд, рекомендуется придерживаться полного восстановления.

Резервное копирование и восстановление SQL Server с помощью MSP360

MSP360 предлагает простое в использовании и надежное решение для резервного копирования и восстановления базы данных SQL Server.

Сжатие и шифрование

Сжатие позволяет сократить объем памяти (и тем самым сэкономить деньги) при одновременном сокращении времени резервного копирования.