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

• Название: Тема 4 Резервное копирование баз данных. Восстановление баз данных Причины потери данных
• Дата: 03.03.2022
• Размер: 420.74 Kb.
• Имя файла: Тема 4 4_ Резервное копирование баз данных_ Восстановление баз д.ppt
• Тип: Документы; #380930

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

Причины потери данных

Можно выделить 5 основных причин потери данных:

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

Причины потери данных

2. Ошибки администратора (человеческий фактор) — Случаи, в которых пользователь с большими полномочиями может неумышленно (или умышленно) разрушить данные. Необходимо постараться создать такой режим работы, который сделает подобную ситуацию маловероятной, однако совсем исключать такую возможность нельзя.

Причины потери данных

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

Причины потери данных

4. Отказ дискового накопителя — Физическое разрушение жесткого диска. Рекомендуется использование технологий RAID для хранения файлов баз данных, кроме того необходимо, чтобы файлы резервных копий хранились на дисковом носителе, отличным от устройства, на котором располагаются файлы баз данных.

Причины потери данных

5. Катастрофы (пожар, наводнение, землетрясение) или кража — Обойти эту ситуацию станет возможным, если устройство, содержащее необходимую для восстановления данных информацию, будет храниться отдельно от основного оборудования и не будет потеряно в результате катастроф или краж.
Необходимо постараться создать систему резервного копирования, позволяющую восстановить данные в любой из описанных выше ситуаций.

Для чего нужно резервирование и восстановление базы данных?

Резервное копирование (англ. backup) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном месте их расположения в случае их повреждения или разрушения.


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


Требования к плану резервного копирования баз данных SQL Server устанавливает бизнес, учитывая несколько критериев:

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

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


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

Полное (Full Backup)

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

Полное (Full Backup)

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


Преимущества:

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

Недостатки:

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

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

Дифференциальное

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

Дифференциальное

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


Преимущества:

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

Недостатки:

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

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

Журнал транзакций

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


Преимущества:

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

Недостатки:

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

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

Tail-Log

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

Copy-only

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

Частичная резервная копия

Partial backup этот тип резервной копии используется для того, чтобы снять копии с read-only файловых групп.
На практике используется редко.

Резервное копирование файлов и файловых групп

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

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

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


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


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

Доставка журналов транзакций
Always On
Point-In-Time восстановление
Резервные копии журнала транзакций

Преимущества:

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

Недостатки:

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

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


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


Преимущества:

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

Недостатки:

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

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

Восстановление с неполным протоколированием (bulk logged)

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

SELECT INTO
BULK INSERT и BCP
INSERT INTO SELECT
Операции с индексами (CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX)

В остальном эта модель работает аналогично полной модели восстановления.

Преимущества:

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

Недостатки:

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

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


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


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


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


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

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

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

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

Пример стратегии резервного копирования

https://tavalik.ru/kopirovanie-i-vosstanovlenie-bd-microsoft-sql-server/