Майкл Вандайн (Michael Vandine), главный технический консультант
Переведено БНТП по заказу Interface Ltd.
Стратегия восстановления должна занимать должное место, чтобы предотвратить случайную потерю данных. Возможности по восстановлению данных должны находится на том же высоком уровне, что и средства резервного копирования.
Восстановление баз данных – это ответ администраторов данных на закон Мэрфи. Базы данных неизбежно повреждаются или теряются по разным причинам: из-за системных или аппаратных сбоев, ошибок операторов, неправильных или недопустимых данных, программных ошибок, компьютерных вирусов и природных катаклизмов.
Поскольку любая организация сильно зависит от своих баз данных, необходимо придерживаться правильной стратегии, чтобы быстро и точно восстановить базу данных после ее потери или повреждения. Кроме того, поскольку восстановление данных должно быть поставлено настолько же хорошо, как и их резервирование, эта стратегия также должна включать в себя согласованную систему резервного копирования данных.
Ниже описаны основные возможности, которые должны быть реализованы для обеспечения точного восстановления:
В данной статье описываются опции каждой из этих возможностей, доступные для баз данных SQLBase. Каждая из этих опций должна рассматриваться с учетом конкретной ситуации. Лучший выбор для конкретной операции необходимо делать на основе различных факторов, включая приемлемые потери данных или время простоя, объем доступного пространства на диске и размер базы данных.
Здесь описываются различные варианты создания резервных копий, призванные обеспечить возможности восстановления данных к требуемому состоянию.
Резервная копия состоит из базы данных (файл с расширением BKP) и всех log-файлов, требуемых для приведения BKP-файла к согласованному состоянию во время резервирования. Необходимо помнить, что вне зависимости от типа выполняемого резервного копирования резервируемые данные должны быть неповрежденными. Поэтому рекомендуется проверять базу данных ("check database") перед резервным копированием и проводить эту процедуру только тогда, когда база данных находится в устойчивом состоянии.
Резервирование может быть осуществлено либо в режиме онлайн, используя ПО резервного копирования SQLBase (сервер SQLBase запущен, а пользователи подключены к базе данных), либо в режиме оффлайн с помощью стандартных команд операционной системы, т.е. используя COPY (отключен сервер SQLBase либо демонтирована база данных), а затем команду "set nextlog". Наиболее часто используемый вариант – резервирование в режиме онлайн, поскольку для большинства операций очень сложно найти подходящее время, когда все пользователи отключены от всех баз данных, с тем чтобы можно было корректно завершить работу сервера SQLBase или демонтировать все базы данных. Это необходимо, потому что сервер SQLBase удерживает базу данных в виде открытого файла, начиная с момента подключения первого процесса и заканчивая демонтажем базы данных или выключением сервера SQLBase.
Что такое log-файлы, зачем они нужны, и почему от них нельзя отказаться
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-файл оказывается блокированным в следующих случаях:
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-файл. В этом варианте резервного копирования требуется одна команда для резервирования данных и одна для их восстановления. Обычно этот метод применяется один раз вечером, перед резервным копированием сервера на магнитную ленту, и, может быть, один раз в течение дня. Недостаток этого метода заключается в том, что создание моментальных снимков очень большой базы данных может потребовать значительных затрат времени, и, кроме того, варианты восстановления ограничены возвращением базы данных в состояние на момент формирования последнего моментального снимка. Любые изменения, сделанные после данного снимка, будут потеряны.
Использование последовательности Backup Database, Release Log и Backup Logs
Этот метод резервного копирования данных несколько более сложен, но гибкость восстановления стоит дополнительных усилий. Он требует резервного копирования файла базы данных, разблокирования log-файла (поскольку тот содержит информацию о текущей резервной копии), а затем резервирования log-файлов. Внимание! Никогда не делайте резервной копии только одной базы данных без log-файлов. Этот метод резервного копирования позволяет изредка резервировать базу данных вместе с ее log-файлами, после чего регулярно создавать резервные копии только одних log-файлов, например, несколько раз в день. Это позволяет провести восстановление базы данных, а затем использовать возможность "rollforward" log-файлов для восстановления работы, выполненной в течение дня. То, насколько часто создаются резервные копии log-файлов, зависит от объема доступного пространства на диске и от того, какое количество данных пользователь может себе позволить потерять. Заметим: накопление log-файлов может привести к очень быстрому заполнению диска. Такой подход особенно удобен для больших баз данных, поскольку резервное копирование файла базы данных, отнимающее много времени, выполняется редко, а периодическое создание резервных копий log-файлов можно выполнить достаточно быстро. Недостатком метода является скапливание log-файлов до их резервирования.
Сегментированное резервирование баз данных превышающих 2 ГБ
В прошлом любую базу данных 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 и, благодаря своим превосходным возможностям мониторинга, позволяет проводить по расписанию создание резервных копий, включая проверку базы данных и обновления статистики. Этот довольно сложный продукт обладает большим набором настроек для выполнения резервного копирования.
Рекомендации по резервному копированию
Выше были рассмотрены основные моменты и рекомендации по проведению резервного копирования в режиме онлайн. Сделаем их краткий обзор:
Резервное копирование в режиме оффлайн
Преимущество резервного копирования в режиме оффлайн состоит в том, что резервируемые данные направляются непосредственно в архив. В этом случае можно получить значительную экономию пространства на диске, потому что объем, требуемый для хранения резервной копии, равен размеру исходной базы данных.
Для создания резервных копий 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-файлов. Процесс восстановления, по существу, проходит в три этапа:
Команда восстановления имеет следующий формат:
В случае использования команды "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-файла.
Рекомендации по восстановлению
Пара советов, на что нужно обратить особое внимание при проведении восстановления
базы данных:
RESTORE DATABASE FROM [путь к каталогу резервных копий] ON SERVER TO MIKE;
Появится сообщение <<Database has been restored. Use rollforward to complete recovery>> (База данных восстановлена. Используйте команду rollforward для завершения восстановления).
ROLLFORWARD MIKE TO BACKUP; (Заметим, что "to backup" – похоже,
единственная опция, которая может сработать)
Возникнет сообщение <<You must restore the database first>> (Вначале
необходимо восстановить базу данных).
ROLLFORWARD MIKE TO BACKUP; (Да, исполните эту команду еще раз!) Будет выдано сообщение <<Rollforward completed>> (Процесс rollforward завершен).
CONNECT MIKE 1 username/password;
Появится сообщение <<Connected to MIKE>> (Установлено соединение
с базой данных MIKE).
Проведите проверку базы данных (команда "check database"), чтобы
узнать о ее состоянии.
Здесь сравниваются различные методы резервного копирования и возникающие в результате возможности восстановления.
Ниже приведены несколько сравнений различных методов резервного копирования, чтобы дать представление о требованиях к дисковому пространству и возможностях восстановления. Предполагается следующее: стандартный размер log-файла – 1 МБ, их отсчет начинается с 1.LOG, для всех log-файлов созданы шаблоны максимального размера и все транзакции завершены до создания резервных копий.
Если в этот момент произошел отказ системы, возможности восстановления будут
доступны только для предыдущей резервной копии. Восстановление последних
трех log-файлов транзакций невозможно, так как нарушена непрерывность последовательности
log-файлов (файлы 1-7 в области базы данных были разблокированы, поскольку
транзакции были завершены и не нуждались в восстановлении после сбоя или
в откате).
После моментального снимка:
Область базы данных Область резервного копирования
Заметим, что файл 4.LOG из области резервного копирования предназначен для удаления, поскольку соответствующие ему транзакции включены в файл DB1.BKP, а создан он был раньше этого файла.
Backup Database и Backup Logs:
Заметим, что все 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.
Тот, кому еще никогда не приходилось восстанавливать свои данные, может считаться счастливым человеком. Однако статистика утверждает, что иногда это приходится делать! Разрабатывайте свою стратегию восстановления данных уже сейчас, до того, как в этом возникнет реальная необходимость.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
