Тема 4 4. Резервное копирование баз данных. Восстановление баз данных

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

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

пользователь с большими полномочиями может неумышленно (или умышленно) разрушить данные.

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

в результате ошибок в оборудовании и программном обеспечении. В этом

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

Рекомендуется использование технологий RAID для хранения файлов баз данных, кроме

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

эту ситуацию станет возможным, если устройство, содержащее необходимую для восстановления

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

любой из описанных выше ситуаций.

носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления

данных в оригинальном месте их расположения в случае их повреждения или разрушения.

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

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

бизнес, учитывая несколько критериев:
Допустимый объём потерянных данных (за последний день/час/минуту/секунду);
Требования

к дисковому пространству и его стоимость;
Затраты ресурсов сервера на резервное копирование.

котором в процессе создания копии только одна активная сессия, поддерживаемая

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

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

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

копию всей базы данных, включая все объекты и данные системных

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

восстановить за 1 шаг, так как она не требует других

дифференциальных/инкрементальных копий.
Если модель восстановления базы SQL данных установлена как “Полная”, то при восстановлении БД можно указать параметр “STOPAT”, где указывается время (до секунды) на котором нужно остановить восстановление данных.
Например, сотрудник внёс некорректные данные в 14:46:07, с помощью параметра STOPAT можно восстановить данные на момент 14:46:06

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

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

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

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

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

используют план по типу “полное раз в N дней, дифференциальное

каждые N часов”. Если ежедневный оборот данных достаточно высокий, то данный тип резервных копий может быть неудобен в применении, так как копии будут весить довольно много.
Например, если полная резервная копия весит 300 GB, а дифференциальная спустя час работы 5 GB, то спустя сутки это будет 120 GB, что делает использование данного типа копий нерациональным.

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

при полном копировании.

баз данных, а затем разностную, что занимает больше времени. И,

соответственно, нет смысла применять разностное копирование без полного.

с полным резервным копированием.

все транзакции, которые произошли с момента последнего резервного копирования, а

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

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

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

резервном копировании, где требуется полная копия базы данных и последняя разностная копия,

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

с полным резервным копированием.

отдельный, но фактически это обычная резервная копия журнала транзакций с

NORECOVERY опцией.
Tail-Log бекап рекомендуется делать перед восстановлением копий журнала транзакций, чтобы не потерять транзакции между последним бекапом и текущим моментом времени.

“базой” для дифференциальных резервных копий и для копий журнала транзакций.

Copy-only бекап не нарушает текущую цепочку резервных копий (полный-> дифференциальный или полный -> копии журналов транзакций) и используется только в том случае, если вам нужно снять полную резервную копию, не задевая текущую цепочку бекапов.
За исключением этих нюансов – ничем не отличается от обычной полной копии.

резервной копии используется для того, чтобы снять копии с read-only

файловых групп.
На практике используется редко.

для снятия резервных копий определенных файлов или файловых групп.
Копирование файлов

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

данных, который может быть потерян во время разрушения базы данных,

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

базы данных SQL Server, который отвечает за регистрацию транзакций в

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

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

нужно.
В случае аварии, данные могут быть восстановлены только на момент снятия резервной копии.
При использовании этой модели восстановления, следующий функционал SQL Server недоступен:
Доставка журналов транзакций
Always On
Point-In-Time восстановление
Резервные копии журнала транзакций

объему памяти протокола.

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

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

только в тех случаях, когда сервер баз данных не обладает

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

хранит все транзакции в журнале транзакций до усечения журнала (посредством

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

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

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

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

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

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

logged)
Эта модель, также, как и полная, записывает все транзакции в

журнал транзакций, за исключением таких операций как:
SELECT INTO
BULK INSERT и BCP
INSERT INTO SELECT
Операции с индексами (CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX)
В остальном эта модель работает аналогично полной модели восстановления.

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

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

восстановления.
Не протоколируется операции с изменением индекса. При восстановлении, индексы потребуется

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

производственных баз данных в тех случаях, когда периодически происходят крупномасштабные

или объемные bulk-операции.

не должны храниться на том же диске, что и ваш

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

целостность резервных копий и проводите тестовые восстановления. Вы всегда должны

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

базой данных системы, потому что она содержит информацию обо всех

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

копию каждый раз, когда выполняются действия, приводящие к модификации базы

данных master.
Вот некоторые из них:
Выполнение операторов и хранимых процедур;
Создание, изменение и удаление базы данных;
Изменения протокола транзакций.

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

после того как с базами данных были выполнены следующие изменения:
После создания базы данных;
После создания индексов;
После создания протокола транзакций;
После выполнения непротоколируемых операций (операции, которые не записываются в протокол транзакций).