Резервное копирование и восстановление баз данных SQL в виртуальных машинах Azure с помощью PowerShell
В этой статье описывается, как использовать Azure PowerShell для резервного копирования и восстановления базы данных SQL в виртуальной машине Azure с помощью хранилища Служб восстановления Azure Backup.
В статье описывается выполнение следующих задач:
- Настройте PowerShell и зарегистрируйте поставщик Служб восстановления Azure.
- Создайте хранилище служб восстановления.
- Настройте резервное копирование для базы данных SQL на виртуальной машине Azure.
- Запустите задание резервного копирования.
- Восстановите резервную копию базы данных SQL.
- Отслеживайте задания резервного копирования и восстановления.
Перед началом работы
- Дополнительные сведения о хранилищах Служб восстановления.
- Прочитайте о возможностях резервного копирования баз данных SQL на виртуальных машинах Azure.
- Изучите иерархию объектов PowerShell для Служб восстановления.
Иерархия объектов Служб восстановления
Иерархия объектов представлена на следующей схеме.
Ознакомьтесь с руководством по командлету Az.RecoveryServices в библиотеке Azure.
Настройка и установка
Настройка PowerShell:
Скачайте последнюю версию Az PowerShell. Минимальная требуемая версия — 1.5.0.
Найдите командлеты PowerShell Azure Backup с помощью следующей команды:
Get-Command *azrecoveryservices*Просмотрите псевдонимы и командлеты для Azure Backup и хранилища Служб восстановления. Ниже приведен пример того, что нам необходимо. Это неполный список командлетов.
Войдите в учетную запись Azure с помощью командлета Connect-AzAccount.
На появившейся веб-странице содержится предложение ввести данные учетной записи.
- Кроме того, данные учетной записи можно добавить в качестве параметра в командлет Connect-AzAccount, используя параметр -Credential.
- Если вы партнер-поставщик облачных услуг, работающий для клиента, вам потребуется указать заказчика в качестве клиента. Для этого нужно ввести идентификатор или основное доменное имя клиента. Например: Connect-AzAccount-Tenant fabrikam.com.
Свяжите подписку, которую собираетесь использовать, с учетной записью, так как последняя может иметь несколько подписок.
Select-AzSubscription -SubscriptionName $SubscriptionNameЕсли вы используете службу архивации Azure впервые, выполните командлет Register-AzResourceProvider, чтобы зарегистрировать поставщик Служб восстановления Azure в своей подписке.
Register-AzResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"Убедитесь в успешной регистрации поставщиков, выполнив следующие команды:
Get-AzResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"В выходных данных команды для RegistrationState должно быть установлено значение Registered. Если это не так, повторно выполните командлет Register-AzResourceProvider.
Создание хранилища Служб восстановления
Чтобы создать хранилище Служб восстановления, выполните описанные ниже действия.
Хранилище Служб восстановления представляет собой ресурс Resource Manager, поэтому вам потребуется разместить его в группе ресурсов. Вы можете использовать имеющуюся группу ресурсов или создать новую, выполнив командлет New-AzResourceGroup. При создании группы ресурсов укажите ее имя и расположение.
Хранилище помещается в группу ресурсов. Если у вас нет существующей группы ресурсов, создайте новую с помощью командлета New-AzResourceGroup. В этом примере мы создаем новую группу ресурсов в регионе "Западная часть США".
New-AzResourceGroup -Name "test-rg" -Location "West US"С помощью командлета New-AzRecoveryServicesVault создайте хранилище. Разместите хранилище там же, где находится группа ресурсов.
New-AzRecoveryServicesVault -Name "testvault" -ResourceGroupName "test-rg" -Location "West US"Укажите тип избыточности, который будет использоваться для хранения хранилища.
- Можно использовать локально избыточное хранилище, геоизбыточное хранилище или хранилище, избыточное между зонами.
- В следующем примере для параметра Set-AzRecoveryServicesBackupProperty для
testvault-BackupStorageRedundancyпараметра set задано значение .GeoRedundant
$vault1 = Get-AzRecoveryServicesVault -Name "testvault" Set-AzRecoveryServicesBackupProperties -Vault $vault1 -BackupStorageRedundancy GeoRedundant
Просмотр хранилищ в подписке
Выполнив командлет Get-AzRecoveryServicesVault, вы получите список всех хранилищ в подписке.
Get-AzRecoveryServicesVault
Выход аналогичен приведенному ниже. Предоставляются связанная группа ресурсов и расположение.
Name : Contoso-vault
ID : /subscriptions/1234
Type : Microsoft.RecoveryServices/vaults
Location : WestUS
ResourceGroupName : Contoso-docs-rg
SubscriptionId : 1234-567f-8910-abc
Properties : Microsoft.Azure.Commands.RecoveryServices.ARSVaultProperties
Задание контекста хранилища
Сохраните объект хранилища в переменной и задайте контекст хранилища.
- Многие командлеты Azure Backup нуждаются в объекте хранилища Служб восстановления в качестве входных данных, поэтому объект хранилища удобно хранить в переменной.
- Контекст хранилища — это тип данных, защищаемых в хранилище. Задайте его с помощью Set-AzRecoveryServicesVaultContext. Заданный контекст применяется ко всем последующим командлетам.
Следующий пример задает контекст хранилища для testvault
Get-AzRecoveryServicesVault -Name "testvault" | Set-AzRecoveryServicesVaultContext
Получение идентификатора хранилища
Мы планируем отказаться от параметра контекста хранилища в соответствии с рекомендациями Azure PowerShell. Вместо этого можно сохранить или извлечь идентификатор хранилища и передать его в соответствующие команды следующим образом.
$testVault = Get-AzRecoveryServicesVault -ResourceGroupName "Contoso-docs-rg" -Name "testvault"
$testVault.ID
Настройка политики резервного копирования
Политика архивации определяет расписание резервного копирования и время хранения резервных точек восстановления.
- Политика резервного копирования связана по крайней мере с одной политикой хранения. Политика хранения определяет продолжительность хранения точки восстановления до ее удаления.
- Просмотрите политику резервного копирования по умолчанию с помощью команды Get-AzRecoveryServicesBackupRetentionPolicyObject.
- Просмотрите политику резервного копирования по умолчанию с помощью команды Get-AzRecoveryServicesBackupSchedulePolicyObject.
- Для создания новой политики резервного копирования используется командлет New-AzRecoveryServicesBackupProtectionPolicy. Следует ввести расписание и объекты политики хранения.
По умолчанию время запуска определено в объекте политики Schedule. Используйте следующий пример, чтобы изменить время запуска на нужное значение. Требуемое время запуска также должно быть в формате UTC. В следующем примере предполагается, что требуемое время запуска для ежедневного резервного копирования — 01:00 UTC.
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType "MSSQL"
$UtcTime = (Get-Date -Date "2019-03-20 01:30:00Z").ToUniversalTime()
$schPol.FullBackupSchedulePolicy.ScheduleRunTimes[0] = $UtcTime
Важно!
Время запуска должно быть указано с кратностью 30 минут. В приведенном выше примере это может быть только "01:00:00" или "02:30:00". Время начала не может быть "01:15:00".
В следующем примере показано сохранение политик расписания и хранения в переменных. Затем эти переменные используются в качестве параметров для новой политики (NewSQLPolicy). NewSQLPolicy создает ежедневную полную резервную копию, хранит ее в течение 180 дней и создает резервную копию журнала каждые 2 часа.
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType "MSSQL"
$retPol = Get-AzRecoveryServicesBackupRetentionPolicyObject -WorkloadType "MSSQL"
$NewSQLPolicy = New-AzRecoveryServicesBackupProtectionPolicy -Name "NewSQLPolicy" -WorkloadType "MSSQL" -RetentionPolicy $retPol -SchedulePolicy $schPol
Выход аналогичен приведенному ниже.
Name WorkloadType BackupManagementType BackupTime Frequency IsDifferentialBackup IsLogBackupEnabled
Enabled
---- ------------ -------------------- ---------- --------- -------------------- ------------------
NewSQLPolicy MSSQL AzureWorkload 3/15/2019 01:30:00 AM Daily False True
Включение резервного копирования
Регистрация виртуальной машины SQL
Для резервных копий виртуальных машин Azure и файловых ресурсов Azure служба резервного копирования может подключаться к этим ресурсам Azure Resource Manager и получать соответствующие сведения. SQL — приложение внутри виртуальной машины Azure, поэтому службе резервного копирования требуется разрешение на доступ к приложению и получение необходимых сведений. Для этого необходимо зарегистрировать виртуальную машину Azure, содержащую приложение SQL, в хранилище Служб восстановления. После регистрации виртуальной машины SQL в хранилище можно защитить базы данных SQL только с помощью этого хранилища. Для регистрации виртуальной машины используйте командлет PowerShell Register-AzRecoveryServicesBackupContainer.
$myVM = Get-AzVM -ResourceGroupName <VMRG Name> -Name <VMName>
Register-AzRecoveryServicesBackupContainer -ResourceId $myVM.ID -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID -Force
Команда вернет "контейнер резервной копии" этого ресурса, а состоянием будет "зарегистрировано"
Примечание.
Если параметр force не указан, появится запрос на подтверждение с текстом "Do you want to disable protection for this container" (Отключить защиту для этого контейнера). Проигнорируйте этот текст и укажите "Y" для подтверждения. Это известная проблема, и мы работаем над удалением этого текста и обязательности параметра force.
Получение баз данных SQL
После завершения регистрации служба Microsoft Azure Backup сможет перечислить все доступные компоненты SQL в виртуальной машине. Чтобы просмотреть все компоненты SQL, для которых еще не выполнено резервное копирование в это хранилище, используйте командлет PowerShell Get-AzRecoveryServicesBackupProtectableItem.
Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -VaultId $testVault.ID
В выходных данных будут показаны все незащищенные компоненты SQL для всех виртуальных машин SQL, зарегистрированных в этом хранилище, с типом элемента (ItemType) и именем сервера (ServerName). Можно дополнительно отфильтровать определенную виртуальную машину SQL, передав параметр "-Container" или указав сочетание "Name" и "ServerName" вместе с флагом ItemType, чтобы приступить к уникальному элементу SQL.
$SQLDB = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLDataBase -VaultId $testVault.ID -Name "<Item Name>" -ServerName "<Server Name>"
Настройка резервного копирования
Теперь, когда у нас есть необходимая база данных SQL и политика, с помощью которой необходимо создать резервную копию, мы можем использовать командлет Enable-AzRecoveryServicesBackupProtection, чтобы настроить резервное копирование для этой базы данных SQL.
Enable-AzRecoveryServicesBackupProtection -ProtectableItem $SQLDB -Policy $NewSQLPolicy
Команда ожидает завершения конфигурации резервного копирования и возвращает следующие выходные данные.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
master ConfigureBackup Completed 3/18/2019 6:00:21 PM 3/18/2019 6:01:35 PM 654e8aa2-4096-402b-b5a9-e5e71a496c4e
Получение новых баз данных SQL
После регистрации машины служба Microsoft Azure Backup выберет сведения о доступных базах данных. Если впоследствии добавить базы данных SQL или экземпляры SQL на зарегистрированную машину, необходимо будет вручную запустить службу резервного копирования, чтобы выполнить новый запрос для получения всех незащищенных баз данных (включая новые добавленные). Используйте командлет PowerShell Initialize-AzRecoveryServicesBackupItem на виртуальной машине SQL для выполнения нового запроса. Команда ожидает завершения операции. Позже используйте командлет PowerShell Get-AzRecoveryServicesBackupProtectableItem, чтобы получить список последних незащищенных компонентов SQL.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Initialize-AzRecoveryServicesBackupProtectableItem -Container $SQLContainer -WorkloadType MSSQL -VaultId $testVault.ID
Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLDataBase -VaultId $testVault.ID
После получения соответствующих защищаемых элементов включите резервное копирование, как указано в приведенном выше разделе. Чтобы не определять новые базы данных вручную, можно выбрать автоматическую защиту, как описано ниже.
Включение автоматической защиты
Резервное копирование можно настроить таким образом, чтобы все базы данных, которые будут добавлены в будущем, автоматически защищались с помощью определенной политики. Чтобы включить автоматическую защиту, используйте командлет PowerShell Enable-AzRecoveryServicesBackupAutoProtection.
Так как инструкция предназначена для резервного копирования всех будущих баз данных, операция выполняется на уровне SQLInstance.
$SQLInstance = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLInstance -VaultId $testVault.ID -Name "<Protectable Item name>" -ServerName "<Server Name>"
Enable-AzRecoveryServicesBackupAutoProtection -InputItem $SQLInstance -BackupManagementType AzureWorkload -WorkloadType MSSQL -Policy $NewSQLPolicy -VaultId $testVault.ID
После того как цель автоматической защиты задана, выполняется запрос к машине для получения новых добавленных баз данных в виде запланированной фоновой задачи каждые 8 часов.
Восстановление баз данных SQL
В Azure Backup можно выполнить восстановление баз данных SQL Server, запущенных на виртуальных машинах Azure, следующим образом.
- Восстановление баз данных в состоянии на определенную дату или время (до секунды) с помощью резервных копий журнала транзакций. На основе выбранного времени Azure Backup автоматически определяет соответствующее полное разностное резервное копирование и цепочку резервных копий журналов, необходимых для восстановления.
- Восстановление конкретной полной или разностной резервной копии по определенной точке восстановления.
Перед восстановлением баз данных SQL проверьте предварительные требования, описанные здесь.
Предупреждение
Из-за проблемы безопасности, связанной с RBAC, нам пришлось реализовать критическое изменение в командах восстановления для SQL DB с помощью PowerShell. Выполните обновление до AZ 6.0.0 или более поздней версии, чтобы правильно отправлять команды восстановления с помощью PowerShell. Ниже приведены актуальные команды PS.
Сначала получите соответствующую резервную копию базы данных SQL с помощью командлета PowerShell Get-AzRecoveryServicesBackupItem.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
Получение соответствующего времени восстановления
Как отмечено выше, можно восстановить резервную копию базы данных SQL в виде полной или разностной копии или на момент времени в журнале.
Получение уникальных точек восстановления
Используйте командлет Get-AzRecoveryServicesBackupRecoveryPoint для получения уникальных (полных или разностных) точек восстановления резервной копии базы данных SQL.
$startDate = (Get-Date).AddDays(-7).ToUniversalTime()
$endDate = (Get-Date).ToUniversalTime()
Get-AzRecoveryServicesBackupRecoveryPoint -Item $bkpItem -VaultId $testVault.ID -StartDate $startdate -EndDate $endDate
Вы должны увидеть результат, аналогичный приведенному ниже.
RecoveryPointId RecoveryPointType RecoveryPointTime ItemName BackupManagemen
tType
--------------- ----------------- ----------------- -------- ---------------
6660368097802 Full 3/18/2019 8:09:35 PM MSSQLSERVER;model AzureWorkload
Используйте фильтр "RecoveryPointId" или фильтр массива для выборки соответствующей точки восстановления.
$FullRP = Get-AzRecoveryServicesBackupRecoveryPoint -Item $bkpItem -VaultId $testVault.ID -RecoveryPointId "6660368097802"
Получение точки восстановления на момент времени
Если нужно восстановить базу данных на определенный момент времени, используйте командлет PowerShell Get-AzRecoveryServicesBackupRecoveryLogChain. Командлет возвращает список дат, представляющих время начала и окончания непрерывной последовательной цепочки журналов для данного элемента резервной копии SQL. Требуемый момент времени должен находиться в пределах этого диапазона.
Get-AzRecoveryServicesBackupRecoveryLogChain -Item $bkpItem -VaultId $testVault.ID
Результат будет выглядеть примерно так, как показано ниже.
ItemName StartTime EndTime
-------- --------- -------
SQLDataBase;MSSQLSERVER;azu... 3/18/2019 8:09:35 PM 3/19/2019 12:08:32 PM
Приведенные выше выходные данные означают, что можно выполнить восстановление на любой момент времени между отображаемым временем начала и временем окончания. Значения времени указаны в формате UTC. Создайте в PowerShell любую точку во времени, находящуюся в диапазоне, показанном выше.
Примечание.
Если для восстановления выбран момент времени журнала, не обязательно указывать начальную точку, то есть полную резервную копию, из которой восстанавливается база данных. Служба Azure Backup позаботится обо всем плане восстановления, то есть о выборе нужной полной резервной копии, применении резервных копий журналов и т. д.
Определение конфигурации восстановления
Для восстановления базы данных SQL поддерживаются следующие сценарии восстановления.
- Переопределение резервной копии базы данных SQL данными из другой точки восстановления — OriginalWorkloadRestore
- Восстановление базы данных SQL в качестве новой базы данных в том же экземпляре SQL — AlternateWorkloadRestore
- Восстановление базы данных SQL в качестве новой базы данных в другом экземпляре SQL на другой виртуальной машине SQL — AlternateWorkloadRestore
- Восстановление базы данных SQL в виде BAK-файлов — RestoreAsFiles
После получения соответствующей точки восстановления (отдельной или на момент времени журнала) воспользуйтесь командлетом PowerShell Get-AzRecoveryServicesBackupWorkloadRecoveryConfig, чтобы получить объект конфигурации восстановления в соответствии с требуемым планом восстановления.
Восстановление исходной рабочей нагрузки
Чтобы перезаписать базу данных, для которой создана резервная копия, данными из точки восстановления, просто укажите правильный флаг и соответствующую точку восстановления, как показано в следующих примерах.
Исходное восстановление с отдельной точкой восстановления
$OverwriteWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -OriginalWorkloadRestore -VaultId $testVault.ID
Исходное восстановление на момент времени журнала
$OverwriteWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $bkpItem -OriginalWorkloadRestore -VaultId $testVault.ID
Восстановление альтернативной рабочей нагрузки
Важно!
Резервную копию базы данных SQL можно восстановить в виде новой базы данных только на другом экземпляре SQLInstance, на виртуальной машине Azure, зарегистрированной в данном хранилище.
Как изложено выше, если целевой SQLInstance находится на другой виртуальной машине Azure, убедитесь, что он зарегистрирован в данном хранилище, а соответствующий SQLInstance отображается как доступный для защиты элемент. В этом документе мы предположим, что целевое имя SQLInstance — MSSQLSERVER на другой виртуальной машине Contoso2.
$TargetContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -Status Registered -VaultId $testVault.ID -FriendlyName "Contoso2"
$TargetInstance = Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -ItemType SQLInstance -Name "MSSQLSERVER" -ServerName "Contoso2" -VaultId $testVault.ID
Затем просто передайте соответствующую точку восстановления, целевой экземпляр SQL с правильным флагом, как показано ниже, и целевым контейнером, в котором существует целевой экземпляр SQL.
Альтернативное восстановление с отдельной точкой восстановления
$AnotherInstanceWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -TargetItem $TargetInstance -AlternateWorkloadRestore -VaultId $testVault.ID -TargetContainer $TargetContainer
Альтернативное восстановление на момент времени журнала
$AnotherInstanceWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $bkpItem -TargetItem $TargetInstance -AlternateWorkloadRestore -VaultId $testVault.ID -TargetContainer $TargetContainer
Восстановление в виде файлов
Чтобы восстановить данные резервной копии в виде BAK-файлов вместо базы данных, выберите параметр Восстановить как файлы. Резервную копию базы данных SQL можно восстановить на любую целевую виртуальную машину, зарегистрированную в этом хранилище.
$TargetContainer= Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName "VM name" -VaultId $vaultID
Восстановление в виде файлов с отдельной точкой восстановления
$FileRestoreWithFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRP -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Восстановление в виде файлов на момент времени журнала из последней полной резервной копии
$FileRestoreWithLogConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Восстановление в виде файлов на момент времени журнала из указанной полной резервной копии
Если необходимо указать полную резервную копию, которую следует использовать для восстановления, примените следующую команду:
$FileRestoreWithLogAndSpecificFullConfig = Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -FromFull $FullRP -TargetContainer $TargetContainer -RestoreAsFiles -FilePath "<>" -VaultId $testVault.ID
Конечный объект конфигурации точки восстановления, полученный из командлета PowerShell Get-AzRecoveryServicesBackupWorkloadRecoveryConfig, содержит все необходимые сведения для восстановления и выглядит, как показано ниже.
TargetServer : <SQL server name>
TargetInstance : <Target Instance name>
RestoredDBName : <Target Instance name>/azurebackup1_restored_3_19_2019_1850
OverwriteWLIfpresent : No
NoRecoveryMode : Disabled
targetPhysicalPath : {azurebackup1, azurebackup1_log}
ContainerId : /Subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testRG/providers/Microsoft.RecoveryServices/vaults/testVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;computeRG;SQLVMName
SourceResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/computeRG/VMAppContainer/SQLVMName
RestoreRequestType : Alternate WL Restore
RecoveryPoint : Microsoft.Azure.Commands.RecoveryServices.Backup.Cmdlets.Models.AzureWorkloadRecoveryPoint
PointInTime : 1/1/0001 12:00:00 AM
Можно изменить имя восстанавливаемой базы данных, а также поля OverwriteWLIfpresent, NoRecoveryMode и targetPhysicalPath. Получите дополнительные сведения о путях к целевым файлам, как показано ниже.
$AnotherInstanceWithFullConfig.targetPhysicalPath
MappingType SourceLogicalName SourcePath TargetPath
----------- ----------------- ---------- ----------
Data azurebackup1 F:\Data\azurebackup1.mdf F:\Data\azurebackup1_1553001753.mdf
Log azurebackup1_log F:\Log\azurebackup1_log.ldf F:\Log\azurebackup1_log_1553001753.ldf
Задайте соответствующие свойства PowerShell в виде строковых значений, как показано ниже.
$AnotherInstanceWithFullConfig.OverwriteWLIfpresent = "Yes"
$AnotherInstanceWithFullConfig | fl
TargetServer : <SQL server name>
TargetInstance : <Target Instance name>
RestoredDBName : <Target Instance name>/azurebackup1_restored_3_19_2019_1850
OverwriteWLIfpresent : Yes
NoRecoveryMode : Disabled
targetPhysicalPath : {azurebackup1, azurebackup1_log}
ContainerId : /Subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testRG/providers/Microsoft.RecoveryServices/vaults/testVault/backupFabrics/Azure/protectionContainers/vmappcontainer;compute;computeRG;SQLVMName
SourceResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/computeRG/VMAppContainer/SQLVMName
RestoreRequestType : Alternate WL Restore
RecoveryPoint : Microsoft.Azure.Commands.RecoveryServices.Backup.Cmdlets.Models.AzureWorkloadRecoveryPoint
PointInTime : 1/1/0001 12:00:00 AM
Важно!
Убедитесь, что конечный объект конфигурации восстановления имеет все необходимые и правильные значения, так как операция восстановления будет основана на объекте конфигурации.
Примечание.
Если вы хотите восстанавливать не всю цепочку, а только подмножество файлов, выполните действия, описанные здесь.
Восстановление альтернативной рабочей нагрузки в хранилище в дополнительном регионе
Важно!
Поддержка восстановления дополнительного региона для SQL из PowerShell стала доступна с версии Az 6.0.0
Если вы включили восстановление между регионами, точки восстановления будут также реплицированы в дополнительный, парный регион. Затем можно получить эти точки восстановления и запустить восстановление на компьютере, присутствующем в этом парном регионе. Как и в случае с обычным восстановлением, целевой компьютер должен быть зарегистрирован в целевом хранилище в дополнительном регионе. Далее весь процесс представлен более детально.
- Получение элементов резервного копирования, которые реплицируются в дополнительный регион
- Для такого элемента получите точки восстановления (уникальные и (или) журналы), которые реплицируются в дополнительный регион.
- Затем выберите целевой сервер, зарегистрированный в хранилище в дополнительном парном регионе.
- Запустите восстановление на этом сервере и отслеживайте его с помощью JobId.
Получение элементов резервного копирования из дополнительного региона
Получите все элементы резервного копирования SQL из дополнительного региона с помощью обычной команды, но с дополнительным параметром, указывающим, что эти элементы должны быть получены из дополнительного региона.
$secondaryBkpItems = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID -UseSecondaryRegion
Получение уникальных точек восстановления из дополнительного региона
Используйте командлет Get-AzRecoveryServicesBackupRecoveryPoint для получения уникальных (полных или разностных) точек восстановления для резервной копии SQL DB и добавления параметра, указывающего, что эти точки восстановления получены из дополнительного региона.
$startDate = (Get-Date).AddDays(-7).ToUniversalTime()
$endDate = (Get-Date).ToUniversalTime()
Get-AzRecoveryServicesBackupRecoveryPoint -Item $secondaryBkpItems[0] -VaultId $testVault.ID -StartDate $startdate -EndDate $endDate -UseSecondaryRegion
Вы должны увидеть результат, аналогичный приведенному ниже.
RecoveryPointId RecoveryPointType RecoveryPointTime ItemName BackupManagemen
tType
--------------- ----------------- ----------------- -------- ---------------
6660368097802 Full 3/18/2019 8:09:35 PM MSSQLSERVER;model AzureWorkload
Используйте фильтр "RecoveryPointId" или фильтр массива для выборки соответствующей точки восстановления.
$FullRPFromSec = Get-AzRecoveryServicesBackupRecoveryPoint -Item $secondaryBkpItems[0] -VaultId $testVault.ID -RecoveryPointId "6660368097802" -UseSecondaryRegion
Получение точек восстановления журналов из дополнительного региона
Используйте командлет PowerShell Get-AzRecoveryServicesBackupRecoveryLogChain с параметром -UseSecondaryRegion, который возвратит время начала и окончания непрерывной цепочки журналов для этого элемента резервного копирования SQL из дополнительного региона. Требуемый момент времени должен находиться в пределах этого диапазона.
Get-AzRecoveryServicesBackupRecoveryLogChain -Item $secondaryBkpItems[0] -VaultId $testVault.ID -UseSecondaryRegion
Результат будет выглядеть примерно так, как показано ниже.
ItemName StartTime EndTime
-------- --------- -------
SQLDataBase;MSSQLSERVER;azu... 3/18/2019 8:09:35 PM 3/19/2019 12:08:32 PM
Приведенные выше выходные данные означают, что можно выполнить восстановление на любой момент времени между отображаемым временем начала и временем окончания. Значения времени указаны в формате UTC. Создайте в PowerShell любую точку во времени, находящуюся в диапазоне, показанном выше.
Получение целевого сервера из дополнительного региона
В дополнительном регионе требуются хранилище и целевой сервер, зарегистрированные в этом хранилище. Когда имеются целевой контейнер в дополнительном регионе и экземпляр SQL, можно повторно использовать существующие командлеты для создания конфигурации рабочей нагрузки восстановления. В этом документе предполагается, что имя виртуальной машины — secondaryVM, а имя экземпляра на этой виртуальной машине — MSSQLInstance.
Во-первых, мы получаем соответствующее хранилище в дополнительном регионе, а во-вторых — зарегистрированные контейнеры в этом хранилище.
$PairedRegionVault = Get-AzRecoveryServicesVault -ResourceGroupName SecondaryRG -Name PairedVault
$secContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -Status Registered -VaultId $PairedRegionVault.ID -FriendlyName "secondaryVM"
После выбора зарегистрированного контейнера мы извлекаем экземпляры SQL в контейнере, в котором должна быть восстановлена база данных. Здесь предполагается, что в "secondaryVM" есть 1 экземпляр SQL, и мы извлекаем этот экземпляр.
$secSQLInstance = Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -ItemType SQLInstance -VaultId $PairedRegionVault.ID -Container $secContainer
Подготовка конфигурации восстановления
Как описано выше для обычного восстановления SQL, эту же команду можно использовать повторно для создания соответствующей конфигурации восстановления.
Для полного восстановления из дополнительного региона
Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -RecoveryPoint $FullRPFromSec[0] -TargetItem $secSQLInstance -AlternateWorkloadRestore -VaultId $vault.ID -TargetContainer $secContainer
Для восстановления на момент времени из дополнительного региона
Get-AzRecoveryServicesBackupWorkloadRecoveryConfig -PointInTime $PointInTime -Item $secondaryBkpItems[0] -TargetItem $secSQLInstance -AlternateWorkloadRestore -VaultId $vault.ID -TargetContainer $secContainer
После получения соответствующей конфигурации для восстановления из основного региона или восстановления из дополнительного региона можно использовать ту же команду восстановления, чтобы запустить восстановление и последующий мониторинг с помощью идентификаторов jobID.
Восстановление с соответствующей конфигурацией
После получения и проверки соответствующего объекта конфигурации восстановления используйте командлет PowerShell Restore-AzRecoveryServicesBackupItem, чтобы запустить процесс восстановления.
Restore-AzRecoveryServicesBackupItem -WLRecoveryConfig $AnotherInstanceWithLogConfig -VaultId $testVault.ID -RestoreToSecondaryRegion
Операция восстановления возвращает задание, которое предстоит отслеживать.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
MSSQLSERVER/m... Restore InProgress 3/17/2019 10:02:45 AM 3274xg2b-e4fg-5952-89b4-8cb566gc1748
Управление резервными копиями SQL
Резервное копирование по требованию
После включения резервного копирования для базы данных можно также активировать резервное копирование базы данных по запросу с помощью командлета PowerShell Backup-AzRecoveryServicesBackupItem. В следующем примере запускается создание полной резервной копии только для копирования в базе данных SQL с включенным сжатием. Эта копия должна храниться в течение 60 дней.
Примечание.
Полные резервные копии только для копирования идеально подходят для длительного хранения, так как они не зависят от других типов резервных копий, таких как журналы. "Полная" резервная копия считается родительский для последующих резервных копий журнала, поэтому в политике ее хранение связано с хранением журналов. В связи с этим указанный клиентом срок действия будет соблюдаться для полных резервных копий только для копирования, а не для "полных" резервных копий. Срок хранения полных резервных копий устанавливается автоматически равным 45 дням с текущего момента времени. Соответствующая документация приведена здесь.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
$endDate = (Get-Date).AddDays(45).ToUniversalTime()
Backup-AzRecoveryServicesBackupItem -Item $bkpItem -BackupType CopyOnlyFull -EnableCompression -VaultId $testVault.ID -ExpiryDateTimeUTC $endDate
Команда резервного копирования по запросу возвращает задание, которое предстоит отслеживать.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
MSSQLSERVER/m... Backup InProgress 3/18/2019 8:41:27 PM 2516bb1a-d3ef-4841-97a3-9ba455fb0637
Если выходные данные потеряны или нужно получить соответствующий идентификатор задания, получите список заданий от службы Azure Backup, а затем отслеживайте его и сведения о нем.
Изменение политики для элементов резервных копий
Политику резервного копирования элемента можно изменить на Policy1Policy2. Чтобы переключить политики для архивированного элемента, извлеките соответствующую политику и элемент резервной копии и примените команду Enable-AzRecoveryServices с этим элементом в качестве параметра.
$TargetPol1 = Get-AzRecoveryServicesBackupProtectionPolicy -Name <PolicyName>
$anotherBkpItem = Get-AzRecoveryServicesBackupItem -WorkloadType MSSQL -BackupManagementType AzureWorkload -Name "<BackupItemName>"
Enable-AzRecoveryServicesBackupProtection -Item $anotherBkpItem -Policy $TargetPol1
Команда ожидает завершения конфигурации резервного копирования и возвращает следующие выходные данные.
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
master ConfigureBackup Completed 3/18/2019 8:00:21 PM 3/18/2019 8:02:16 PM 654e8aa2-4096-402b-b5a9-e5e71a496c4e
Изменение существующей политики резервного копирования
Чтобы изменить существующую политику, используйте команду Set-AzRecoveryServicesBackupProtectionPolicy.
Set-AzRecoveryServicesBackupProtectionPolicy -Policy $Pol -SchedulePolicy $SchPol -RetentionPolicy $RetPol
Проверьте задания резервного копирования через некоторое время для отслеживания возможных сбоев. При наличии проблем необходимо их устранить. Затем повторно выполните команду изменения политики с параметром FixForInconsistentItems, чтобы повторить попытку изменения политики для всех элементов резервных копий, для которых операцию не удалось выполнить ранее.
Set-AzRecoveryServicesBackupProtectionPolicy -Policy $Pol -FixForInconsistentItems
Повторная регистрация виртуальных машин SQL
Предупреждение
Не забудьте прочитать этот документ, чтобы понять признаки и причины сбоя, прежде чем пытаться повторно выполнить регистрацию
Чтобы запустить повторную регистрацию виртуальной машины SQL, извлеките соответствующий контейнер резервных копий и передайте его в командлет регистрации.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Register-AzRecoveryServicesBackupContainer -Container $SQLContainer -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID
Отключение защиты
Сохранение данных
Если нужно отключить защиту, можно использовать командлет PowerShell Disable-AzRecoveryServicesBackupProtection. Это остановит создание запланированных резервных копий, но данные, сохраненные до текущего момента, будут храниться неограниченное время.
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType AzureWorkload -WorkloadType MSSQL -Name "<backup item name>" -VaultId $testVault.ID
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $testVault.ID
удаление резервных копий;
Чтобы полностью удалить сохраненные резервные копии данных из хранилища, просто добавьте флаг "-RemoveRecoveryPoints" или переключитесь на команду "disable" для отключения защиты.
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $testVault.ID -RemoveRecoveryPoints
Отключение автоматической защиты
Если для SQLInstance была настроена автоматическая защита, ее можно отключить с помощью командлета PowerShell Disable-AzRecoveryServicesBackupAutoProtection.
Найдите экземпляры, для которых включена автоматическая защита, с помощью следующей команды PowerShell.
Get-AzRecoveryServicesBackupProtectableItem -WorkloadType MSSQL -VaultId $testVault.ID | Where-Object {$_.IsAutoProtected -eq $true}
Затем выберите соответствующее защищаемое имя элемента и имя сервера из выходных данных и отключите автоматическую защиту для этих экземпляров.
$SQLInstance = Get-AzRecoveryServicesBackupProtectableItem -workloadType MSSQL -ItemType SQLInstance -VaultId $testVault.ID -Name "<Protectable Item name>" -ServerName "<Server Name>"
Disable-AzRecoveryServicesBackupAutoProtection -InputItem $SQLInstance -BackupManagementType AzureWorkload -WorkloadType MSSQL -VaultId $testVault.ID
Отмена регистрации виртуальной машины SQL
Если все базы данных сервера SQL больше не защищены и резервных копий данных не существует, можно отменить регистрацию виртуальной машины SQL из этого хранилища. Только после этого можно защитить базы данных в другом хранилище. Для отмены регистрации виртуальной машины SQL используйте командлет PowerShell Unregister-AzRecoveryServicesBackupContainer.
$SQLContainer = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVMAppContainer -FriendlyName <VM name> -VaultId $testVault.ID
Unregister-AzRecoveryServicesBackupContainer -Container $SQLContainer -VaultId $testVault.ID
Отслеживание заданий Azure Backup
Важно отметить, что Azure Backup отслеживает только активированные пользователем задания в резервной копии SQL. Запланированные резервные копии (включая резервные копии журналов) не отображаются на портале или в PowerShell. Однако при сбое запланированных заданий создается оповещение о резервном копировании, которое отображается на портале. Используйте Azure Monitor для отслеживания всех запланированных заданий и других важных сведений.
Пользователи могут контролировать операции, активируемые по запросу или пользователем, с помощью JobID, возвращаемого в выходных данных асинхронных заданий, таких как резервное копирование. Используйте командлет PowerShell Get-AzRecoveryServicesBackupJobDetail для отслеживания задания и сведений о нем.
Get-AzRecoveryServicesBackupJobDetails -JobId 2516bb1a-d3ef-4841-97a3-9ba455fb0637 -VaultId $testVault.ID
Чтобы получить список заданий по запросу и их состояний от службы Azure Backup, используйте командлет PowerShell Get-AzRecoveryServicesBackupJob. В следующем примере возвращаются все выполняющиеся задания SQL.
Get-AzRecoveryServicesBackupJob -Status InProgress -BackupManagementType AzureWorkload
Чтобы отменить выполняющееся задание, используйте командлет PowerShell Stop-AzRecoveryServicesBackupJob.
Управление группами доступности AlwaysOn SQL
Для групп доступности AlwaysOn SQL не забудьте зарегистрировать все узлы группы доступности. После завершения регистрации для всех узлов объект группы доступности SQL логически создается в разделе защищаемых элементов. Базы данных в группе доступности SQL будут перечислены как "SQLDatabase". Узлы будут представлены как автономные экземпляры, а базы данных SQL по умолчанию в них — также как базы данных SQL.
Например, предположим, что в группе доступности SQL есть два узла sql-server-0 и sql-server-1, а также одна база данных группы доступности SQL. После регистрации обоих узлов, если вывести список защищаемых элементов, в нем будут перечислены следующие компоненты.
- Объект группы доступности SQL — тип защищаемого элемента SQLAvailabilityGroup
- База данных группы доступности SQL — тип защищаемого элемента SQLDatabase
- sql-server-0 — тип защищаемого элемента SQLInstance
- sql-server-1 — тип защищаемого элемента SQLInstance
- Любые базы данных SQL по умолчанию (master, model, msdb) в sql-server-0 — тип защищаемого элемента SQLDatabase
- Любые базы данных SQL по умолчанию (master, model, msdb) в sql-server-1 — тип защищаемого элемента SQLDatabase
sql-server-0, sql-server-1 также будут отображены как "AzureVMAppContainer" при перечислении контейнеров резервных копий.
Просто выберите соответствующую базу данных, чтобы включить резервное копирование, а командлеты PowerShell для резервного копирования и восстановления по запросу идентичны.