Резервное копирование
Резервирование системных баз данных
Резервирование баз данных
Создание и хранение резервных копий
Планирование резервного копирования
Вопросы для повторения

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

Для чего нужно резервное копирование, думаю объяснять не нужно. Каждый пользователь ПК имеет горький опыт потери информации по той или иной причине… Что бы эти потери свести к минимуму используют резервное копирование. Главное, что бы копии хранились отдельно от оригиналов. Относительно SQL сервера, к необходимости восстановления из резервной копии могут привести, как глобальные катаклизмы, так и тривиальные ошибки пользователей/разработчиков/администраторов.   Например, кто-то может случайно или не случайно выполнить DELETE или UPDATE , забыв указать WHERE ; а кто-то подцепит вирус, который окажется деструктивным, а кто-то решит позариться на вашу базу данных, или кто-то подожжет вашу серверную комнату. Впрочем, случаются ещё и войны, наводнения и пожары. В общем, как в песне поётся: «…следи за собой, будь осторожен…».
Поэтому, после завершения создания баз данных, лучше ещё до   закачки информации в базы, разработайте и внедрите систему резервирования информации ваших серверов баз данных. Здесь, кроме непосредственно MS SQL Server , нужно не забыть и другие компоненты программно – аппаратного окружения ваших информационных систем и приложений. Например, будет очень обидно, если сервер баз данных выживет после того, как террорист кинет гранату в окно ВЦ, а единственный контроллер домена умрёт, вместе с его списком пользователей из 1500 человек. Затраты на систему резервирования рассчитываются, как правило таким образом, что бы они не превысили цифру возможных потерь, в случае потери данных. Иначе, сама система резервирования может стать причиной не явных убытков.
Резервные копии надо делать регулярно (как это банально…)! Другой вопрос, как часто? Для OLTP баз данных или таблиц это может быть очень часто, а для данных OLAP , возможно и не очень часто. Если данные обновляются не очень часто и не очень критичны к их потере, можно составить расписание резервного копирования и делать копии, когда удобно. Исходите из того, сколько ваши сервера могут безболезненно простоять и какой временной период не критичен для восстановления данных из альтернативных резервной копии источников (например, ручной ввод или подкачка из файла).
Сама процедура резервного копирования не должна, при правильном конфигурировании аппаратных средств, существенно повлиять на работу сервера бах данных. Во время резервирования данных, работу с сервером прекращать не нужно, кроме того, в копию попадут и все изменения данных, которые произошли за время резервного копирования. Это становится возможным потому, что на резервную копию копируются не только данные, но их схема и структура файлов. Также в копию попадут фрагменты журнала транзакций, содержащие изменения за время резервного копирования. Механизм включения текущих изменений в резервную копию заключается в том, что перед началом копирования инициализируется процесс контрольной точки, который закрепляет все исполненные транзакции. Далее, сервер запоминает Log Sequence Number (LSN) – номер самой старой транзакции. Копируются все новые транзакции, начиная с этого LSN . Кроме того, в резервную копию помещаются все страницы, которые читаются непосредственно с диска, в обход кэша.
Выполнять резервное копирование дозволено только трём фиксированным серверным ролям: sysadmin, db_owner и db_backupoperator . Для этого можно написать запрос на T-SQL или просто воспользоваться MS SQL SEM . Можно создать и специальную пользовательскую роль, предоставив ей право на резервное копирование.
Для хранения резервных копий Вы можете воспользоваться ленточным накопителем, подключённым непосредственно к серверу баз данных или копировать на диск локального или удалённого компьютера. Для обеспечения возможности использования сторонних программ резервного копирования, таких, как сервер резервного копирования ARCserve производства Computer Associates International, есть возможность копирования в именованный канал.

Резервирование системных баз данных

Поскольку системные базы данных содержат жизненно важную для функционирования сервера информацию, они подлежат обязательному резервному копированию. Особенно это критично, когда Вы вносите такие изменения в структуру баз сервера, которые могут повлиять на его работу. Минимальным требованием к резервированию системной информации является резервное копирование системных баз до и после изменений, вносимых в структуру его баз и системных объектов. В таком случае, возможные фатальные последствия таких изменений могут быть преодолены, путём восстановления предыдущего состояния из имеющихся копий.
Резервное копирование системной информации следует организовывать таким образом, что бы в любой момент времени у Вас была возможность восстановить любую системную базу данных, причём, состояние этой базы было бы актуально на этот момент и содержало все внесённые до этого момента изменения. Как вариант, официальный курс предлагает настроить расписание резервного копирования системных баз данных и обязательно делать копии после внесения изменений.
Копированию подлежат три системные базы: master (содержащая информацию обо всех системных объектах сервера), msdb (содержащая информацию о расписаниях, оповещениях и операторах SQLServerAgent), model (определяет конфигурацию по умолчанию для вновь создаваемых баз).
Если Вы не имеете резервных копий перечисленных баз данных, но нуждаетесь в их восстановлении, Вы можете пересоздать их с помощью утилиты rebildm, которая находится в BINN каталоге сервера.
Если с изменениями, после которых необходимо резервировать системную информацию, для баз model и msdb всё понятно, то для базы master можно заострить внимание, что изменения происходят при использовании операторов CREATE DATABASE, ALTER DATABASE, DROP DATABASE, а также операций их аналогов в SQL SEM. Кроме того, создавайте резервную копию после использования системных хранимых процедур: sp_logdevice, sp_addserver, sp_dropserver, sp_addlinkedserver.

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

О необходимости разработки плана резервного копирования баз данных, удовлетворяющего специфические требования каждого конкретного применения, мы уже не однократно говорили в предыдущих номерах рассылки. Однако существуют события, после которых необходимо в обязательном порядке изготовить «внеплановые» копии. Перечислим их:
1. Копия изготавливается сразу после создания базы данных. Без неё не возможно будет восстановить журнал транзакций, да и сами транзакции выгружать из журнала будет некуда.
2. После создания или перестройки индексов. Хоть это и не является непременным условием, но может избавить Вас от лишней головной боли, в случае, если Вам после этого понадобиться восстановить данные. Дело в том, что в копии до создания индексов содержится старая структура индексов. С другой стороны, журналируется только факт создания индекса, а не сам индекс. Тогда, при восстановлении из старой копии и сохранённых до и после создания индекса записей журнала транзакций, сервер вынужден будет перестроить индекс автоматически, а на это уйдёт ой, как больше времени, чем на простое восстановление.
3. После инициации процесса очистки журнала транзакций (BACKUP LOG WITH TRUNKATE_ONLY или BACKUP LOG WITH NO LOG) также необходимо сделать копию, иначе Вам не удастся восстановить то, что было на этот момент в журнале.
4. Вам придётся сделать резервную копию и после того, как на сервере будет исполнена одна из не регистрируемых в журнале транзакций операция:
- WRITETEXT (без параметра WITH LOG);
- UPDATETEXT (без параметра WITH LOG);
- SELECT…INTO, создающий постоянную таблицу;
- BCP (bulk copy program) для массового ввода данных в базу из файла.

Нужно отметить, что процесс резервного копирования, как правило, проходит не заметно для пользователей и не мешает их работе, однако есть исключения. Приведём ниже список операций, которые запрещено делать во время резервного копирования:
1. Не допустимо создавать или изменять размеры баз данных (CREATE/ALTER DATABASE);
2. Нельзя создавать или перестраивать индексы;
3. Выполнять не регистрируемые в журнале операции (те, что мы описали чуть выше).

Если резервирование уже началось, то сервер просто не даст Вам выполнить перечисленные операции. И наоборот, резервное копирование не начнётся, когда запущена одна из таких операций.
Ещё один примечательный момент: во время резервного копирования базы не могут автоматически расширяться. Так что старайтесь не делать копии, когда в вашу базу идёт активный ввод информации, вдруг места не хватит…

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

Вы можете создавать постоянные или разовые файлы резервных копий. Наиболее распространены постоянные копии, хотя иногда бывает нужно сделать разовую копию. Постоянные файлы (устройства) резервных копий (BackUp Devises) применяются при неоднократном резервном копировании, что позволяет автоматизировать этот процесс. Создать устройства резервирования можно в SQL SEM или с помощью системной хранимой процедуры sp_addumpdevice. Резервными устройствами могут быть файлы на дисках, ленты или именованные каналы. Информация об этих устройствах записывается в системные таблицы sysdevice базы master. Каждому устройству присваивается логическое и физическое имя. Допускается иметь не более 32 устройств резервных копий. Синтаксис sp_addumpdevice следующий:

sp_addumpdevice [@devtype = ] ‘ТипУстройства’,
    [@logicalname = ] ‘НазваниеУстройства’,
    [@physicalname = ] ‘ФизическоеИмя’
    [, { [@cntrltype = ] ТипКонтроллера |
    [@devstatus = ] ‘СостояниеУстройства’}]

Тип устройства может быть: TAPE, DISK или PIPE, например:

USE master
EXEC sp_addumpdevice ‘TAPE’, ‘ModelTapeBackup’, ‘\\.\tape0’

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

BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [,...n]
[WITH
        [BLOCKSIZE = {blocksize | @blocksize_variable}]
        [[,] DESCRIPTION = {text | @text_variable}]
        [[,] DIFFERENTIAL]
        [[,] EXPIREDATE = {date | @date_var}
          | RETAINDAYS = {days | @days_var}]
        [[,] FORMAT | NOFORMAT]
        [[,] {INIT | NOINIT}]
        [[,] MEDIADESCRIPTION = {text | @text_variable}]
        [[,] MEDIANAME = {media_name | @media_name_variable}]
        [[,] [NAME = {backup_set_name | @backup_set_name_var}]
        [[,] {NOSKIP | SKIP}]
        [[,] {NOUNLOAD | UNLOAD}]
        [[,] [RESTART]
        [[,] STATS [= percentage]]
]

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

1. Для создания разовой (временной) копии, например базы NorthWind, можно использовать такую конструкцию:

USE master
BACKUP DATABASE NorthWind TO DISK = ‘E:\\BACKUPS\BackupOnseNorthWind.bak’

Как видим, вместо backup_device здесь используется прямое указание на файл диска "E:". Допускается также использовать прямую ссылку местоположения файла на другом сервере. В таком случае, учётная запись, от имени которой стартует MSSQLServer должна иметь соответствующие права для доступа в выбранный каталог другого компьютера.

2. Можно существенно ускорить процесс резервного копирования, если у Вас имеется несколько однотипных устройств (приводов магнитных лент или дисков). Для этого введено понятие MEDIANAME (имя до 128 символов) описывающее резервный набор этих самых устройств. Т.е., в случае использования дисковых устройств, можно писать копию сразу в несколько файлов (параллельно - последовательно), что соответственно увеличивает скорость копирования. Резервные наборы могут содержать, как постоянные, так и временные файлы. Причём, если Вы включили файл резервной копии в такой набор, то использовать его можно только в этом наборе. Если Вы, все-таки, создадите копию в одном из файлов набора, то для дальнейшего использования набора в целом потребуется переформатировать все его файлы. Также бессмысленно форматировать только один файл набора, поскольку это нарушит целостность копий всех файлов набора.

3. Резервная копия может присоединятся к существующему устройству (по умолчанию) или затирать предыдущие копии. Т.е. может выполняться предварительная инициализация соответствующего устройства но данные заголовка файла сохраняются. Для этого используют параметр INIT или NOINIT. Правда, если первый файл резервного набора располагается на устройстве с меткой стандарта ANSI, которая запрещает перезаписывать существующие копии, то использовать параметр INIT не удастся. Ещё одним препятствием, способным помешать резервному копированию, может стать установка параметра EXPIREDATE, определяющего срок использования устройства резервирования. Также, копия не получится, если Вы попытаетесь записать копию в один из файлов существующего резервного набора. Во многих случаях, когда Вы испытываете трудности с устройствами резервного копирования, на выручку может прийти параметр FORMAT (есть ещё и NOFORMAT). С помощью его можно записать копию даже в принадлежащий резервному набору файл. В отличии от INIT, перезаписи подлежит всё, включая заголовок файла, причём, если файл входит набор, заголовок переписывается во всех файлах набора (при этом, правда, набор разбивается). Новый заголовок определяется данными из MEDIANAME и MEDIADESCRIPTION.

4. Существуют параметры, которые применимы только к лентам, как сменным устройствам. Кроме этих отличий, есть ещё и специфическое ограничение для магнитных лент: привод магнитных лент должен быть подключён локально, т.е. к тому серверу, где "крутится" SQL. Для того, что бы делать копии на ленточное устройство, подключённое к другому серверу, Вам потребуется использовать специальное ПО третьих фирм, которое будет получать данные по именованному каналу. Для отделения копий друг от друга, на ленту записываются метки, которые определяют имя базы, время создания копии, дату и тип резервного копирования (об этом позже). Начиная с версии 7.0, SQL сервер записывает информацию на ленты в стандартном для Windows NT формате, и поэтому допускается совмещение копий сервера баз данных и операционной системы на одной ленте. По умолчанию, после завершения копирования на ленту, происходит её выгрузка из привода (как при использовании параметра UNLOAD). Так будет происходить, пока Вы не примените NOUNLOAD. Другой параметр BLOCKSIZE применяется в комплекте с параметрами FORMAT, INIT или SKIP. Применяйте его, если Вас не устраивает стандартный размер блока, при копировании на ленту (например, если кроме баз данных Вы копируете обычные файлы, средний размер которых существенно меньше размера блока). При форматировании ленты нет необходимости использовать параметры INIT и SKIP, они и так выполнятся. В заголовках ленты содержатся метки ANSI, которые могут препятствовать записи копии (срок действия или права на запись). Что бы преодолеть это препятствие используют параметр SKIP. По умолчанию, действует NOSKIP, т.е. все эти заголовки читаются и учитываются. И в довершении ко всему, если Ваша копия не помещается на одну ленту, возобновить копирование на следующий том с точки прерывания можно повторным запуском BACKUP с параметром RESTART.

5. Кроме полного резервного копирования, существуют ещё схемы, позволяющие иметь актуальную копию с меньшим отвлечением ресурсов, чем автоматическое создание полной копии во временном интервале использования базы и в автоматическом режиме. Одна из таких схем – разностное резервное копирование, которое определяется параметром DIFFERENTIAL. Разностная копия создаётся на базе полной и предусматривает отписывание на устройство резервирования фрагментов базы, которые были изменены за время, прошедшее с последнего полного копирования. Для этого сравнивается Log Sequence Number (LSN) – порядковый номер записи в журнале транзакций, на каждой синхронизируемой с копией странице, с тем LSN, который был последним в предыдущей полной копии. Копирование происходит экстентами, и в копию попадают те экстенты, в которых встречаются страницы с найденным LSN большим, чем в полной копии. Копированию подлежат также все выполняющиеся в это время операции и все не завершённые транзакции. Журнал транзакций целиком не копируется. Следует отметить, что хронология обработки транзакций при таком копировании не соблюдается. Т.е., если одна запись менялась в промежутке между копированиями несколько раз, в копии отразится только последний результат. Если Вы собираетесь использовать эту схему резервного копирования, лучше выработать для себя некие правила именования файлов, содержащих разностные копии, так будет проще разобраться, где у Вас полные, а где у вас иные копии.

Ещё одной схемой резервирования является отписывание в предварительно созданную полную копию записей журнала транзакций. Для этих целей используется оператор BACKUP LOG. При таком подходе, в копию попадают записи журнала транзакций от момента, когда была создана полная копия или отписывались транзакции последний раз и до конца текущего журнала. При этом от журнала будет отсечена неактивная его часть вплоть до начала активного фрагмента, т.е. до того места, откуда начинаются активные в этот момент транзакции и далее, до конца журнала. Поскольку, после отписывания журнала в копию происходит очистка завершённых транзакций, таким способом можно удерживать размер журнала в разумных пределах (он не будет "распухать" у вас до следующей полной копии). Кроме того, соблюдается хронология выполнения операций, т.е. можно их восстанавливать в обратном порядке, как они выполнялись, а не последнее значение (разностная копия).
Возможен случай, когда в промежутке между очередным резервным копированием журнала (по описанной выше схеме) у Вас будет повреждена база данных или даже утеряна полностью. Не отчаивайтесь, выход есть. Правда, для этого нужно, что бы "выжил" файл, содержащий журнал транзакций. Поскольку в журнале останутся записи после Вашего последнего резервного копирования, Вы можете применить оператор BACKUP LOG с параметром NO_TRUNCATE, после чего всё содержимое журнала транзакций попадёт в Вашу резервную копию, даже если сама база уже не доступна. Разумеется, усечения журнала транзакций не происходит и у Вас появляется возможность восстановить данные на момент сбоя. Вы восстанавливаете базу из имеющейся копии, а потом восстанавливаете транзакции из журнала, которые Вы скопировали с параметром NO_TRUNCATE. Забыл ещё одно непременное условие: кроме журнала, у Вас должны обязательно выжить .mdf файл этой базы, где хранятся системные таблицы и база master.
Параметр TRUNCATE_ONLY или NO_LOG в увязке с BACKUP LOG может помочь Вам просто очистить журнал. Надеюсь, Вы сделаете сразу после этого резервную копию. При этом активная часть журнала остаётся не тронутой. Такая операция может понадобиться, если журнал разросся до такой степени, что заполнил всё свободное дисковое пространство и пользователи не могут больше вносить изменения. Я же, искренне надеюсь, что Вам доведётся прибегать к подобной операции только в тестовых условиях, когда потеря данных не критична. Есть в таком подходе и один приятный момент: дело в том, что выполненная после очистки журнала полная копия получится меньше, чем обычная (за счёт отсутствия в ней не активных записей журнала). Этот трюк можно проделать, если Ваша база чуть – чуть не помещается на устройство резервирования. Кроме того, операция усечения журнала не регистрируется. Эффекта автоматического усечения журнала, после каждого запуска контрольной точки, можно получить установкой в TRUE параметра базы данных truncate log on check point. Завершённые транзакции будут удаляться из журнала, что не даст ему сильно расти. Правда, в таком режиме работы базы Вы на сможете отписывать транзакции в резервную копию, а следовательно, восстановлению подлежит только то, что было до этого резервировано.

6. Если база данных храниться у Вас не в одном файле, а в некоторой группе файлов, можно эти файлы резервировать выборочно. Такой подход наиболее часто применяют для очень больших баз данных. Исходный синтаксис в таком случае будет немного расширен. Кроме имени базы данных или её номера, можно через параметр FILE или FILEGROUP задать набор конкретных логических имён файлов, которые будут копироваться. Через запятую можно указывать до 16-ти таких имён. При такой схеме копирования, лучше копировать журнал в отдельный файл. Для исключения путаницы, лучше создать расписание таких копий. Вот пример резервирования выбранного, седьмого файла:

BACKUP DATABASE MyFirsDB
FILE = File7 TO File7Backup
BACKUP LOG MyFirsDB to myfirsdbLOGbackup

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

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

Если данные, содержащиеся в базах Вашего сервера не критичны к их частичной потере в результате сбоя или аварии сервера, или если они редко изменяются, а изменения легко восполнимы, Вы можете использовать самый простой план резервирования, заключающийся в периодическом, полном резервном копировании баз данных. Можно даже ограничится копированием только баз, исключая журнал транзакций. В таком случае, если Вам потребуется восстановить данные из резервной копии, Вы сможете восстановить только прошлую копию. Если при этом, Вы не включали параметр базы trunc. Log on chkpt в TRUE (автоматическая очистка завершённых транзакций в журнале и усечение журнала), и журнал не пострадал, можно попытаться его резервировать (на момент сбоя и до восстановления базы) с параметром NO_TRUNCATE и восстановить записи журнала после восстановления данных. В таком случае, Вам удастся обойтись без потерь. Если же trunc. Log on chkpt был установлен в истину, кроме прошлой копии данных у Вас не останется ничего. Кроме того, для варианта с отключенным trunc. Log on chkpt и если вы не резервируете и не чистите (даже в ручную) журнал, велика вероятность того, что журнал займёт у Вас всё дисковое пространство, после чего сервер просто откажется обслуживать запросы клиентов, пока журнал не почистят. Т.о. Вы стоите перед дилеммой, или смериться с возможной потерей данных или заботится о том, что бы транзакции периодически отписывались из журнала в резервную копию в период между полными копиями. По моему мнению, данная схема не должна применяться ни при каких обстоятельствах, потому, как не способна решить ни одной практической задачи защиты данных в виду множества уязвимостей. Единственное её применение, это задачи подготовки и сдачи теста на MCDBA, поскольку она упоминается в официальном курсе.
Общепринятой схемой резервного копирования является периодическое, полное копирование, с отписыванием журнала транзакций с необходимой периодичностью в промежутках межу полными копиями. В результате, резервная копия представляет из себя полную копию и набор копий записей журнала. В случае сбоя, вы можете восстановить полную копию, а вслед за ней поочерёдно все копии записей журнала транзакций, которые успели отписаться на устройство резервирования. Не сохранённые записи журнала транзакций можно попытаться (перед началом восстановительных мероприятий) выгрузить в резервную копию, как и в предыдущей схеме (WITH NO_TRUNCATE). Такая схема достаточно универсальна для большинства применений и обеспечивает хорошую гибкость в проведении восстановительных работ. Есть и ещё одно применение у этой схемы. Допустим Вы (случайно) закачали в базу не те данные и хотите вернуться в предыдущее этой операции состояние. Поскольку далеко не всегда можно придумать условие отбора, которое позволило бы отобрать все не верные записи, можно просто восстановить базу и записи журнала до того времени, которое предшествует ошибочной операции. Если у Вас записи журнала отписываются достаточно часто и по расписанию, Вы может довольно близко подобраться к необходимому состоянию базы данных, после которого наступило не устраивающее Вас событие, так, что приведение данных к необходимому состоянию может быть осуществлено с минимальными затратами.
Всё становится на много сложнее, если у Вас «огромная» база или совсем «древнее» железо. Вполне может случится так, что времени на создание резервных копий ни в рабочее время ни в ночь не останется. Тогда Вам придётся использовать следующие две схемы, каждая из которых имеет свои прелести и недостатки.
Применение разностной схемы резервирования, позволяет существенно сократить количество копий журнала транзакций, которые делаются в период между полными бэкапами. В начале, Вы делаете полную копию. Потом отписываете в неё транзакции. Когда сеансов копирования журнала транзакций накопится достаточно много, Вы выполняете разностную копию. Это позволяет Вам зафиксировать в устройстве резервирования все изменения в базе данных, произошедшие между полным бэкапом и разностной копией. Копии журнала транзакций между полным и разностным копированием становятся не нужны. Далее, Вы продолжаете отписывать транзакции до следующего разностного или полного копирования, что определяется размерами Вашей базы или даже временем резервного копирования. В случае сбоя, Вы должны сохранить текущие записи журнала, как и предыдущих схемах, восстановить последнюю полную копию, восстановить последнюю разностную копию и все сеансы резервирования записей журнала до момента сбоя. В заключении, Вы восстанавливаете копию журнала на момент сбоя.
Другой вариант предполагает то, что Ваша база данных расположена не в одном, а в нескольких файла. Резервное копирование каждого файла занимает меньше времени, что также может оказаться необходимым условием для проведения резервного копирования в регламентные сроки. Предварительно выполнив полную копию, и отписывая транзакции в промежутках между копированиями, Вы можете организовать в последующем не полное копирование, а циклическое копирование файлов базы данных. В таком случае, для восстановления базы, Вы должны убедится в том, что проблема связана только с одним файлом, и восстановить только его из копии (предварительно, разумеется, нужно произвести резервирование журнала на момент сбоя). Далее, Вы применяете все последующие после резервирования этого файла транзакции, и, что удивительно, сервер сам разберётся, и применит только те транзакции, которые относятся к повреждённому файлу. В заключении, Вам останется только восстановить сохранённые на первом шаге транзакции из журнала на момент сбоя. Это вариант всем хорош, особенно по тому, что восстанавливается не вся база, а только один файл, за исключением, разве что тех нюансов, о которых мы говорили в прошлом выпуске. Ну и кроме всего прочего, не стоит на долгое время оставлять сервер без полного бэкапа.
Для повышения производительности резервного копирования старайтесь размещать на разных дисковых массивах (и даже RAID контроллерах) файлы баз данных, журналов транзакций и резервных копий. Если для копирования используются ленточные накопители, можно линейно увеличивать скорость бэкапирования за счёт распараллеливания задачи резервирования. Кроме того, старайтесь делать копии, когда на Вашем сервере наблюдается минимальная активность. Удобно и надёжно составить расписание резервирования баз и журналов и поручить это всё выполнять серверу. В своей практике, я использую вторую из описанных схем, когда полная копия делается ночью, а в течении дня транзакции отписываются каждый час. Основная копия делается на диск, а вторая копия (в ручном режиме) делается на DLT ленту. Такая схема позволяет мне запросто управляться с базой в 9ГБ и 1,9ГБ журналом.

Вопросы для повторения

ВОПРОС
База данных содержит 5 ГБ данных и хранится в виде одного файла. Эта база данных используется в качестве системы принятия заказов в компании, занимающейся выполнением заказов по почте. Операторы принимают заказы круглые сутки. Всего компания ежедневно получает около 2 тыс. заказов. Предложите наиболее целесообразный план резервного копирования такой базы данных.
ОТВЕТ
Сервер SQL Server может выполнять резервное копирование, когда база данных открыта для доступа. Однако на время особо интенсивного использования базы данных лучше не планировать процедуры резервного копирования.
Поскольку база данных размещена в одном файле, вы не сможете делать резервные копии отдельных ее частей. Придется выполнять резервное копирование всей базы данных целиком.
Можно использовать план, предусматривающий полное резервное копирование базы данных вместе с журналом транзакций. В периоды увеличения объема ежедневных заказов в план можно добавить процедуры разностного резервного копирования. Использование разностных копий позволит ускорить восстановление после системного сбоя.
ВОПРОС
База данных содержит изображения, получаемые с метеоспутника, и постоянно обновляется. Размер базы данных составляет 700 ГБ. База данных разбита на три файла. Если выполнять полное резервное копирование базы данных, это заняло бы около 20 часов. Как уменьшить время ежедневного резервного копирования, сохранив при этом хорошие показатели восстанавливаемости данных после системных сбоев?
ОТВЕТ
Используйте план резервного копирования, начинающийся с создания полной резервной копии базы данных. Полная копия будет сниматься редко. Каждый день проводите резервное копирование одного из файлов базы данных по круговой системе. Вдобавок к резервному копированию журнала транзакций делайте разностные копии, чтобы свести к минимуму время восстановления.
ВОПРОС
Имеется база данных, для которой обычно проводится только полное резервное копирование. Журнал транзакций размещен отдельно от файлов данных на другом физическом диске. В журнале разрешается накапливать изменения, но периодически его следует очищать. Диск, содержащий файлы данных, поврежден. Что можно сделать после замены диска для того, чтобы потери данных были минимальными?
ОТВЕТ
Попробуйте сделать резервную копию неповрежденного журнала транзакций, используя параметр NO_TRUNCATE. Это позволит сохранить данные о некоторых операциях, выполненных со времени последней процедуры полного резервного копирования базы данных. После восстановления полной копии базы данных примените резервную копию журнала транзакций и восстановите содержимое базы данных.
ВОПРОС
Каковы преимущества и недостатки применения разностного копирования в составе общей стратегии резервного копирования?
ОТВЕТ
Разностные копии позволяют сэкономить время при восстановлении. Для восстановления базы данных достаточно использовать полную резервную копию и последнюю разностную копию. Для возвращения базы данных в нормальное состояние необязательно применять все резервные копии журнала транзакций и остальные разностные копии.
Недостаток разностного резервного копирования состоит в том, что разностные копии не охватывают промежуточные изменения базы данных, и потому их нельзя использовать для восстановления данных на определенный момент времени. Для подобного восстановления нужны резервные копии журнала транзакций. Кроме того, каждая новая разностная копия будет больше предыдущей, и точно так же возрастет промежуток времени между последней процедурой полного резервного копирования базы данных и процедурой разностного копирования.