Создание резервной копии БД в Azure Storage

В предыдущих статьях по миграции в «облачный» SQL Server мы рассмотрели различные возможности передачи резервной копии базы в Облако. На всякий случай следует сразу напомнить, что речь идет о IaaS-подходе, т.е. развертывании SQL Server на виртуальной машине Windows Azure. Альтернативный PaaS-подход принципиально отличен, т.к. Windows Azure SQL Database (SQL Azure) не поддерживает функциональности в виде штатных команд T-SQL backup/restore. Также нет возможности отсоединять и присоединять файлы БД (detach/attach). Там следует применять другие методы, такие, как DAC, BCP, SSIS, SQL Azure Sync и т.д. В данной статье мы продолжаем обзор способов, относящихся к IaaS, и, коль скоро в нем нет проблемы сделать/поднять бэкап, основной рабочий момент состоит в том, чтобы оптимально передать резервную копию базы в Облако и обратно. В этом плане он ничем не отличается от загрузки или скачивания любого блоба в/из Azure Storage. Нами были рассмотрены использование Blob Service REST API (http://msdn.microsoft.com/en-us/library/dd135733.aspx), который является очень простым по своей идее, но достаточно кропотливым в реализации, поскольку требует аккуратно сформировать тело PUT-запроса. Упростить процесс позволяет обертка, предоставляемая Azure SDK (http://msdn.microsoft.com/en-us/library/dd179380.aspx), который имеет в своем составе готовые классы, инкапсулирующие подготовительную работу, которую требуется выполнять вручную в случае использования «сырого» REST API. Наконец, мы рассмотрели процесс передачи резервной копии на отдельном vhd-диске, который присоединяется к облачной виртуалке. С выходом Cumulative Update 2 к SQL Server 2012 SP1 этот процесс еще более упростился, т.к. теперь стало возможным создавать резервные копии базы непосредственно в Azure Storage с помощью штатных команд T-SQL и, соответственно, восстанавливаться с них. Вся не относящаяся к функциональности SQL Server служебная работа по передаче резервной копии в Облако встроена внутрь T-SQLных команд. От нас потребуется только иметь учетную запись хранения (Windows Azure Storage Account), которая будет использоваться для промежуточного хранения резервной копии.

Процесс создания storage account мы разбирали в статье, посвященной Blob Service REST API (http://blogs.technet.com/b/isv_team/archive/2012/10/25/3528566.aspx) и сейчас не будем на этом подробно останавливаться. Напомню на всякий случай, что создавать его имеет смысл в том же датацентре, где находится виртуальная машина с SQL Server, на которой предполагается восстановливать резервную копию, чтобы сэкономить на трафике между датацентрами. Например, в моем случае виртуальная машина lvmtest4 с экземпляром SQL Server по умолчанию, расположена в локации North Europe. Там же будет создана учетная запись сториджа tststorage для передачи бэкапа базы. Более подробно процесс создания описан в документации к Windows Azure (http://msdn.microsoft.com/en-us/library/windowsazure/gg433066.aspx). Внутри эккаунта мы создадим контейнер container1 (заглавные буквы в названии контейнера не поддерживаются). В целях безопасности контейнер будет создан как private, что означает, что для доступа к его содержимому потребуется указывать Access Key (первичный или вторичный), посмотреть которые можно в свойствах Storage Account.
Из пререквизитов нам еще понадобится установленный на локальном SQL Server 2012 CU2 к SP1. Как водится, кумулятивные апдейты будут, скорее всего, включены в следующий сервис-пак, но на момент написания данной статьи требуется на SQL Server 2012 установить Service Pack 1 (если он еще не установлен) (http://www.microsoft.com/en-us/download/details.aspx?id=35575), а затем кумулятивный апдейт 2 к этому сервис-паку (http://support.microsoft.com/kb/2790947). Когда мы проходили этот вопрос на Windows Azure Summit, слушатели обратили внимание на фразу This service pack contains SQL Server 2012 Cumulative Update 1 (CU1) and Cumulative Update 2 (CU2), поэтому, наверно, лучше лишний раз уточнить. В ней речь идет про кумулятивные апдейты к “голому” SQL Server 2012. Нам нужен CU2 к SP1. По ссылке открывается форма, в форме отмечаем, какой именно файл нужен (я отметил все три) и указываем e-mail, на который буквально сразу приходит письмо от hotfix@microsoft.com, содержащее ссылки, откуда что брать. Для наших целей достаточно поставить SQLServer2012_SP1_CU2_2790947_11_0_3339_x64, чтобы select @version была не ниже Microsoft SQL Server 2012 (SP1) — 11.0.3339.0 (X64), Jan 14 2013 19:02:10, Build 9200.
Чтобы локальный SQL Server смог доступиться до облачного сториджа, на нем предварительно нужно создать удостоверение (credential), в котором будут указаны название учетной записи сториджа и один из его ключей доступа (первичный или вторичный, без разницы).

if exists (select 1 from sys.credentials where name = 'SqlToAzureStorage' and credential_identity = 'tststorage') drop credential SqlToAzureStorage CREATE CREDENTIAL SqlToAzureStorage WITH IDENTITY= 'tststorage' --storage account , SECRET = 'oY1AUn6/5/IWz8dfQJzidOVY8HRUKOz1k5MsSnV86xV46fEtQCAigC3Fd8Lgkn2fv6SotsRpZm6w2tRaQVAovw=='
Скрипт 1

Ключи доступа можно найти в управлении учетной записью сториджа в Windows Azure Management Portal, если в верхнем меню выбрать пункт Configure, а в нижнем — Manage Keys.

Рис.1

Рис.2

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

BACKUP DATABASE AdventureWorks2012 TO URL = 'https://tststorage.blob.core.windows.net/container1/AdventureWorks2012.bak' WITH CREDENTIAL = 'SqlToAzureStorage', INIT, STATS = 10
Скрипт 2

Здесь все понятно. Строка URL формируется по принципу <имя учетной записи Azure Storage>. blob.core.windows.net/<название контейнера>/<как будет называться файл бэкапа, созданный в этом контейнере>’. Ее можно посмотреть в Windows Azure Management Portal в свойствах контейнера:

Рис.3

Если CU2 к SP1 не установлен, при выполнении этой команды происходит ошибка Msg 155, Level 15, State 1, Line 2. ‘URL’ is not a recognized Device Type option. Но мы его установили, поэтому все выполняется успешно.

Рис.4

Если теперь зайти в контейнер container1 на Рис.3, мы увидим, что там создался бэкап AdventureWorks2012.bak.
Комментарии:
• Максимальный размер резервной копии не должен превышать 1 ТБ, что связано с ограничениями Azure Blob Storage.
• Поддерживается создание не только полной резервной копии базы, но и резервных копий журнала транзакций, файловых групп, дифференциальное резервное копирование, а также сжатие бэкапов.
• Если файл с таким именем уже существует в контейнере, произойдет ошибка. Чтобы его переписать, используйте опцию FORMAT.
• Из интерфейса SSMS создание резервной копии базы в Azure Blob Storage пока не поддерживается.
Теперь заходим на облачную виртуалку с установленным на ней SQL Server, создаем удостоверение (Скрипт 1) и совершенно симметрично восстанавливаем на ней базу из свежесозданного облачного бэкапа. Понятно, что на том SQL Server также должен стоять SP1 CU2.

RESTORE DATABASE AdventureWorks2012 FROM URL = 'https://tststorage.blob.core.windows.net/container1/AdventureWorks2012.bak' WITH CREDENTIAL = 'SqlToAzureStorage', REPLACE, STATS = 10
Скрипт 3

Рис.5

Аналогично можно делать в обратном направлении: создавать резервную копию в Облаке и поднимать ее на on-premise SQL Server, а также передавать базу между облачными или on-premise машинами.