Как избежать фрагментирования резервных копий

Администраторам систем SQL Server, в которых не используются группы доступности (или зеркальное дублирование), я обычно рекомендую не ограничиваться хранением резервных копий на соответствующей системе и генерировать дополнительную копию, которая будет находиться в другом месте. Понятно, что, если ваши базы данных и их резервные копии размещаются на одном и том же сервере, вы, образно говоря, храните все яйца в одной корзине, а этого следует всячески избегать. В порядке подготовки к восстановлению данных после катастрофического сбоя иметь про запас их резервную копию целесообразно. Но все-таки я считаю, что на случай возникновения аварийных ситуаций «меньшего» масштаба хранить самые свежие резервные копии нужно на той же системе или на том же сервере, где размещаются ваши базы данных. Следовательно, если вы храните экземпляры всех своих резервных копий на соответствующих системах, это означает, что в ситуациях, когда вам нужно будет преодолевать последствия «незначительных» аварий, или в иных чрезвычайных обстоятельствах, требующих немедленных действий по восстановлению рабочей базы данных, вам не придется пропускать данные «по проводам». И снова подчеркну: хотя иметь резервную копию данных под рукой весьма полезно, мы просто не можем себе позволить держать единственную копию данных на той же системе, где хранится оригинал. Вот почему я рекомендую дополнительно сохранить резервные копии в других местах. Кроме того, я полагаю, что почти во всех сетях не составляет большого труда сохранять непосредственно в системе резервные копии типов FULL + DIFF + TLOG в течение 1-3 дней. В то же время обычно довольно просто организовывать хранение данных в течение недели и даже более длительного срока на другой системе, где мы в идеале можем размещать резервные копии на более дешевых и не столь высокопроизводительных дисках.

Группы доступности AlwaysOn и резервные копии

Как отмечалось в предыдущей статье серии, с появлением групп доступности AlwaysOn ситуация несколько изменилась — теперь нам приходится считаться с возможностью «фрагментирования». Иначе говоря, если вы не посвятите некоторое время планированию мер по обработке резервных копий, они в конечном итоге могут «расползтись» по нескольким хостам. Теоретически в этом нет ничего плохого — эти резервные копии по-прежнему будут работать. Но если происходит сбой и требуется восстанавливать данные с резервных копий, меня перспектива охоты за экземплярами T-Log, а также другими резервными копиями не вдохновляет (ведь речь и так идет о дополнительных усилиях и временных затратах на расчленение групп доступности или по меньшей мере о выведении целевой базы данных из существующей группы и т. д.).

Поясню свою мысль на примере. Допустим, я настроил два сервера с идентичными параметрами накопителей, развернул на них базу данных SQL Server и включил эту базу данных в состав группы доступности. Далее я настроил систему таким образом, чтобы резервные копии выполнялись с основной реплики (так как я не нуждаюсь в получении дополнительной лицензии для запуска резервных копий с дополнительной реплики). Теперь представьте, что у меня в два часа ночи автоматизированные средства резервирования запустили создание полной резервной копии, которая хранится на SERVER1; резервные копии T-LOG стали запускаться раз в 10 минут (они тоже, как и ранее, хранятся на SERVER1). В 8 утра система начинает регистрировать массовый трафик, а к 9:30 утра возникают странные сбои, и группа доступности корректно переключается на SERVER2, то есть Server2 становится основной репликой. Теперь вообразите, что резервные копии журнала регистрации транзакций продолжают запускаться, как положено, каждые 10 минут, и получается, что сейчас у меня имеется полная резервная копия на SERVER1, а также ряд резервных копий T-Log (тоже на SERVER1), но плюс ко всему теперь я записываю резервные копии T-Log еще и на SERVER2. В 10:25 утра происходит еще одно событие, и действия вновь переключаются на SERVER1. Будем исходить из того, что переключение произошло вследствие вмешательства оператора, хотя это мог быть все тот же странный «сбой» или что-то иное. Начиная с этого момента большинство полученных мною резервных копий T-LOG хранятся на SERVER1, хотя несколько таких копий размещается на SERVER2.

Теперь представим себе, что около двух часов дня происходит нечто действительно угрожающее, и я понимаю, что нужно восстановить базу данных (или использовать копии T-Log для устранения последствий). К этому моменту я уже «фрагментировал» свои резервные копии, и мне придется «собирать» их с двух машин, из двух различных папок, а затем попытаться восстановить в должном порядке, ничего не перепутав.

Простое решение

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

Более того, если вы хотите сохранить экземпляры своих резервных копий, настоящей палочкой-выручалочкой для вас станет параметр MIRROR TO команды BACKUP. Как показывает практика, многие администраторы баз данных или вообще не знают о наличии этой возможности, или забывают о ней — просто потому, что она реализована только в версии Enterprise Edition. Но поскольку для работы с группами доступности требуется именно версия Enterprise Edition, возьмите эту возможность на вооружение, чтобы использовать вложенные средства полностью.

Фрагментирование резервных копий и агенты чтения журналов

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

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

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

Разумеется, если вы позаботились о том, чтобы все ваши резервные копии T-Log размещались в отдельном консолидированном месте, вы убедитесь, что это значительно облегчает работу с агентом чтения журнала. Словом, когда дело касается «предотвращения фрагментирования», даже самые скромные меры защиты могут принести весьма ощутимые плоды.

Настройки резервных копий

В процессе создания групп доступности AlwaysOn вы можете задать настройки резервных копий. Это можно сделать и после формирования группы доступности; щелкните правой кнопкой мыши на соответствующей группе доступности, в раскрывшемся меню выберите пункт Properties и перейдите на вкладку Backup Preferences.

И хотя отдельные аспекты этих настроек могут показаться несколько невразумительными — во всяком случае, поначалу, на самом деле их установка довольно проста. Настолько проста, что соответствующей документации, подготовленной специалистами Microsoft, вполне достаточно для обзора имеющихся вариантов. Впрочем, здесь имеется два «подводных камня».

Первый «подводный камень» — лицензии. Хотя подготовленная корпорацией Microsoft документация по средствам управления настройками резервных копий, входящих в состав групп доступности AlwaysOn баз данных, достаточно подробна, в ней ничего не говорится о том, что для реализации большинства предлагаемых вариантов необходимо приобретать дополнительные лицензии. Иными словами, если вы создаете «простую», состоящую из двух узлов и предназначенную исключительно для обеспечения высокой степени готовности группу доступности (тогда, кстати, в ряде ситуаций представляется более логичным использовать решение FCI), единственный параметр, который вы фактически сможете указать, — это Primary. Выбрав его, вы тем самым заявите о своем желании генерировать резервные копии на сервере или для сервера, где размещается основная реплика. Любой другой вариант будет вполне обоснованно отнесен к категории сценариев развертывания, а для поддержки операций развертывания вам потребуется дополнительная лицензия. Таким образом, если вы подумываете о том, чтобы разгрузить свой основной сервер и перенести процесс резервирования с него на дополнительный сервер для перераспределения нагрузки, имейте в виду, что это вполне возможный вариант. Но в данном случае речь не идет о простом сценарии обеспечения отказоустойчивости, и, следовательно, положения о лицензировании типичной программы Software Assurance, предусматривающие «бесплатную» лицензию отказоустойчивости или хост на каждый полностью лицензированный основной/активный хост, на эту ситуацию не распространяются.

Второй «подводный камень» состоит в том, что настройки не выполняют никакой работы. Перейдя на вкладку Backup Preferences (или действуя напрямую средствами языка T-SQL), вы можете колдовать над настройками с утра до вечера, однако ничто из того, что вы сделаете, не сможет побудить SQL Server ни подчиниться вашим указаниям, ни даже выполнить какую-либо проверку.

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

Иначе говоря, хотя вы можете указывать предпочтительные параметры в рамках настроек группы доступности, если вы хотите, чтобы ваши резервные копии «принимали» или хотя бы «рассматривали» эти предпочтительные значения, вам придется кодировать данную функцию вручную. А отсюда, в свою очередь, следует, что с целью привлечения внимания к упомянутым установкам вам придется формировать вокруг резервных копий дополнительные логические конструкции, после чего выполнять (или не выполнять) резервное копирование соответствующим образом.

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

Выполнение резервных копий

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

  • Ручные сценарии (подготовленные на языке T-SQL или с помощью PowerShell либо аналогичного продукта), предусматривающие выполнение резервных копий в соответствии с заданным расписанием, а также удаление ранее сделанных резервных копий для высвобождения дискового пространства.
  • Планы обслуживания SQL Server. Я расскажу о них подробно в одной из следующих статей.
  • Специализированные инструменты и решения от независимых поставщиков, предназначенные для выполнения таких задач, как резервирование содержимого нескольких серверов, шифрование, а также (для версий, предшествующих SQL Server 2008/2008 R2) сжатие резервных копий. Я не имею в виду средства резервного копирования от сторонних поставщиков, предназначенные прежде всего для резервирования «файлов», поставляемых с дополнительными компонентами «SQL Server»: некоторые из этих решений функционируют вполне нормально, но другие вытворяют с базами данных невообразимые вещи.
  • Сценарии от сторонних поставщиков — такие, как превосходное решение SQL Server Backup компании Ola Hallengren. С помощью подобных инструментов можно управлять резервными копиями и другими обслуживающими программами (включая средства поддержки управления резервными копиями с помощью поставляемых сторонними поставщиками продуктов, обеспечивающих управление резервными копиями).

Но в любом случае, независимо от того, указывает ли администратор баз данных предпочтительные настройки с помощью графического интерфейса (что происходит при использовании средств резервного копирования от сторонних поставщиков либо планов обслуживания SQL Server) или вручную, вводя значения и настройки в набор сценариев (собственных либо тех, что предлагаются в продукте Ola), конечный результат сводится к следующему. Администратор баз данных получает набор команд на языке T-SQL, которые в конце концов выполняются применительно к целевым системам SQL Server, с тем чтобы запускать резервные копии и попутно решать другие задачи.

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

Управление резервными копиями с предпочтительными репликами групп доступности AlwaysOn

В системах SQL Server 2012 и более новых версий предусмотрен механизм, позволяющий оценить, выполняется ли запущенный код на предпочтительном сервере: он реализован в виде функции процедуры sys.fn_hadr_backup_is_preferred_replica. Здесь можно найти примеры того, как выполняются проверки на выполнение условий if. Правда, в приведенных примерах используется оператор RETURN, который нельзя применять в рамках шага задания агента SQL Server (пример, использованный в образце документации, был явно написан как часть хранимой процедуры, которая управляет резервными копиями, а этим, на мой взгляд, вряд ли будут заниматься многие администраторы баз данных). Но как бы то ни было, общая идея механизма управления данной функцией довольно проста, как показано в следующем образце псевдокода:

1. If sys.fn_hadr_backup_is_preferred_
   replica ('nameOfTargetDBHere') = 1 BEGIN
2. PRINT 'This is the primary —
   execute backups here.';
3. END
4. ELSE BEGIN
5. PRINT 'This is NOT the primary.
   Don''t do anything here.';
6. END

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

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

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

В остальном же единственная реальная проблема, возникающая в процессе настройки кода для управления резервными копиями, состоит во «внедрении» проверок на выполнение условия (if checks) в программы, которые вы уже используете. Так, если вы пользуетесь средствами резервного копирования данных SQL Server от сторонних изготовителей (таких, как Redgate, Idera, LightSpeed, Apex SQL и т. д.), вам нужно будет отыскать все фрагменты кода на языке T-SQL, создаваемые в процессе выполнения этих заданий (по всем хостам группы доступности AlwaysOn) и «встроить» вызываемые и исполняемые компоненты в логику проверок на выполнение условия, которая выполняет соответствующую резервную копию лишь в том случае, если предпочтительные реплики размещаются на сервере, о котором идет речь.

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

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