Устранение неполадок резервного копирования базы данных SQL Server с помощью Azure Backup

В этой статье содержатся сведения об устранении неполадок в работе SQL Server на виртуальных машинах Azure.

Дополнительные сведения о процессе и ограничениях резервного копирования см. в разделе о резервном копировании SQL Server на виртуальных машинах Azure.

Разрешения SQL Server

Чтобы настроить защиту базы данных SQL Server на виртуальной машине, на этой виртуальной машине должно быть установлено расширение AzureBackupWindowsWorkload. Если вы получили сообщение об ошибке UserErrorSQLNoSysadminMembership, это означает, что ваш экземпляр SQL Server не имеет необходимых разрешений на резервное копирование. Чтобы устранить ошибку, выполните действия, описанные в разделе Настройка разрешений виртуальной машины.

Устранение неполадок обнаружения и настройки

После завершения создания и настройки хранилища служб восстановления обнаружение баз данных и настройка резервного копирования — это двухэтапный процесс.

Если при настройке резервного копирования виртуальная машина SQL и ее экземпляры не отображаются в разделах Обнаружить базы данных в виртуальных машинах и Настройка резервного копирования (см. выше), убедитесь в следующем.

Шаг 1. Обнаружение баз данных в виртуальных машинах

• Если виртуальная машина не указана в списке обнаруженных виртуальных машин и не зарегистрирована для резервного копирования SQL в другом хранилище, выполните действия из раздела Обнаружение резервной копии SQL Server.

Шаг 2. Настройка резервного копирования

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

Если виртуальная машина SQL должна быть зарегистрирована в новом хранилище, ее регистрацию в старом хранилище следует отменить. Для отмены регистрации виртуальной машины SQL в хранилище необходимо остановить защиту для всех защищенных источников данных, после чего можно будет удалить резервные копии данных. Удаление данных резервных копий — это необратимая операция. После того как вы проверите отмену регистрации виртуальной машины SQL и предпримете все меры предосторожности, зарегистрируйте эту же виртуальную машину в новом хранилище и повторите операцию резервного копирования.

Устранение проблем с резервным копированием и восстановлением

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

1. Исключите из проверки в антивирусном программном обеспечении следующие папки:

   C:\Program Files\Azure Workload Backup C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup.AzureBackupWindowsWorkload

   Замените C:\ на букву для SystemDrive.

2. Исключите следующие три процесса, выполняемые на виртуальной машине, из проверки антивирусом:

   • IaasWLPluginSvc.exe
   • IaaSWorkloadCoordinatorService.exe
   • TriggerExtensionJob.exe

3. Для SQL существует также ряд рекомендаций по работе с антивирусными программами. Подробные сведения см. в этой статье.

Неисправный экземпляр в виртуальной машине с несколькими экземплярами SQL Server

Восстановление в виртуальной машине SQL можно выполнить, только если все экземпляры SQL, работающие на виртуальной машине, сообщают о работоспособном состоянии. Если один или несколько экземпляров неисправны, виртуальная машина не будет отображаться как целевой объект восстановления. Это может быть причиной, по которой виртуальная машина с несколькими экземплярами может не отображаться в раскрывающемся списке "сервер" во время операции восстановления.

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

Если вы хотите активировать восстановление в работоспособных экземплярах SQL, выполните следующие действия.

1. Войдите на виртуальную машину SQL и перейдите по адресу C:\Program Files\Azure Workload Backup\bin.

2. Создайте JSON-файл с именем ExtensionSettingsOverrides.json (если его еще не существует). Если этот файл уже существует на виртуальной машине, продолжайте использовать его.

3. Добавьте следующее содержимое в JSON-файл и сохраните файл:

   {
                 "<ExistingKey1>":"<ExistingValue1>",
                   …………………………………………………… ,
             "whitelistedInstancesForInquiry": "FaultyInstance_1,FaultyInstance_2"
           }
   
           Sample content:        
           { 
             "whitelistedInstancesForInquiry": "CRPPA,CRPPB "
           }
   
   

4. Активируйте операцию повторного обнаружения баз данных на соответствующем сервере с портала Azure (с того же места, в котором можно просмотреть готовность к резервному копированию). Виртуальная машина начнет отображаться как целевой объект для операций восстановления.

   

5. Удалите запись whitelistedInstancesForInquiry из файла ExtensionSettingsOverrides.json после завершения операции восстановления.

Сообщения об ошибках

Неподдерживаемый тип резервного копирования

UserErrorSQLPODoesNotSupportBackupType

OperationCancelledBecauseConflictingOperationRunningUserError

UserErrorFileManipulationIsNotAllowedDuringBackup

UserErrorSQLPODoesNotExist

UserErrorSQLLSNValidationFailure

UserErrorOpeningSQLConnection

UserErrorParentFullBackupMissing

UserErrorBackupFailedAsTransactionLogIsFull

UserErrorCannotRestoreExistingDBWithoutForceOverwrite

UserErrorRestoreFailedDatabaseCannotBeOfflined

WlExtGenericIOFaultUserError

UserErrorCannotFindServerCertificateWithThumbprint

UserErrorRestoreNotPossibleBecauseLogBackupContainsBulkLoggedChanges

FabricSvcBackupPreferenceCheckFailedUserError

VMNotInRunningStateUserError

GuestAgentStatusUnavailableUserError

AutoProtectionCancelledOrNotValid

CloudDosAbsoluteLimitReached

CloudDosAbsoluteLimitReachedWithRetry

WorkloadExtensionNotReachable

UserErrorVMInternetConnectivityIssue

UserErrorOperationNotAllowedDatabaseMirroringEnabled

UserErrorWindowsWLExtFailedToStartPluginService

Сбои повторной регистрации

Перед запуском операции повторной регистрации проверьте наличие одного или нескольких следующих признаков.

• Все операции (такие как резервное копирование, восстановление и настройка резервного копирования) на виртуальной машине завершаются ошибкой с одним из следующих кодов: WorkloadExtensionNotReachable, UserErrorWorkloadExtensionNotInstalled, WorkloadExtensionNotPresent, WorkloadExtensionDidntDequeueMsg.

• Если в области Backup Status (Состояние резервного копирования) для элемента резервного копирования отображается Недоступно, исключите все остальные причины, которые могут привести к тому же состоянию:

  • отсутствие разрешения на выполнение операций, связанных с резервным копированием на виртуальной машине;
  • завершение работы виртуальной машины, препятствующее выполнению операций резервного копирования;
  • Проблемы с сетью.

  

• В случае с группой доступности Always On запущенные операции резервного копирования завершаются сбоем после изменения настроек резервного копирования или отработки отказа.

Эти признаки могут возникнуть по одной или нескольким из следующих причин:

• Расширение удалено из портала.
• Расширение удалено с помощью панели управления на виртуальной машине из раздела Удаление или изменение программы.
• Восстановлено предыдущее состояние виртуальной машины с помощью восстановления с диска на месте.
• Виртуальная машина была выключена в течение длительного периода, поэтому срок действия конфигурации расширения на ней истек.
• Виртуальная машина была удалена, а затем была создана другая виртуальная машина с тем же именем и в той же группе ресурсов, что и удаленная виртуальная машина.
• Один из узлов группы доступности не получил полную конфигурацию резервного копирования. Это могло произойти при регистрации группы доступности в хранилище или при добавлении нового узла.

В предыдущих сценариях рекомендуется активировать повторную регистрацию на виртуальной машине. Инструкции по выполнению этой задачи в PowerShell см. здесь.

Ограничение размера для файлов

Общий размер строк файлов зависит не только от количества файлов, но и от их имен и путей. Получите логическое имя файла и физический путь для каждого файла базы данных. Для этого вы можете использовать этот SQL-запрос:

SELECT mf.name AS LogicalName, Physical_Name AS Location FROM sys.master_files mf
               INNER JOIN sys.databases db ON db.database_id = mf.database_id
               WHERE db.name = N'<Database Name>'"

Теперь расположите их в следующем формате:

[{"path":"<Location>","logicalName":"<LogicalName>","isDir":false},{"path":"<Location>","logicalName":"<LogicalName>","isDir":false}]}

Приведем пример:

[{"path":"F:\\Data\\TestDB12.mdf","logicalName":"TestDB12","isDir":false},{"path":"F:\\Log\\TestDB12_log.ldf","logicalName":"TestDB12_log","isDir":false}]}

Если размер строки содержимого превышает 20 000 байт, файлы базы данных хранятся иначе. Во время восстановления вы не сможете задать путь к целевому файлу для восстановления. Файлы будут восстановлены по умолчанию по пути SQL, заданном SQL Server.

Переопределение стандартного целевого пути к файлу восстановления

Целевой путь к файлу восстановления можно переопределить во время операции восстановления, поместив JSON-файл, содержащий сопоставление файла базы данных, по целевому пути восстановления. Создайте файл database_name.json и поместите его в расположение C:\Program Files\Azure Workload Backup\bin\plugins\SQL*.

Содержимое файла должно иметь такой формат:

[
  {
    "Path": "<Restore_Path>",
    "LogicalName": "<LogicalName>",
    "IsDir": "false"
  },
  {
    "Path": "<Restore_Path>",
    "LogicalName": "LogicalName",
    "IsDir": "false"
  },  
]

Приведем пример:

[
  {
   "Path": "F:\\Data\\testdb2_1546408741449456.mdf",
   "LogicalName": "testdb7",
   "IsDir": "false"
  },
  {
    "Path": "F:\\Log\\testdb2_log_1546408741449456.ldf",
    "LogicalName": "testdb7_log",
    "IsDir": "false"
  },  
]

Приведенное выше содержимое позволяет получить логическое имя файла базы данных с помощью следующего запроса SQL:

SELECT mf.name AS LogicalName FROM sys.master_files mf
                INNER JOIN sys.databases db ON db.database_id = mf.database_id
                WHERE db.name = N'<Database Name>'"

Этот файл должен быть добавлен перед запуском операции восстановления.

Следующие шаги

Дополнительные сведения о Azure Backup для виртуальных машин SQL.