Резервное копирование данных в MySQL. Резервное копирование mysql базы данных

Майкл Вандайн (Michael Vandine), главный технический консультант

Введение

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

Восстановление баз данных - это ответ администраторов данных на закон Мэрфи. Базы данных неизбежно повреждаются или теряются по разным причинам: из-за системных или аппаратных сбоев, ошибок операторов, неправильных или недопустимых данных, программных ошибок, компьютерных вирусов и природных катаклизмов.

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

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

1. Резервное копирование данных в объеме, достаточном для возвращения базы данных к согласованному состоянию, вне зависимости от ее текущего состояния.
2. Регистрация транзакций и изменений базы данных.
3. Восстановление базы данных с достаточным количеством возможностей для ее приведения в исходное рабочее состояние, с минимальными потерями данных и времени.

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

Резервное копирование баз данных

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

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

Резервирование может быть осуществлено либо в режиме онлайн, используя ПО резервного копирования SQLBase (сервер SQLBase запущен, а пользователи подключены к базе данных), либо в режиме оффлайн с помощью стандартных команд операционной системы, т.е. используя COPY (отключен сервер SQLBase либо демонтирована база данных), а затем команду "set nextlog". Наиболее часто используемый вариант - резервирование в режиме онлайн, поскольку для большинства операций очень сложно найти подходящее время, когда все пользователи отключены от всех баз данных, с тем чтобы можно было корректно завершить работу сервера SQLBase или демонтировать все базы данных. Это необходимо, потому что сервер SQLBase удерживает базу данных в виде открытого файла, начиная с момента подключения первого процесса и заканчивая демонтажем базы данных или выключением сервера SQLBase.

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

Следует обратить внимание, что база данных состоит из файла с расширением DBS и log-файлов. В случае удаления log-файлов база данных становится недоступной для использования! По умолчанию SQLBase автоматически удаляет log-файлы после их резервирования, или когда они не нужны для восстановления после сбоев или отката. Это поведение можно изменить, установив для базы данных параметр LOGBACKUP в положение ON с помощью интерфейса SQLTalk. При таком положении параметра log-файлы сохраняются до тех пор, пока не создается их резервная копия с помощью специальной команды "backup logs". Это единственный способ удаления log-файлов. Этот параметр должен находится в положении ON, если необходимо применить команды "backup database" или "backup logs". И наоборот, не нужно устанавливать этот параметр в данное положение, если нет намерений использовать команду "backup logs" или внедрять возможность "rollforward" (восстановление с повтором всех завершенных транзакций) в стратегию восстановления, т. е. если предполагается делать только "моментальные снимки".

Максимальный размер log-файлов, создаваемых для каждой базы данных, можно указать, задав параметр LOGFILESIZE с помощью SQLTalk (по умолчанию этот размер - 1 МБ). Сначала log-файлы имеют минимальный размер, а затем они растут в объеме до указанного предела. Если с помощью SQLTalk установить параметр LOGFILEPREALLOC в положение ON, то есть возможность создавать для каждой базы данных шаблоны log-файлов максимального размера. Если необходимо много log-файлов, можно установить их максимальный объем большим (скажем 5 МБ) и заранее назначить размер файлов. Это приведет к уменьшению числа операций ввода/вывода, необходимых для создания новых файлов или дописывания существующих.

Log-файлы могут быть удалены только после применения команды "release log" или "backup logs", и если они не являются "блокированными". Log-файл оказывается блокированным в следующих случаях:

1. Текущая транзакция осуществляет запись в этот log-файл. Блокировка может быть снята с этого файла только после завершения или отката транзакции.
2. Предпоследняя контрольная точка была создана при использовании данного или предыдущего log-файла. Например, если контрольная точка была создана в 6.log, то этот log-файл и все последующие будут блокированы. В этом случае блокировку можно снять с помощью команды "release log".
3. Параметр LOGBACKUP находится в положении ON, а у данного log-файла еще нет резервной копии. Блокировка с него может быть снята только с помощью команды "backup logs". Исполнение команды "backup snapshot" никак не отразится на блокировке этого log-файла.

Log-файлы, для которых была сделана резервная копия, должны регулярно удаляться вручную. Сохраняются только log-файлы, имеющие прямое отношение к BKP-файлу в области резервного копирования. Например, если в какой-то день создается резервная копия в виде моментального снимка, то все предыдущие резервные копии log-файлов могут быть удалены. Будьте внимательны: эти файлы могут занимать значительный объем дискового пространства.

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

Существует два основных варианта резервирования в режиме онлайн. Первый соответствует использованию команды "backup snapshot" (закончен сам по себе), и второй - последовательному применению команд "backup database", "release log" и "backup logs" (они все необходимы для согласованного резервирования).

Независимо от выбранного варианта, резервное копирование состоит из следующей последовательности шагов:

Создание BKP-файла в избранной области резервного копирования (backup database);
- обновление самых последних log-файлов, поскольку в них содержится вся информация о текущем резервировании (release log);
- копирование всех надлежащих разблокированных log-файлов, предшествующих текущему log-файлу, в избранную область резервного копирования (backup logs).
В случае использования метода моментальных снимков (backup snapshot) все эти шаги выполняются автоматически.

При выполнении резервирования пунктом назначения данных может служить клиентский компьютер или сама сеть. Это указывается в ключе "directory-name" команды резервного копирования. Также необходимо хорошо представлять себе разницу между ключами "on server" и "on client" этой команды. При использовании ключа "on client" все данные и log-файлы будут помещены в указанный каталог определенного компьютера (даже если это сетевой сервер). Использование ключа "on server" приведет к резервированию прямо на сервере без предварительного сохранения данных на клиентском компьютере. Это может привести к значительному выигрышу в скорости резервного копирования и сокращению сетевого трафика!

Если используется ключ "on client", т.е. данные сохраняются на клиентском компьютере, каталог должен быть задан полным локальным путем либо в виде сетевого диска, например, C:\SQLBASE\BACKUPS\DB1 (локальный путь) или F:\BACKUPS\DB1 (сетевой диск). Однако, при применении ключа "on server" указываемый диск должен быть локальным для сервера, а не сетевым. Если используется сервер Novell, то путь к нужному каталогу должен быть указан в формате сервера Novell. Например, если резервное копирование базы данных производится в каталоге:

SERVER1\SYS:SQLBASE\BACKUPS\DB1

моментальный снимок базы данных DB1 может быть сделан следующим образом:

BACKUP SNAPSHOT FROM DB1 TO \SQLBASE\BACKUPS\DB1 ON SERVER;

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

Создание моментальных снимков (команда backup snapshot) - самый простой метод резервного копирования баз данных. В этом случае копируются база данных и log-файлы, необходимые для восстановления базы данных до согласованного состояния. Перед резервированием log-файлов проводится их обновление, что позволяет включить в резервную копию текущий активный log-файл. В этом варианте резервного копирования требуется одна команда для резервирования данных и одна для их восстановления. Обычно этот метод применяется один раз вечером, перед резервным копированием сервера на магнитную ленту, и, может быть, один раз в течение дня. Недостаток этого метода заключается в том, что создание моментальных снимков очень большой базы данных может потребовать значительных затрат времени, и, кроме того, варианты восстановления ограничены возвращением базы данных в состояние на момент формирования последнего моментального снимка. Любые изменения, сделанные после данного снимка, будут потеряны.

Этот метод резервного копирования данных несколько более сложен, но гибкость восстановления стоит дополнительных усилий. Он требует резервного копирования файла базы данных, разблокирования log-файла (поскольку тот содержит информацию о текущей резервной копии), а затем резервирования log-файлов. Внимание! Никогда не делайте резервной копии только одной базы данных без log-файлов. Этот метод резервного копирования позволяет изредка резервировать базу данных вместе с ее log-файлами, после чего регулярно создавать резервные копии только одних log-файлов, например, несколько раз в день. Это позволяет провести восстановление базы данных, а затем использовать возможность "rollforward" log-файлов для восстановления работы, выполненной в течение дня. То, насколько часто создаются резервные копии log-файлов, зависит от объема доступного пространства на диске и от того, какое количество данных пользователь может себе позволить потерять. Заметим: накопление log-файлов может привести к очень быстрому заполнению диска. Такой подход особенно удобен для больших баз данных, поскольку резервное копирование файла базы данных, отнимающее много времени, выполняется редко, а периодическое создание резервных копий log-файлов можно выполнить достаточно быстро. Недостатком метода является скапливание log-файлов до их резервирования.

В прошлом любую базу данных SQLBase размера больше 2 ГБ было необходимо разбивать на части. Начиная с SQLBase версии 7.5.0, это ограничение было поднято для баз данных на всех операционных системах, за исключением семейства Novell. Теперь их размер может расти до 256 ГБ без необходимости разбиения. Впрочем, это ограничение действует только для DBS-файла, а не временных файлов или с расширением.bkp. Чтобы справиться с таким ограничением, был введен новый метод сегментированного резервного копирования.

Сконфигурируйте контрольный файл и положите в тот же каталог, где сохраняются резервные копии. Не нужно вносить какие-либо изменения в операторы резервного копирования или запущенные программы. Сервер SQLBase находит контрольный файл в целевом каталоге и сегментирует резервную копию соответствующим образом. Контрольный файл имеет расширение.bcf, а его имя совпадает с названием резервируемой базы данных. Для создания этого файла можно использовать любой редактор текстовых файлов (например, notepad.exe).

Контрольный файл имеет следующий формат:

FILEPREFIX префикс
DIR каталог, куда помещается резервная копия сегмента
SIZE размер в МБ

Можно указать несколько операторов DIR, чтобы разбить базу данных на сегменты, каждый из которых меньше 2 Гбайт. Заметим, что суммарный объем, задаваемый всеми операторами SIZE, должен быть достаточно большим, чтобы позволить сделать резервную копию всей базы данных. Например:

FILEPREFIX MIKE
DIR C:\BACKUPS\MIKE SIZE 1000
DIR C:\BACKUPS\MIKE SIZE 1000
DIR C:\BACKUPS\MIKE SIZE 500

позволяет создать три файла в каталоге C:\BACKUPS\MIKE:

MIKE.1 1 ГБ
MIKE.2 1 ГБ
MIKE.3 0,5 ГБ

Обратите внимание на то, что эти файлы создаются, только если база данных требует столько места. В приведенном выше примере, если бы размер базы данных составлял лишь 1,8 ГБ, то были бы созданы лишь два сегмента: MIKE.1 и MIKE.2 размером 1 ГБ и 0,8 ГБ, соответственно.

Можно использовать: предоставляемый компанией Gupta интерфейс SQLTalk для выполнения команд, показанных выше; продукт SQLConsole (использует вызовы C/API), чтобы планировать создание резервных копий; собственное программное обеспечение, которое при резервировании учитывает все возможные особенности конкретной системы, например, проводит проверку базы данных перед резервным копированием.

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

Выше были рассмотрены основные моменты и рекомендации по проведению резервного копирования в режиме онлайн. Сделаем их краткий обзор:

1. Выполняйте проверку базы данных ("check database") перед ее резервированием. Если проверка обнаружила ошибки в базе данных, не записывайте ее резервную копию поверх неповрежденной копии.
2. Если не предполагается создать моментальный снимок, проверьте последовательность резервного копирования, т.е. порядок следования команд ""backup database", "release log" и "backup logs".
3. Чтобы сэкономить время, по возможности используйте ключ "on server"!
4. При использовании ключа "on server" на сервере Novell, путь к целевому каталогу должен быть указан в формате сервера Novell, а не в виде сетевого диска.
5. Не удаляйте НИКАКИЕ log-файлы из текущего каталога их хранения, задаваемого утверждением logdir= в конфигурационном файле сервера под названием sql.ini (или утверждение dbdir=, если logdir= не определено).
6. Периодически удаляйте из области резервного копирования старые log-файлы, чтобы освободить пространство на диске. Не стирайте файлы, относящиеся к текущему BKP-файлу. Безопасным является удаление из области резервного копирования любых log-файлов, которые были созданы раньше текущего BKP-файла.
7. Если параметр LOGBACKUP находится в положении ON и используется команда "backup snapshot", log-файлы не будут разблокированы. Чтобы добиться этого, выполните команду "backup logs".
8. Не помещайте резервные копии в подкаталог самой базы данных.
9. Если во время создания резервной копии в виде моментального снимка была произведена перезагрузка клиентского компьютера, то при попытке повторного резервирования базы данных может появиться сообщение о том, что резервное копирование уже находится в процессе выполнения. Это может произойти при подключении к серверу до завершения предыдущего сеанса. Возникшее затруднение можно преодолеть, завершив прерванный сеанс с помощью SQLConsole или перезапуска сервера SQLBase.

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

Для создания резервных копий DBS-файла базы данных и всех log-файлов из ее каталога, используйте команды или утилиты операционной системы (например, команду "copy" или средства ARCServe). Если параметр LOGBACKUP находится в положении OFF, log-файлы копироваться не будут. Однако, если он находится в положении ON, необходимо сообщить серверу SQLBase, были ли log-файлы резервированы или они останутся "блокированным". Это можно сделать с помощью команды "nextlog" из арсенала интерфейса SQLTalk от Gupta. Для этого требуется быть подсоединенным к базе данных. Используется следующий формат:

SET NEXTLOG [целое число]

Заданное число указывает следующий резервируемый log-файл. Например, если последними в архив были отправлены резервные копии 4.LOG и 5.LOG, нужно выполнить команду "set nextlog 6".

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

Восстановление базы данных

Здесь описываются различные варианты восстановления базы данных до согласованного состояния на основе выбранных настроек резервного копирования.

Комплект восстановления состоит из резервных копий BKP-файла и связанных с ним log-файлов. BKP-файл бесполезен без ассоциированных log-файлов. Процесс восстановления, по существу, проходит в три этапа:

1. Скопируйте BKP-файл в каталог базы данных.
2. Скопируйте log-файлы в каталог базы данных.
3. Запустите двухходовой (redo и undo) процесс rollforward (восстановление с повтором всех завершенных транзакций) в отношении нового DBS-файла.

Команда восстановления имеет следующий формат:

В случае использования команды "restore snapshot", дальнейшие действия не требуются, поскольку все этапы восстановления будут выполнены автоматически. При выборе варианта "restore database" после восстановления базы данных нужно выполнить команду "rollforward". Следует отметить, что, как и в фазе резервного копирования, при использовании ключа "on server" (при котором время восстановления значительно сокращается) на сервере Novell, путь к целевому каталогу должен быть указан в формате сервера Novell, а не в виде сетевого диска. Процесс rollforward заключается в восстановлении всех изменений, сделанных после резервирования базы данных, чтобы привести ее в согласованное состояние. Log-файлы содержат информацию обо всех транзакциях, как успешных, так и тех, для которых был произведен откат. В процессе rollforward обращение к log-файлам происходит дважды. Во время прохода "redo" SQLBase локализует начальную точку всех транзакций и применяет все успешные транзакции к данной резервной копии. В проходе "undo" происходит обращение всех транзакций, для которых производился откат. В конце процесса отката база данных находится в полностью согласованном состоянии без незавершенных транзакций. Команда "rollforward" имеет следующий формат:

При использовании команды "rollforward to backup" будет восстановлена вся работа, совершенная вплоть до момента создания резервной копии базы данных. Это эквивалентно исполнению команды "restore snapshot". При этом не восстанавливаются никакие дополнительные log-файлы, которые могли быть резервированы после создания исходной резервной копии.

Команда "rollforward to time" позволяет восстанавливать данные до определенного момента времени. Это очень хорошо подходит для отката значительного объема ошибочно сделанных изменений. Например, если какой-нибудь новый неосторожный программист удалил половину базы данных и зафиксировал это изменение, то ее можно восстановить до состояния на момент удаления с помощью резервной копии и процесса rollforward.

В результате команды "rollforward to end" обрабатываются все log-файлы с последовательными номерами, начиная с первого файла от момента создания резервной копии. В этом случае восстанавливается максимально возможный объем работы. После обработки последнего log-файла появится сообщение о том, что следующий log-файл не может быть найден. Это нормально! Просто выполните команду "rollforward end", чтобы завершить восстановление и процесс rollforward.

Обратите внимание, что необходимо иметь и последовательно использовать ВСЕ log-файлы, чтобы откат был успешным. Если какие-либо log-файлы потеряны, операция rollforward будет остановлена в ожидании пропущенных файлов. Если это возможно, можно применить команду "restore logs", чтобы сделать нужные log-файлы доступными, а затем использовать команду "rollforward continue", чтобы продолжить процесс. Если какой-то из необходимых log-файлов недоступен, примените команду "rollforward end" для завершения процесса. База данных будет восстановлена только с учетом последнего обработанного log-файла.

Пара советов, на что нужно обратить особое внимание при проведении восстановления базы данных:

1. После завершения исполнения команды "restore snapshot" может появиться сообщение "cannot connect to the database" (не удается подключиться к базе данных). По существу, это проблема синхронизации. После завершения восстановления старая база данных удаляется, BKP-файл копируется из каталога резервного копирования в каталог базы данных и устанавливается. После этого процесс восстановления пытается подсоединиться к базе данных для обработки log-файлов. Если система загружена или сервер SQLBase слишком медленно работает, чтобы вовремя обработать сообщение об обновлении установки базы данных, процесс восстановления не может к ней подключиться. Решением этого затруднения является увеличение значения параметра CONNECTTIMEOUT в секции маршрутизатора (router) конфигурационного файла sql.ini. Этот параметр указывает время ожидания (в секундах) после неудачного подключения к серверу перед следующей попыткой соединения. Например, если для успешного подключения к базе данных нужно задать параметру CONNECTTIMEOUT значение 20, создайте в секции маршрутизатора строку со значением: connecttimeout=20.
2. Наличие одного только BKP-файла без log-файлов означает большую проблему. Тем не менее, и в этом случае можно попытаться что-то сделать. Иногда это работает, но ничего нельзя гарантировать. Предположим, что база данных называется MIKE.BKP. Используя SQLTalk, выполните команду задания имени сервера (set server), а затем сделайте следующее:

RESTORE DATABASE FROM [путь к каталогу резервных копий] ON SERVER TO MIKE;

Появится сообщение <> (База данных восстановлена. Используйте команду rollforward для завершения восстановления).

ROLLFORWARD MIKE TO BACKUP; (Заметим, что "to backup" - похоже, единственная опция, которая может сработать)
Возникнет сообщение <> (Вначале необходимо восстановить базу данных).

ROLLFORWARD MIKE TO BACKUP; (Да, исполните эту команду еще раз!) Будет выдано сообщение <> (Процесс rollforward завершен).

CONNECT MIKE 1 username/password;
Появится сообщение <> (Установлено соединение с базой данных MIKE).
Проведите проверку базы данных (команда "check database"), чтобы узнать о ее состоянии.

Сценарии

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

Ниже приведены несколько сравнений различных методов резервного копирования, чтобы дать представление о требованиях к дисковому пространству и возможностях восстановления. Предполагается следующее: стандартный размер log-файла - 1 МБ, их отсчет начинается с 1.LOG, для всех log-файлов созданы шаблоны максимального размера и все транзакции завершены до создания резервных копий.

Если в этот момент произошел отказ системы, возможности восстановления будут доступны только для предыдущей резервной копии. Восстановление последних трех log-файлов транзакций невозможно, так как нарушена непрерывность последовательности log-файлов (файлы 1-7 в области базы данных были разблокированы, поскольку транзакции были завершены и не нуждались в восстановлении после сбоя или в откате).

После моментального снимка:

Область базы данных Область резервного копирования

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

Заметим, что все log-файлы находятся в области базы данных до их резервирования командой "backup logs", даже если все транзакции были завершены.

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

Если в этот момент произошел отказ системы, возможности восстановления доступны для самой последней транзакции путем восстановления BKP-файла, обработки сначала log-файлов 1-4 из области резервного копирования, а затем файлов 5-8 из области базы данных.

_____________________________________________
После завершения методов "release log" и "backup logs"

Заметим, что ни один log-файл из области резервного копирования не предназначен для удаления, поскольку они ВСЕ должны быть использованы вместе с DB1.BKP из той же области, чтобы сделать его согласованным с файлом DB1.DBS из области базы данных.

Заметим, что раз были созданы резервные копии базы данных и log-файлов, log-файлы 1-10 из области резервного копирования могут быть разблокированы, поскольку новый BKP-файл должен содержать все соответствующие транзакции, а дата и время их создания будут более ранними, чем у файла DB1.BKP.

Заключение

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

Для целостности ИТ инфраструктуры крайне важно обеспечить правильное резервное копирование базы данных. Как правило, при этом важно соблюдать требования политики безопасности. Реализованные на базе плагинов для СУБД передовые решения Bacula Systems позволят любой компании-пользователю Bacula Enterprise быстро и надежно производить резервное копирование баз данных.

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

Резервное копирование базы данных Oracle

Упрощает процедуры резервного копирования и восстановления баз данных Oracle. Администраторы БД Oracle могут воспользоваться командами RMAN с целью более простого и удобного резервного копирования базы данных. Помимо скорости и простоты, плагин для Oracle существенно оптимизирует прочие важные функции, в том числе восстановление БД на любой момент времени, а также фильтр объектов во время резервного копирования и восстановления. Все эти возможности доступны при использовании любого из двух методов резервного копирования, а именно “Dump” метода и метода восстановление до заданной контрольной точки (PITR) с помощью тесной интеграции плагина с диспетчером восстановления Oracle RMAN.

Плагин также задействует RMAN API sbt, что позволяет исключать запись файлов в первую очередь на локальные диски. И в режиме “Dump”, и в режиме RMAN плагин создает резервную копию значимой информации, что является бест-практикой администрирования Oracle DB. Как правило, методы “Dump” и RMAN PITR используются совместно для резервного копирования одного и того же кластера.

Повышение эффективности инкрементального и дифференциального резервного копирования Oracle
​

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

​
Восстановление данных Oracle
​

Как показано на рисунке ниже, плагин для Oracle позволяет восстанавливать БД с помощью утилит RMAN или используя метод Dump.

​Поддерживаемые версии платформы Oracle для бэкапа​​

Плагин доступен для 32 и 64-битной версии Linux и совместим с БД Oracle версий 10.x, 11.x.

Резервное копирование и восстановление PostgreSQL​​​

Был разработан с целью упростить процедуры резервного копирования и восстановления кластеров БД PostgreSQL. Администратору не нужно знать внутренние методы резервного копирования PostgreSQL или процедуры написания сложных скриптов. Плагин автоматически создает резервную копию значимой информации, например, конфигурации БД, определений пользователей, табличных пространств. Плагин для PostgreSQL поддерживает два метода создания резервных копий “Dump” и PITR.

Используя уникальную технологию включения последних данных Late Data Inclusion (LDI) от компании Bacula Systems, данный плагин эффективно захватывает данные вплоть до момента завершения создания бэкапа, тем самым, сводя к минимуму риск их потери. Это является преимуществом плагина по сравнению с решениями других вендоров.

​Горячее резервное копирование базы данных PostgreSQL​​​​

Плагин Bacula Systems для PostgreSQL также позволяет администратору БД создавать бэкапы серверов PostgreSQL в режиме «горячего резервного копирования» с резервным копированием WAL файлов.

​Восстановление PostgreSQL​​​

Содержимое кластера

Содержимое базы данных

Поддерживаемые версии платформы PostgreSQL для бэкапа

​​Резервное копирование базы данных PostgreSQL доступно используется под 32 и 64-битные версии Linux и поддерживает PostgreSQL версий: 8.4, 9.0, 9.1 и 9.2. Работает на базе ПО Bacula Enterprise версии 6.0.6 и выше.

Резервное копирование и восстановление базы данных MySQL

Был разработан с целью упростить процедуры резервного копирования и восстановления серверов MySQL. Администратору не нужно знать внутренние методы резервного копирования MySQL или процедуры написания сложных скриптов. Плагин конфигурируем и автоматически создает бэкапы значимой информации, например, конфигурации БД и определений пользователей. Плагин для MySQL поддерживает два метода создания резервных копий “Dump” и “Binary”.

Возможность выбора методики резервного копирования базы данных MySQL​

Позволяет администратору выбирать метод Dump или Binary для более быстрого резервного копирования и создания больших по объему бэкапов. Плагин для MySQL обрабатывает лог-файлы MySQL при использовании функции создания PITR бэкапов.

Восстановление данных БД MySQL​

Восстановление единичной БД MySQL

Поддерживаемые версии платформы MySQL для бэкапа​

​Резервное копирование и восстановление базы данных MySQL доступно под 32 и 64-битные версии Linux и поддерживает MySQL версий 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.
​

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

​VSS плагин – один из двух способов резервного копирования базы SQL Server с помощью ПО Bacula Systems. Резервное копирование базы данных SQL Server через VSS плагин разработано для бэкапа нескольких специфических компонентов Windows, в частности базы SQL Server. Плагин Bacula Enterprise VSS существенно упрощает создание резервных копий БД SQL Server.
​

Быстрый и простой способ восстановления базы данных SQL​ Server

​VSS плагин способен восстанавливать либо master, либо прочие инстансы БД. Все БД, за исключением master, могут быть восстановлены во время работы MS SQL. VSS плагин также может быть использован совместно с процессом перемещения БД MS SQL.

Дерево SQL сервера во время восстановления

Перемещенная БД

Поддерживаемые версии резервного копирования базы данных SQL

Резервное копирование базы данных SQL осуществляется под Windows 2003 SP1 и выше, Windows 2008 R1 и Windows 2008 R2.

Резервное копирование базы данных SQL — расширенные возможности

– это современное решение для создания резервных копий множества БД MS SQL, позволяющий:

• Осуществлять полное резервное копирование, при котором сохраняются файлы БД и лог-файлы транзакций, что позволяет избегать отказа системы хранения данных.
• При дифференциальном резервном копировании сохраняется только те данные, которые были изменены с момента создания последнего полного бэкапа. Плагин Bacula Enterprise для SQL Server включает интегрированные опции по повышению класса резервного копирования с дифференциального до полного если это необходимо.
• Создание инкрементальных бэкапов посредством резервного копирования логов транзакций. В случае конфигурации по соответствующей модели, данный метод позволяет использовать режим PITR.
• Резервное копирование master-БД для создания резервной копии информации о конфигурации MS SQL.

Мощный инструмент восстановления баз данных SQL​

Плагин Bacula Enterprise для SQL способен восстанавливать данные несколькими способами, в том числе с использованием восстановления до контрольной точки PITR. В таком случае процесс восстановления предполагает следующие сценарии:

• Восстановление файлов на диск
• Восстановление исходной БД
• Восстановление БД с новым именем
• Восстановление БД с новым именем и перемещением файлов

Модель создания бэкапа БД “с полным и неполным протоколированием”

Поддерживаемые версии платформы MS SQL для бэкапа

​Резервное копирование базы данных MS SQL возможно под Windows 2003 R2, Windows 2008 R2, Windows 2012 и для MS SQL Server 2005, 2008 и 2014.

Интересует резервное копирование базы данных с Bacula Enterprise и квалифицированная поддержка? Смотрите видео.​

Несмотря на то, что в наших предыдущих материалах мы уже касались вопроса резервного копирования баз 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 часов.

• Теги:

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

Неисправности аппаратного обеспечения

• Некорректное использование инструкций UPDATE и DELETE

  Ошибки программного обеспечения

  Аварийные ситуации, например, пожар или затопление

Чтобы избежать потери данных, можно реализовать для базы данных стратегию восстановления. Стратегию восстановления необходимо спланировать, реализовать и протестировать с учетом возможных неисправностей, с которыми можно встретиться в процессе работы системы, и необходимого уровня защиты данных. В витринах данных, то есть в случаях, когда данные можно восстановить из других систем, вероятно, нет необходимости создавать резервные копии каждой отдельной транзакции. Возможно, будет достаточно выполнять полное резервное копирование данных с регулярными временными интервалами. И наоборот, для базы данных, в которой хранятся транзакции интернет-магазина, возможно, будет необходимо сохранять резервные копии каждой отдельной транзакции. СУБД SQL Server предоставляет полный комплекс функций для реализации именно того вида резервного копирования, который вам необходим. В данной лекции рассматриваются наиболее широко используемые в Microsoft SQL Server стратегии для защиты данных.

Полное резервное копирование базы данных

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

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

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

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

В следующем разделе мы рассмотрим варианты реализации этой стратегии резервного копирования.

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

Следует заранее уведомить SQL Server о том, какой тип резервного копирования вы намерены использовать, поэтому надо сконфигурировать базу данных так, чтобы настройки соответствовали выбранному вами типу резервного копирования. Такая настройка выполняется посредством выбора значения параметра "модель восстановления базы данных". Модель восстановления базы данных, которая используется по умолчанию, является производным от модели восстановления модели базы данных, определенной при ее создании. Чтобы реализовать стратегию резервного копирования, которая будет включать только полные резервные копии, следует выбрать простую модель восстановления (SIMPLE).

Выбираем модель восстановления SIMPLE

В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).

В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).

Чтобы задать модель восстановления, можно использовать инструкцию ALTER DATABASE. Введите текст следующей инструкции и нажмите кнопку Execute (Выполнить).

ALTER DATABASE AdventureWorks

SET RECOVERY SIMPLE;

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

Проверяем настройки модели аварийного восстановления

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

SELECT DATABASEPROPERTYEX("AdventureWorks","Recovery")

Убедитесь, что в результатах запроса указана модель восстановления SIMPLE.

Закройте окно среды SQL Server Management Studio.

Устройства резервного копирования

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

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

Дисковые устройства .Файлы на локальном или удаленном диске или дисковом накопителе. К этим файлам обращаются, указывая путь к файлу, в котором хранится резервная копия. Для обращения к удаленным хранилищам следует использовать путь в формате UNC.

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

Устройства резервного копирования идентифицируются по имени устройства. В качестве имени устройства может использоваться имя логического или физического устройства. Имя физического дискового устройства представляет собой путь к файлу резервной копии, например, "\\BACKUPSERVER\Backups\adv\AdventureWorks.bak". Этот путь можно включить непосредственно в инструкцию резервного копирования. Имя логического устройства представляет собой имя, указывающее на имя физического устройства резервного копирования и хранящееся в SQL Server. Когда в инструкции резервного копирования используется имя логического устройства, SQL Server осуществляет поиск соответствующего физического устройства в системном каталоге и выполняет резервное копирование, сохраняя резервную копию в указанной папке.

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

EXEC sp addumpdevice "disk", "AdvFullDbDev", "T:\BACKUPS\AdvFullDbDev.bak";

Совет . Обязательно измените путь к файлу, чтобы он соответствовал вашему компьютеру. Т:/, то измените эту часть пути к файлу в инструкции так, чтобы он соответствовал букве диска на вашем компьютере. Кроме того, убедитесь в том, что все папки, заданные в этом пути, существуют на вашем компьютере.

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

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

Совет . Сокращение RAID происходит от выражения "redundant array of independent disks" (избыточный массив независимых дисков). Такие массивы представляют собой системы дисков с несколькими приводами, которые используются для повышения доступности и емкости хранилища.

Выполнение полного резервного копирования базы данных

После того, как вы установили модель резервного копирования на SIMPLE и решили, на каком устройстве резервного копирования сохранять резервные копии, можно приступить к выполнению резервного копирования. Полное резервное копирование базы данных выполняется с помощью довольно простой инструкции BACKUP DATABASE. В простейшей форме нужно только указать системе, резервную копию какой базы данных создать и на каком устройстве ее сохранить. Чтобы создать резервную копию базы данных AdventureWorks на предварительно выбранном логическом устройстве, используется следующая инструкция T-SQL:

TO Adv_FullDb_Dev;

Если надо выполнить полное резервное копирование базы данных на физическое устройство, необходимо указать тип устройства и место размещения резервной копии в инструкцииBACKUP DATABASE. Чтобы создать резервную копию базы данных в папке t:\adv.bak, используйте следующую инструкцию:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak";

Как уже говорилось, на любом устройстве резервного копирования может храниться больше одной резервной копии. В аргументе инструкции BACKUP DATABASE можно указать, следует ли SQL Server перезаписать существующую резервную копию на этом устройстве или дописать ее к существующим резервным копиям. Для этого используются ключевые слова INIT илиNOINIT. Если указать INIT, то перед запуском резервного копирования устройство резервного копирования форматируется, при этом удаляются все резервные копии, которые имеются на этом устройстве. NOINIT, которое используется по умолчанию, если не указано иное, разрешает SQL Server дописать резервную копию на существующее устройство резервного копирования с сохранением всех существующих на нем резервных копий. Эти опции устанавливаются при помощи блока WITH в конце инструкции BACKUP DATABASE.

Если нужно создать такую же резервную копию, как в предыдущем примере, но при этом указать SQL Server сначала очистить устройство, используйте следующую инструкцию:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak"

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

Разностное резервное копирование

Главное преимущество полного резервного копирования базы данных заключается в том, что в полной резервной копии содержатся все данные, которые необходимы для восстановления базы данных полностью. Но это преимущество может одновременно быть и недостатком. Представьте себе базу данных, для которой каждую ночь создается резервная копия. Если придется восстанавливать базу данных, в любом случае придется использовать резервную копию, созданную прошлой ночью, и в результате будут потеряны результаты работы за целый день. Один из способов уменьшить потенциальный промежуток времени, который может быть не учтен резервным копированием является более частое выполнение полного резервного копирования базы данных. Но это само по себе является проблематичным. Поскольку все данные и фрагменты журнала транзакций записываются на устройство резервного копирования, выполнение резервного копирования может отнимать слишком много времени. Кроме того, для хранения всех этих резервных копий необходимо много дискового пространства h° , а полное резервное копирование может снизить производительность базы данных в результате потребности в большом объеме операций ввода/вывода. Не лучше ли будет один раз выполнить резервное копирование ночью, а затем выполнять резервное копирование только тех данных, которые были изменены в течение дня? Такие функциональные возможности предоставляет разностный тип резервного копирования.

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

Рис. 4.1. Стратегия резервного копирования с использованием разностных резервных копий

Выполнение разностного резервного копирования

Выполнение разностного резервного копирования мало чем отличается от выполнения полного резервного копирования. Единственное отличие заключается в том, что в блоке WITHобъявляются инструкции по создании разностной резервной копии. Синтаксис инструкции BACKUP DATABASE для выполнения резервного копирования базы данных Adventure Works на физическое устройство с перезаписью других существующих резервных копий на этом устройстве будет таким:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv_diff.bak"

WITH INIT,DIFFERENTIAL;

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

EXEC sp_addumpdevice "disk", "Adv_Diff_Dev",

"T:\BACKUPS\AdvDiffDev.bak";

BACKUP DATABASE AdventureWorks

TO Adv_Diff_Dev

WITH INIT,DIFFERENTIAL;

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

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

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

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

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

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

Рис. 4.2. Стратегия резервного копирования с использованием резервных копий журнала транзакций

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

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

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

Рис. 4.3. Комбинированная стратегия резервного копирования

Например, чтобы восстановить данные до резервной копии журнала транзакций Т3, следует восстановить данные полной резервной копии F1, разностной резервной копии D1 и резервной копии журнала транзакций Т3.

Интервал времени между созданием резервных копий журнала транзакций зависит от:

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

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

Копирование баз данных

Используемые базы данных делятся на две категории: 3 системные БД (oktell, oktell_cc_temp и oktell_settings) и БД для модулей веб-клиента Okapp. Для запуска Oktell после восстановления нужны только системные базы. Остальные БД нужны только, если вы хотите сохранить ваши настройки веб-модуля.

Например, база WO_Module_journal используется модулем Журнал хранит в себе теги записей разговоров. База WO_Module_dashboards нужна для работы модуля Дашборды Okboard и содержит настройки используемых индикаторов.

Шаг 1. Копии системных таблиц создаются автоматически каждый день, по умолчанию в 02:00 по серверному времени, если не отключен параметр DBAutoDailyBackup . Создание копий происходит особым образом, оставляя копии

• последние две недели - каждый день
• далее три месяца - раз в неделю
• далее два года - каждый месяц
• далее раз в год

Все копии находятся в папке \oktell\server\Backup, если не переопределено в параметре DBBackupDir .

В свою очередь, вы можете сделать резервные копии в любой момент. Для этого перейдите в Администрирование/Обшие настройки/Управление базами данных . Нажмите кнопку Произвести резервное копирование БД .

После окончания резервного копирования созданные бэкапы будут доступны в корне папки oktell\server\backup .

Шаг 2. Для созданий копий остальных баз данных откройте SQL Server Management Studio. Кликните правой кнопкой на нужной БД и в контекстном меню выберите Задачи, затем Создать резервную копию . В открывшемся окне вы можете поменять путь для создания бэкапа, для начала копирования нажмите ОК. Копии по умолчанию создается в папке C:\Program Files\Microsoft SQL Server\MSSQL11.OKTELL\MSSQL\Backup\ .

Восстановление баз данных

Восстановить базы данных можно только на такую же версию SQL-сервера или выше. Если базы были созданы на версии SQL Server 2008 R2, их нельзя восстановить на SQL Server 2008.

Шаг 1. Остановите службу oktellserver. Запустите командную строку с правами администратора и введите туда следующую строчку:

Net stop oktellserver

Шаг 2. Запустите SQL Server Management Studio с учетной записью sa:

• Login: sa
• Password: 123Oktell321

Шаг 3. Если у вас есть ранее установленные базы данных Oktell, то их нужно удалить. Это касается системных БД и БД, используемых веб-модулями.

Шаг 4. Приступаем к процедуре восстановления. Нажмите правой кнопкой на System Database (Системные базы данных) и нажмите Restore Database (Восстановить резервную копию).

Выберите файл с копией баз данных. Для этого выберите пункт Device (Устройство), в открывшемся окне Add (Добавить) и выберите ваш файл с резервной копией, например db_ok_130628.bak (в данном случае, это БД oktell).

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

Повторите тоже самое с остальными базами данных.

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

Шаг 6. Если вы перенесли базу данных на сторонний сервер, то проверьте настройки в серверном конфигурационном файле \oktell\server\oktell.ServerService.exe.config . Убедитесь что в строке с ключом DBConnectionString ссылка на базу данных, логин и пароль указаны верно. По умолчанию, строка подключения выглядит следующим образом:

Server=(local)\OKTELL;database=oktell;uid=AutelService;pwd=;pooling=true

Новое название сервера нужно указать вместо значения (local)\OKTELL . Например, SQL-сервер перенесен на сервер WORK с IP-адресом 192.168.0.3. Следовательно, в параметре вам нужно указать WORK\OKTELL . Если сервер не запускается с этой настройкой, попробуйте указать только название сервера без инстанса - WORK . Вместо названия сервера можно указать IP-адрес - 192.168.0.3/OKTELL или только 192.168.0.3 .

Если вы поменяли основную учетную запись AutelService, то необходимо указать новые логин и пароль в полях uid и pwd соответственно.

Узнать название вашего сервера (инстанс) вы всегда можете с помощью команды

Sqlcmd.exe -L

в командной строке Windows.

Шаг 7. Запустите службу oktellserver . Для этого в командной строке выполните