Облако выполняет роль хаба. До сих пор это могло делаться только из скрипта T-SQL. В версии 2014 СТР в этот процесс добавились две новые возможности. Во-первых, выполнять резервное копирование в Windows Azure теперь можно непосредственно из интерфейса SQL Server Management Studio и включать его на регулярной основе в автоматизированный план поддержки базы, и во-вторых, что немаловажно, осуществлять шифрование резервных копий с использованием сертификатов или асимметричных ключей на основе криптостойких алгоритмов защиты. Впрочем, обо всем по порядку.
Для начала нам, как нетрудно догадаться, понадобится, собственно, SQL Server 2014 CTP2, взять который можно здесь. Срок действия этой пробной версии истекает 31 марта 2014 г. При скачивании потребуется выбрать тип дистрибутива (iso/cab/Azure), разрядность (32- или 64-битный) и язык. На данный момент предлагаются English, German, Spanish, Japanese, Chinese (Traditional). В релизе русский, как всегда, поддерживаться будет, ну пока вот то, что есть. Установка не вызывает каких-либо неожиданностей/сложностей по сравнению с текущей версией. Я поставил 2014 CTP2 бок о бок именованным экземпляром рядом с 2012. Сосуществуют нормально, не дерутся в отличие от СТР1. Можно приступать к экспериментам.
Запускаем новую SQL Server Management Studio. Для счастливых обладателей Windows 8.x, которые не пользуются детальными плитками на стартовом экране, где они сгруппированы по SQL Server 2012, SQL Server 2014 и т.д.
Рис.1
а предпочитают по-быстрому набрать в строке поиска что-нибудь типа "sql":
Рис.2
теперь этих плиток несколько. Нужно выбирать ту, которая относится к C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SQL Server 2014 CTP2, т.е. ссылается на C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe.
В SSMS из контекстного меню базы выбираем, как всегда, Tasks -> Back Up и обращаем внимание, что в новом интерфейсе резервного копирования наряду с традиционным диском появился еще URL в качестве альтернативной опции размещения резервной копии.
Рис.3
Если в SSMS 2014 CTP2 подключить экземпляр сервера версии 2012 и ниже, эта опция для него доступна не будет. Для экземпляров 2014 СТР2 она доступна независимо от того, в каком compatibility level находится база.
После выбора Back up to = URL интерфейс секции Destination изменяется так, чтобы предоставить возможность ввода параметров, которые мы ранее использовали в команде BACKUP DATABASE… TO URL (см. Скрипт 2). Требуется задать. File name - имя файла резервной копии, который будет сохранен в сторидже Windows Azure.
Рис.4
Нажатие кнопки Create напротив SQL Credential соответствует выполнению команды CREATE CREDENTIAL (см. Скрипт 2). Для подтверждения подлинности при обращении к облачной подписке можно использовать сертификат управления или профиль публикации (файл с расширением .publishsettings). Второй способ мы использовали в посте Введение в разработку и тестирование приложений в Облаке (Рис.16-17), поэтому здесь для разнообразия посмотрим первый способ.
Рис.5
Открываем командную строку Visual Studio от лица администратора и создаем самозаверяющий сертификат для работы с Windows Azure с длиной ключа не менее 2048 бит, который сохраняется в хранилище сертификатов по умолчанию - Personal.makecert -sky exchange -r -n "CN=AzureCert" -pe -a sha1 -len 2048 -ss My
Скрипт 1
Рис.6
Если Visual Studio нет, утилиту makecert можно скачать, например, в составе Windows 8 SDK. После этого искать ее нужно где-нибудь в C:\Program Files (x86)\Windows Kits\8.х\bin\x64.
Чтобы проверить, что сертификат создан успешно, вызываем обычное командное окно (лучше опять-таки от имени администратора) и вводим certmgr.msc. В разделе Personal видим свежесозданный сертификат.
Рис.7
Экспортируем его (без закрытого ключа) в .cer-файл. Из контекстного меню сертификата выбираем All Tasks -> Export:
Рис.8
Рис.9
Рис.10
Теперь идем в портал администрирования Windows Azure, выбираем в панели слева последний пункт Settings, в верхнем меню - Management Certificates, а внизу нажимаем кнопку Upload и указываем .cer-файл, экспортированный на Рис.10.
Рис.11
Он появляется в списке сертификатов:
Рис.12
Возвращаемся на Рис.5, нажимаем кнопку Select (management certificate from the certificate store) и в открывшемся окне выбираем строчку со свежесозданным сертификатом AzureCert:
Рис.13
В текстбоксе слева от кнопки Select появляется thumbprint указанного сертификата.
Остается ввести подписку - ее имя или ID можно прочесть там же, в Settings портала администрирования Windows Azure (Рис.11-12), если в верхнем меню сдвинуться влево на пункт Subcriptions.
Рис.14
После ввода сертификата управления Windows Azure и Subscription ID перемещаемся на комбобокс Storage Account. Происходит небольшая пауза, в ходе которых SSMS пытается зайти в облако, указывая заданную подписку и сертификат, все у нее получается, и внизу открывается список учетных записей хранения Azure, относящихся к данной подписке.
Рис.15
Выбираем интересующую, в которую будет происходить бэкап, и жмем кнопку Create. Создается Credential, и мы возвращаемся на Рис.4. Остается указать контейнер выбранной учетной записи хранения Azure. Как и в предыдущем посте, я укажу публичный контейнер container1. Поле URL prefix при этом заполняется автоматически. Если все уазано правильно, редактировать его не требуется.
Рис.16
Жмем кнопку ОК, бэкап начинает выполняться.
Рис.17
После его окончания заходим в контейнер container1 учетной записи хранения tststorage на портале управления Windows Azure и наблюдаем свежесозданный в нем блоб, в котором находится файл резервной копии БД AdventureWorks:
Рис.18
Восстановление выполняется аналогично.
В следующей серии мы разберем новые возможности шифрования резервных копий.