Предыдущий способ переноса резервной копии базы с локального компьютера на виртуальную машину с SQL Server в Облаке использовал Azure Storage, который не является NTFS-видимым. Таким образом, перед восстановлением бэкап базы нужно было скопировать из Azure Storage на виртуальный диск, чтобы установленный на виртуалке SQL Server его увидел. В случае БД значительного объема это ведет к неоправданному расходу пространства в Azure Storage и, как следствие, к дополнительным затратам: сначала бэкап загружается в облачное хранилище, а затем копируется в vhd, который хранится там же. Чтобы избежать этих затрат, в этой статье мы рассмотрим иной способ. Локально будет создан отдельный vhd, на котором будет размещен бэкап базы. Затем vhd будет загружен в Azure Storage и приаттачен в качестве дополнительного диска облачной виртуалки. С него будет произведено восстановление резервной копии.
Чтобы локально создать виртуальный диск, заходим в Administrative ToolsComputer ManagementDisk Management и выбираем пункт Create VHD из контекстного меню. Указываем полный путь к vhd-файлу, который будет создан, желаемый размер, достаточный для того, чтобы вместить резервную копию базы, а также — будет ли этот размер фиксированный или динамически расширяемый. Кликаем по диску и выбираем из контекстного меню пункт «Инициализировать диск». Создаем том и форматируем его под NTFS. Созданный vhd начинает видеться как дополнительный диск локальной машины. Копируем на него бэкап базы.
Для проверки созданный vhd можно добавить в качестве дополнительного диска к локальной виртуалке. На всякий случай напомню, что в Windows 8 технология виртуализации Hyper-V (включая средство управления Hyper-V Manager) поддерживается, что называется, из коробки. Не требуется устанавливать Hyper-V Server отдельно и администрировать при помощи RSAT, как было в случае Windows 7. У меня по случаю имеется локальная виртуальная машина, которой я делаю shutdown и присоединяю дополнительный диск. Перед стартом виртуальной машины vhd требуется детачить в Disk Management на хосте. Убедившись, что содержание диска нормально читается на локальной виртуальной машине, гасим ее, отсоединяем диск, нажав кнопку Remove на Рис.10, и загружаем диск в Azure Storage. Проще всего это сделать при помощи утилиты csupload, входящей в состав Windows Azure SDK, который мы поставили в предыдущей статье. Перед загрузкой предварительно требуется создать сертификат X.509 v3, как указано в документации. Для этого я воспользуюсь утилитой makecert, которая ставится, например, в составе Visual Studio:
"C:Program Files (x86)Windows Kits8.0binx86makecert.exe" -sky exchange -r -n "CN=MyCert" -pe -a sha1 -len 2048 -ss My "c:TempMyCert.cer"
Скрипт 1
Теперь сертификат нужно положить в Облако. Заходим в Azure Management Portal, кликаем на Settings в левой панели, внизу нажимаем кнопку Upload. Находим файл сертификата c:TempMyCert.cer, созданный в Скрипте 1 и указываем его для загрузки. Сертификат успешно загружается. Для загрузки vhd в Azure Storage должен иметься Storage Account. Как минимум, один был создан автоматически на этапе создания виртуальной машины, а второй мы создали в предыдущей статье для загрузки файла бэкапа. Не имеет значения, какой из них использовать. Я возьму последний (tststorage), в котором создам приватный контейнер myvhds, чтобы положить туда свежесозданный виртуальный диск с бэкапом базы. Напомню, что заглавные буквы в названии контейнера не воспринимаются. Для использования утилиты csupload требуется сформировать строку соединения. Это можно сделать непосредственно в момент загрузки или предварительно.
"C:Program FilesMicrosoft SDKsWindows Azure.NET SDK2012-06bincsupload.exe" Set-Connection "SubscriptionID=1145d36f-60d2-4db3-91e7-7cd730599e27;CertificateThumbprint=8BC0B6D0C1A010CABECF558612A21D2CCDFD679F;ServiceManagementEndpoint=https://management.core.windows.net"Скрипт 2
Параметр ServiceManagementEndpoint является константой. Основными параметрами при формировании строки соединения выступают SubscriptionID и CertificateThumbprint. Их можно скопировать в свойствах сертификата. Ширины колонок раздвигаются и, при необходимости, скроллируются по горизонтали. В непосредственно загрузке диска тоже все понятно: откуда берем vhd-файл (LiteralPath), куда кладем (Storage Accountконтейнер блобовского сториджа — Destination) и как обзываем (Label). Параметр Add-Disk указывает, что загружается именно диск, а не, скажем, образ. В параметре OS — что это будет диск для виртуальной машины Windows, а не Linux. По умолчанию, предполагается, естественно, Windows. Подробно ознакомиться с параметрами утилиты csupload можно в документации.
"C:Program FilesMicrosoft SDKsWindows Azure.NET SDK2012-06bincsupload.exe" Add-Disk -Destination "https://tststorage.blob.core.windows.net/myvhds/aaa_disk" -Label aaa_disk -LiteralPath "c:tempaaa.vhd" -OS Windows
Скрипт 3
После загрузки свежеположенный диск можно видеть в Azure Management Portal -> Virtual Machines -> Disks. Остается присоединить его к облачной виртуалке. Виртуалку при этом можно не гасить. В верхней строке переключаемся на Virtual Machine Instances, в нижней жмем Attach и выбираем диск среди доступных загруженных и неподключенных. В нашем примере такой сейчас всего один. Ждем, когда статус виртуалки сменяется с Running (Updating) на просто Running и соединяемся с ней по удаленному RDP-подключению. Видим диск F: с Volume Label = aaa, как заказывали, а на нем резервную копию базы AdventureWorks2012.bak, с которой восстанавливаемся. После чего диск aaa нам больше не нужен. Отсоединяем его аналогично подключению (кнопка Detach Disk в нижней строке) и удаляем из дисков вместе с соответствующим ему vhd-файлом (не из Storage), нажав кнопку Delete Disk -> Delete the associated VHD, чтобы не платить за лишнее место.
Автор: alexejs
