Содержание:
Резервное копирование MS SQL
Дата публикации: 27 декабря 2018 г.
* * *
Данная статья посвящена решениям для восстановления MS SQL. Постараемся рассмотреть основные моменты и важные детали, которые необходимо учесть, при планировании и выборе решения для восстановления базы данных MS SQL.
В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective - RTO) и допустимая точка восстановления (recovery point objective - RPO).
RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO - это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:
- аппаратный сбой, физический выход сервера из строя: диски, CPU, системная плата, блок питания и т.д.
- программный сбой: операционная система, база данных
Для каждого обозначенного инцидента есть целый комплекс мер, позволяющий избежать последствия инцидента.
* * *
HIGH AVAILABILITY MS SQL
При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):
- Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.
- В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.
Оба способа могут быть реализованы как по отдельности, так и совместно, если в этом есть необходимость. Кластеризация в большей степени рассчитана для оперативного устранения аппаратного сбоя.
Преимущества High Availability MS SQL:
- мгновенное переключение с ноды на ноду, без простоя
- без зависимости от физических серверов
- позволяет проводить обслуживание серверов без перерыва в работе с базой данных
Недостатки High Availability MS SQL:
- реализации требует дополнительной инфраструктуры и ресурсов
- высокая стоимость решения по лицензиям и оборудованию
- более сложное и высоквалифицированное обслуживание
* * *
BACKUP MS SQL
В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:
Данные системы помогут избежать как аппаратных, так и программных сбоев в работе сервера базы данных.
После расчета значений RTO и RPO можно перейти к планированию конфигурации SQL сервера. Для достижения этих значений мы можем использовать как технологии высокой доступности, перечисленные выше, так и backup баз данных.
* * *
Регламент backup MS SQL
- Резервные копии должны находиться на разных физических носителях с исходными файлами базы данных
- Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий
- Выполняйте ежедневное полное резервное копирование
- Делайте дифференциальные резервные копии как можно чаще. Они занимают гораздо меньший объем в хранилище и еще больше сокращают риск потери данных
- Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут
- Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы
* * *
НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC
СкачатьBackup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.
Рассмотрим каждый случай более подробно для этого создадим в системе новое задание для резервного копирования основной и системных баз данных.
Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).
Далее, для настройки Full backup на вкладке Microsoft SQL выбрать один из двух методов резервного копирования: Full или Full Copy.
В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:
- не проводить проверку
- полная проверка, без учёта индексов
- полная проверка с учётом индексов
- только физическая проверка
Рекомендуется выполнять полную проверку, включая индексы, но необходимо учесть, что это самый длительный процесс проверки.
Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.
В данном списке в первую очередь интересует «Differential - Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) - Backup up database changes since the last full – use with convert to virtual machine job».
Еще одним важным параметром является «Log - Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.
Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.
Используемая в статье информация взята из официальных источников:
Отказоустойчивая кластеризация Windows Server с SQL Server
Руководство администратора Backup Exec
