SQL Server: Всегда имейте план резервирования

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

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

Резервирование и восстановление — это не HA

Имеется одно хорошее базовое правило, которое нужно держать в голове: резервирование и восстановление не являются средством обеспечения высокой доступности (high availability, HA). Восстановление базы данных с резервной копии — это просто «починка», а не обеспечение доступности.

Если вы работаете с критически важной системой и вашей базе данных необходима HA, подумайте о различных настоящих HA-функциях, доступных для SQL Server. HA — не то же самое, что резервирование и восстановление.

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

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

Вот некоторые из этих других методик.

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

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

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

Резервирование снимка: это самый быстрый способ резервирования баз данных. Резервная копия снимка — это специальная резервная копия, создаваемая почти мгновенно с помощью решения по созданию снимков на основе полного дублирования (split-mirror) от независимого поставщика оборудования и ПО.

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

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

Резервирование Full, Differential и Log: если выбрана модель резервирования базы данных Full, используйте комбинацию разных видов резервирования (Full, Differential и Log — полное, разностное и журналов транзакций). Это позволит свести к минимуму число резервных копий, необходимых для приведения базы данных к состоянию на момент сбоя.

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

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

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