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

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

Кстати, я по-прежнему считаю, что, если вы развернули группы доступности 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 с использованием сценариев или с помощью предназначенных для работы с резервными копиями инструментов и решений от независимых производителей. Далее мы рассмотрим некоторые из этих возможностей, а также специфические трудности, касающиеся деталей реализации.