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

Имеется дополнительная возможность организации доступа для чтения данных из зеркальной копии БД с использованием снимков (snapshot) базы данных. Снимок — это специальный объект, представляющий собой доступную только для чтения копию базы данных в определенный момент времени. Максимальный размер, который может иметь снимок, равен размеру исходной базы данных в момент создания.

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

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

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

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

(RAID-устройство - (Redundant Array of Inexpensive Disks, Redundant Array of Independent Disks)

дисковый  массив, дисковая матрица, избыточный массив недорогих дисков Метод восстановления ошибок жесткого диска, основанный на том, что два или более жестких  дисков работают параллельно. Каждый диск содержит лишь часть данных, необходимых для воссоздания целостного набора данных. Данные расщепляются для записи на каждый отдельный диск и сопровождаются дополнительными битами для коррекции ошибок. Если происходит сбой в работе одного из дисков, данные можно восстановить на новом диске, используя содержание других дисков массива. В зависимости от уровня (0, 1, 2, 3, 4, 5 и 7) предоставляются различные способы объединения дисков: RAID 0 - Non-Redundant Stripped Array, RAID 1 - Mirrored Arrays, RAID 2  - Parallel Array with ECC, RAID 3 - Parallel Array with Parity (требуется три диска минимум), RAID 4 - Stripped Array with Parity, RAID 5 - Stripped Array with Rotating Parity. Уровни RAID 0-5 в конце 1997 г. RAID Advisory Board заменила тремя новыми классификациями: DTDS, FRDS, FTDS.) 

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

1. Распределенный менеджер блокировок представляет собой потенциально узкое место системы
2. архитектура является дорогостоящей
3. для работы с такой системой нужны специально подготовленные специалисты

Планирование резервного копирования очень больших БД

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

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

Стратегия резервного копирования должна быть реализована таким образом, чтобы  БД использовали:

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

Выбор устройств и носителей  для резервного копирования

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

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

Восстановление корпоративных данных 

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

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

Полная  модель (full model) – применяется для баз данных, которые необходимо восстанавливать до точки отказа либо до конкретной точки во времени. Стратегия резервного копирования при использовании этой модели возможна в двух вариантах; создание полных и дифференциальных резервных копий в сочетании с копиями журналов транзакций или же только полных копий и копий журналов транзакций.

Минимальное ведение журнала (bulk-logged) – сокращает использование пространства в журналах, но сохраняет большую часть возможностей полного резервного копирования. Массовые операции с данными заносятся в журнал минимально, что не позволяет контролировать каждую такую операцию в отдельности. Поэтому, если сбой данных произойдет перед создание очередной полной или дифференциальной копии, операции массовой загрузки данных придется повторить вручную. Стратегия резервного копирования при использовании этой модели возможна в двух вариантах: создание полных и дифференциальных резервных копий  в сочетании с копиями журнала транзакций или же только полных копий и копий журналов транзакций.

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

Сервер  горячего резерва – автоматически обновляемый сервер, начинающий работу немедленно после сбоя основного СУБД-сервера.

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

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