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

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

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

Современная СУБД может предоставлять несколько различных способов создания резервной копии базы корпоративных данных.

Простейшим из этих способов, который поддерживает любая СУБД, является создание полной резервной копии (full backup, database backup) – точной копии базы данных на текущий момент времени.

ПОЛНАЯ КОПИЯ  является стандартным типом резервного копирования. Этот тип резервирования предполагает полное копирование всей информации, имеющейся в БД – все объекты, системные таблицы и данные. В качестве приемника данных может выступать магнитный диск (device) большого объема или устройство резервного копирования - стример (streamer - устройство потоковой записи на магнитную ленту, применяется для резервного копирования и архивирования данных). Создание полной копии является необходимым условием реализации плана резервного копирования, независимо от выбранной стратегии.

Полное копирование  имеет свои преимущества и недостатки. Преимущество – для приведения поврежденной системы в рабочее состояние  достаточно восстановить лишь один архив (копию). К недостаткам относится длительное время создания архива даже в случае внесения в БД незначительных изменений в интервал времени между созданием очередной резервной копии. Периодичность создания полной копии определяется степенью активности системы.

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

Второй  тип создания резервной копии, предоставляемый СУБД (не всеми), называется дифференциальным резервированием (differential backup) или разностным копированием. При дифференциальном резервировании записывает только та информация, которая была изменена после последнего полного резервирования. Преимуществом дифференциального резервирования является то, что для выполнения этого процесса требуется намного меньше дискового пространства, и при этом достигается большая скорость выполнения операции резервирования данных.

РАЗНОСТНОЕ  КОПИРОВАНИЕ было разработано с  целью уменьшения времени, необходимого для получения копии базы данных. В основе разностной копии лежит отслеживание изменений, вносимых пользователями в базу данных. Достаточно применить ее после восстановления полной резервной копии (которая делается один раз в большой промежуток времени), чтобы целиком восстановить систему в актуальном состоянии. В больших базах данных с относительно небольшим количеством изменений разностное копирование является наиболее оптимальным методом резервирования данных.

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

Третий  тип создания резервной копии, предоставляемый СУБД (теми, которые в принципе поддерживают механизм транзакций), называется резервированием журнала транзакций (transaction log backup). В журнал транзакций записываются все транзакции, выполненные после последнего резервного копирования журнала транзакций.

КОПИЯ ЖУРНАЛА ТРАНЗАКЦИЙ. В двух предыдущих типах резервного копирования фиксируется состояние системы на конкретный момент времени. Однако они не помогут, если потребуется восстановить систему в промежуточном состоянии (например, в состоянии за полчаса до выполнения полного копирования). Резервное копирование журнала транзакций позволяет сохранить информацию обо всех транзакциях (операциях), выполненных в базе данных. Такая копия содержит непрерывную цепочку изменений, которым подверглись данные со времени последнего архивирования любого типа. Таким образом, она отображает все операции изменения данных.

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

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

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

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

Четвертый тип - резервное копирование файлов и групп файлов – в этом случае создаются резервные копии отдельных файлов и групп файлов БД, а не всей базы данных целиком, то есть выполняется частичное архивирование данных (что позволяет сильно сэкономить время). В основе этого подхода лежит возможность привязывания таблицы или даже отдельного столбца к конкретному файлу или группе файлов. Все данные, принадлежащие столбцу, будут размещаться только в указанном файле. Используя данный тип резервирования, можно создать копию отдельной таблицы БД. Это бывает полезно, когда большую часть БД составляет практически неизменяемая справочная информация.

КАК ЧАСТО НАДО ВЫПОЛНЯТЬ  РЕЗЕРВИРОВАНИЕ ДАННЫХ 

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

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

Максимальные

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

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

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

Но  самое главное  в любой схеме резервного копирования – это систематичность и регулярность. 

РЕЖИМЫ  РЕЗЕРВНОГО КОПИРОВАНИЯ 

Резервное копирование может выполняться  в следующих режимах:

1. режим холодного резервирования
2. режим горячего резервирования
3. режим зеркалирования

1. Как показывает практика, резервирование базы данных лучше всего проводить в «холодном» виде, когда перед резервированием БД закрывается и становится неактивной. Такое резервирование лучше всего выполнять в ночное время, когда пользователей можно отключить от базы. Однако во многих случаях этот вариант неприемлем. Во-первых, современные базы данных нередко достигают в объеме сотен и тысяч гигабайт, поэтому их копирование требует слишком много времени, особенно при копировании на магнитные ленты и даже целой ночи для этого может не хватить. Блокировать  доступ к базе для выполнения резервирования на длительное время крайне нежелательно. Во-вторых, нередко СУБД работают в режиме on-line (например, на Internet - серверах), и отключение их в принципе невозможно.

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

3. Зеркальное отображение баз данных работает на стандартном серверном аппаратном обеспечении и позволяет организовать непрерывный поток изменений журнала транзакций от сервера-источника (основной сервер) к серверу-получателю (резервный сервер).

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

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

На основном (principal) размещается главная база данных. Именно к этому серверу подключаются приложения; на нем же обрабатываются транзакции. Зеркальный сервер резерва (mirror) содержит копию; он является местом назначения переданных записей журналов транзакций и находится в состоянии ожидания. Третий сервер, свидетель (witness), отслеживает состояние двух других серверов и позволяет организовать автоматическое переключение в случае сбоя. Именно свидетель делает выбор сервера, поскольку знает, какой из них в данный момент является основным, а какой - зеркальным. Для автоматического переключения клиентов в случае отказа основного сервера используется функция автоматического перенаправления клиентов.

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

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