Резервные копии журналов (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 .
Резервные копии 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 и управлению
Take tail log backup before restore что это
Модель восстановления — Полная. Имеется Полная резервная копия базы. При попытке восстановления выпадает ошибка System.Data.SqlClient.SqlError: Инструкцию BACKUP LOG невозможно выполнить, так как не существует резервной копии текущей базы данных. (Microsoft.SqlServer.SmoExtended)
Подскажите, что может быть?
PS Восстанавливаю через Management Studio.
Первый раз восстанавливаешь? Тогда что-то не так сделал.
Телепатирую: у вас файл не фулл бекапа, а дифф.
Наверное, включена опция «Take tail-log backup before restore»
(3) При создании резервной копии?
(3)
Провёл восстановление своей базы при указанных параметрах (полная модель восстановления). Всё отлично и на MS SQL 2005, 2008, 2012.
Может быть проблема в том, что восстанавливается бэкап от старшей версии MS SQL на младшей (т.е. бэкап, сделанный в 2012 на, допустим, 2005ом)?
(1) У себя на копии делал раньше — все нормально восстанавливалось.
(6) Наоборот на 14 восстанавливаю копию, созданную на 2008, но я так делал уже.
Непонятно причём тут BACKUP LOG, если делается наоборот восстановление?
скрипт сюда выложи
(4) При восстановлении естественно.
(5) А я говорю Дифф.
Не, при диффе должна быть другая ошибка.
(12) Выложи, пожалуйста, скриншоты.
(14) Скриншот чего, я через Мэнэджмент Студио загружаю, вот полное описание ошибки, сейчас покажу окно настройки копирования
===================================
Ошибка восстановления базы данных «Aksol_UPP». (Microsoft.SqlServer.Management.RelationalEngineTasks)
в Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.PerformTask(ITaskExecutionContext context)
в Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.Perform(ITaskExecutionContext context)
в Microsoft.SqlServer.Management.TaskForms.TaskExecutionManager.ExecuteTaskSequence(ISfcScriptCollector collector)
System.Data.SqlClient.SqlError: Инструкцию BACKUP LOG невозможно выполнить, так как не существует резервной копии текущей базы данных. (Microsoft.SqlServer.SmoExtended)
в Microsoft.SqlServer.Management.Smo.RestorePlan.Execute()
в Microsoft.SqlServer.Management.RelationalEngineTasks.RestoreDatabaseTaskFormComponent.PerformTask(ITaskExecutionContext context)
Резервное копирование и восстановление базы данных в MS SQL Server
26.02.2020
insci
SQL Server
комментариев 16
В этой статье мы рассмотрим, как настроить резервное копирование баз данных в 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”.
Выберите операции, которые нужно сделать в этом плане обслуживания:
- Back Up Database (Full)
- Back Up Database (Transaction Log)
Используйте следующую последовательность операций:
Выберите базу данных 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
Рекомендации и best practice по резервному копированию SQL Server
- Резервные копии не должны храниться на том же диске, что и ваш SQL Server. Это правило касается любых резервных копий. При выходе из строя основного дискового массива вы должны иметь доступ к вашим резервным копиям. Если позволяют ресурсы, лучше хранить резервные копии сразу на нескольких разрозненных массивах.
- Процесс резервного копирования должен минимально влиять на работу пользователей. Полные резервные копии лучше делать тогда, когда пользовательская активность на сервере минимальна.
- Регулярно проверяйте целостность резервных копий и проводите тестовые восстановления. Вы всегда должны быть уверены, что ваши бекапы валидны и готовы к восстановлению в любое время.
- Заранее рассчитайте время, необходимое для полного восстановления при аварии. Часто в базах хранится критически важная для бизнеса информация, поэтому ваш руководитель должен знать минимальное время, которое потребуется для восстановления после аварии. Если даже вас об этом не спрашивают, лучше заранее уведомить об этом, чтобы в случае аварии не возникло недопонимания.
Предыдущая статья Следующая статья 
Восстановление базы данных из резервной копии в 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) можно указать дополнительные параметры резервного копирования. В частности:
- Флаг «Перезаписать существующую базу данных (WITH REPLACE)» (Overwrite the existing database) указывает, что операция восстановления перезапишет файлы любой базы данных, в настоящее время использующей имя, указанное в качестве базы данных назначения.
- Флаг «Сохранить параметры репликации (WITH KEEP_REPLICATION)» (Preserve the replication settings) сохраняет настройки репликации при восстановлении опубликованной базы данных на сервере, отличном от сервера, на котором была создана база данных. Этот параметр имеет значение, только если во время создания резервной копии проводилась репликация базы данных.
- Флаг «Ограничение доступа к восстановленной базе данных (WITH RESTRICTED_USER)» (Restrict access to the restored database) ограничит доступ к базе данных, за исключением пользователей с правами db_owner, dbcreator или sysadmin. Данный параметр имеет смысл использовать, например, если необходимо последовательно восстановить базу из нескольких файлов резервных копий, и доступ пользователей необходимо ограничить до завершения всех операций по восстановлению данных.
- Если оставить флаг «Создание резервной копии заключительного фрагмента журнала перед восстановлением» (Take tail-log backup before restore) то будет создана резервная копия заключительного фрагмента журнала транзакций. Если для точки во времени, выбранной в окне «Временная шкала резервного копирования» (Backup Timeline) требуется резервная копия заключительного фрагмента журнала, этот флажок будет установлен и снять его будет нельзя.
- Флаг «Закрыть существующие соединения» (Close existing connections option) переводит базу данных в однопользовательский режим перед началом выполнения процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.
- Ну и наконец, флаг «Выдавать приглашение перед восстановлением каждой резервной копии» ( Prompt before restoring each backup ) указывает, что после восстановления каждой резервной копии будет выводиться диалоговое окно с вопросом, нужно ли продолжать последовательность восстановления. Этот параметр позволяет приостанавливать последовательность восстановления после восстановления каждой резервной копии. Он будет полезен, например, когда нужно поменять ленты в устройстве, если на сервере имеется только одно ленточное устройство.
Когда все необходимые параметры установлены нажимаем «ОК» для запуска процесса восстановления базы данных. После того, как все операции по восстановлению будут завершены увидим соответствующее уведомление.
2. Просмотр информации о событиях резервного копирования и восстановления для базы данных
Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).
Сформировавшийся отчет содержит в себе следующие данные:
- Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
- Успешные операции резервного копирования (Saccessful Backup Operations)
- Ошибки операции резервного копирования (Backup Operation Errors)
- Успешные операции восстановления (Saccessful Restore Operations)
Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.
Помогла ли Вам данная статья?
Смотрите также:
Добавление базы данных в Microsoft SQL Server 2012 Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…
Перемещение базы данных tempdb в MS SQL Server Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…
Создание резервной копии базы данных в MS SQL Server 2012 Ниже будет подробно рассказано о том, как создать резервную копию базы данных в MS SQL Server 2012. В младших версиях (например в MS SQL Server 2008) алгоритм получения резервной копии…
Запись опубликована в рубрике Microsoft SQL Server 2012 с метками Backup, SQL. Добавьте в закладки постоянную ссылку.