Problembehandlung für die SQL Server-Datenbanksicherung mit Azure Backup

Dieser Artikel enthält Informationen zur Problembehandlung bei SQL Server-Datenbank-Instanzen, die auf Azure-VMs ausgeführt werden.

Weitere Informationen zu Sicherungsprozess und Einschränkungen finden Sie unter Funktionsaspekte und Einschränkungen.

SQL Server-Berechtigungen

Zum Konfigurieren des Schutzes für eine SQL Server-Datenbank auf einem virtuellen Computer, müssen Sie auf diesem virtuellen Computer die Erweiterung AzureBackupWindowsWorkload installieren. Wenn Sie die Fehlermeldung UserErrorSQLNoSysadminMembership erhalten, bedeutet das, dass Ihre SQL Server-Instanz nicht über die erforderlichen Berechtigungen für die Sicherung verfügt. Um diesen Fehler zu beheben, führen Sie die Schritte in Einrichten von Berechtigungen für virtuelle Computer aus.

Behandlung von Problemen beim Ermitteln und Konfigurieren

Nach Abschluss der Erstellung und Konfiguration eines Recovery Services-Tresors erfolgt das Ermitteln von Datenbanken und das Konfigurieren der Sicherung in einem zweistufigen Prozess.

Wenn die SQL-VM und ihre Instanzen während der Sicherungskonfiguration unter Ermitteln der DBs in VMs und Konfiguration der Sicherung (siehe das Bild oben) nicht angezeigt werden, stellen Sie Folgendes sicher:

Schritt 1: Ermitteln der DBs in VMs

• Wenn die VM in der Liste der ermittelten VMs nicht aufgeführt wird und auch für die SQL-Sicherung in einem anderen Tresor nicht registriert wurde, führen Sie die Schritte unter Ermitteln der Sicherung des SQL-Servers aus.

Schritt 2: Konfiguration der Sicherung

• Folgen Sie den Schritten unter Konfiguration der Sicherung, wenn der Tresor, in dem die SQL-VM registriert ist, dem Tresor entspricht, in dem Datenbanken geschützt werden.

Die SQL-VM muss zunächst aus dem alten Tresor abgemeldet werden, bevor sie im neuen Tresor registriert werden kann. Für die Abmeldung der SQL-VM aus dem Tresor müssen Sie den Schutz aller Datenquellen beenden. Erst danach können Sie die gesicherten Daten löschen. Das Löschen der gesicherten Daten kann nicht rückgängig gemacht werden. Nachdem Sie alles überprüft und alle Vorsichtsmaßnahmen zum Abmelden der SQL-VM getroffen haben, registrieren Sie diese VM in einem neuen Tresor, und wiederholen Sie den Sicherungsvorgang.

Beheben von Problemen bei der Sicherung und Wiederherstellung

Gelegentlich können bei Sicherungs- und Wiederherstellungsvorgängen zufällige Ausfälle auftreten, da diese Vorgänge möglicherweise hängen bleiben. Der Grund hierfür kann ein Antivirenprogramm auf Ihrer VM sein. Als bewährte Vorgehensweise werden die folgenden Schritte empfohlen:

1. Schließen Sie die folgenden Ordner von der Antivirenüberprüfung aus:

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

   Ersetzen Sie C:\ durch den Buchstaben Ihres Systemlaufwerks.

2. Schließen Sie die folgenden drei Prozesse, die innerhalb einer VM ausgeführt werden, von der Antivirenüberprüfung aus:

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

3. SQL bietet ebenfalls einige Richtlinien für die Arbeit mit Antivirussoftware. Nähere Einzelheiten finden Sie in diesem Artikel.

Fehlerhafte Instanz in einer VM mit mehreren SQL Server-Instanzen

Sie können die Wiederherstellung auf einer SQL-VM nur durchführen, wenn für alle SQL-Instanzen, die auf der VM ausgeführt werden, ein fehlerfreier Zustand gemeldet wird. Wenn auch nur eine Instanz fehlerhaft ist, wird die VM nicht als Wiederherstellungsziel angezeigt. Dies kann also ein möglicher Grund sein, warum eine VM mit mehreren Instanzen während des Wiederherstellungsvorgangs nicht in der Dropdownliste „Server“ angezeigt wird.

Sie können die „Sicherungsbereitschaft“ aller SQL-Instanzen auf der VM unter Sicherung konfigurieren überprüfen:

Führen Sie die folgenden Schritte aus, wenn Sie eine Wiederherstellung der fehlerfreien SQL-Instanzen starten möchten:

1. Melden Sie sich bei der SQL-VM an, und wechseln Sie zu C:\Program Files\Azure Workload Backup\bin.

2. Erstellen Sie eine JSON-Datei mit dem Namen ExtensionSettingsOverrides.json (sofern sie noch nicht vorhanden ist). Wenn diese Datei bereits auf der VM vorhanden ist, können Sie sie weiter verwenden.

3. Fügen Sie den folgenden Inhalt hinzu, und speichern Sie die JSON-Datei:

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

4. Starten Sie den Vorgang Datenbanken neu ermitteln auf dem betroffenen Server über das Azure-Portal (an der Stelle, an der die Sicherungsbereitschaft angezeigt wird). Die VM wird als Ziel für Wiederherstellungsvorgänge angezeigt.

   

5. Entfernen Sie nach Abschluss des Wiederherstellungsvorgangs den Eintrag whitelistedInstancesForInquiry aus der Datei „ExtensionSettingsOverrides.json“.

Fehlermeldungen

Nicht unterstützter Sicherungstyp

UserErrorSQLPODoesNotSupportBackupType

OperationCancelledBecauseConflictingOperationRunningUserError

UserErrorFileManipulationIsNotAllowedDuringBackup

UserErrorSQLPODoesNotExist

UserErrorSQLLSNValidationFailure

UserErrorOpeningSQLConnection

UserErrorParentFullBackupMissing

UserErrorBackupFailedAsTransactionLogIsFull

UserErrorCannotRestoreExistingDBWithoutForceOverwrite

UserErrorRestoreFailedDatabaseCannotBeOfflined

WlExtGenericIOFaultUserError

UserErrorCannotFindServerCertificateWithThumbprint

UserErrorRestoreNotPossibleBecauseLogBackupContainsBulkLoggedChanges

FabricSvcBackupPreferenceCheckFailedUserError

VMNotInRunningStateUserError

GuestAgentStatusUnavailableUserError

AutoProtectionCancelledOrNotValid

CloudDosAbsoluteLimitReached

CloudDosAbsoluteLimitReachedWithRetry

WorkloadExtensionNotReachable

UserErrorVMInternetConnectivityIssue

UserErrorOperationNotAllowedDatabaseMirroringEnabled

UserErrorWindowsWLExtFailedToStartPluginService

Fehler bei der erneuten Registrierung

Überprüfen Sie vor dem Auslösen der erneuten Registrierung, ob ein oder mehrere der folgenden Symptome vorhanden sind:

• Für alle Vorgänge (z.B. Sicherung, Wiederherstellung und Sicherungskonfiguration) tritt auf der VM ein Fehler mit einem der folgenden Fehlercodes auf: WorkloadExtensionNotReachable , UserErrorWorkloadExtensionNotInstalled, WorkloadExtensionNotPresent, WorkloadExtensionDidntDequeueMsg.

• Wenn im Bereich Sicherungsstatus für das Sicherungselement der Status Nicht erreichbar angezeigt wird, schließen Sie alle anderen Gründe aus, die zum gleichen Status führen könnten:

  • Fehlende Berechtigung zur Durchführung von sicherungsbezogenen Vorgängen auf der VM
  • Herunterfahren des virtuellen Computers, sodass keine Sicherungen durchgeführt werden können
  • Netzwerkprobleme

  

• Bei einer Always On-Verfügbarkeitsgruppe: Für die Sicherungen ist ein Fehler aufgetreten, nachdem Sie die Sicherungseinstellung geändert haben, oder nach einem Failover.

Zu diesen Symptomen kann es aufgrund von einer oder mehreren der folgenden Ursachen kommen:

• Eine Erweiterung wurde gelöscht oder im Portal deinstalliert.
• Eine Erweiterung wurde in der Systemsteuerung der VM unter Programm deinstallieren oder ändern deinstalliert.
• Die VM wurde über eine direkte Datenträgerwiederherstellung rechtzeitig wiederhergestellt.
• Die VM wurde für längere Zeit heruntergefahren, sodass die Erweiterungskonfiguration dafür abgelaufen ist.
• Die VM wurde gelöscht, und eine andere VM wurde mit dem gleichen Namen und in derselben Ressourcengruppe wie die gelöschte VM erstellt.
• Einer der Verfügbarkeitsgruppenknoten hat nicht die vollständige Sicherungskonfiguration erhalten. Dies kann passieren, wenn die Verfügbarkeitsgruppe im Tresor registriert ist, oder wenn ein neuer Knoten hinzugefügt wird.

In den vorhergehenden Szenarien sollten Sie einen Neuregistrierungsvorgang auf der VM auszulösen. Anweisungen zum Durchführen dieser Aufgabe in PowerShell finden Sie hier.

Maximale Größe für Dateien

Die gesamte Zeichenfolgengröße von Dateien hängt nicht nur von der Anzahl der Dateien, sondern auch von deren Namen und Pfaden ab. Rufen Sie für jede der Datenbankdateien den logischen Dateinamen und den physischen Pfad ab. Sie können diese SQL-Abfrage verwenden:

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>'"

Ordnen Sie sie jetzt im folgenden Format an:

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

Hier sehen Sie ein Beispiel:

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

Wenn die Zeichenfolgegröße des Inhalts 20.000 Bytes überschreitet, werden die Datenbankdateien anders gespeichert. Während der Wiederherstellung können Sie den Pfad der Zieldatei für die Wiederherstellung nicht festlegen. Die Dateien werden in dem von SQL Server bereitgestellten Standard-SQL-Pfad wiederhergestellt.

Außerkraftsetzen des Standard-Zieldateipfads für die Wiederherstellung

Sie können den Zieldateipfad für die Wiederherstellung während des Wiederherstellungsvorgangs außer Kraft setzen, indem Sie eine JSON-Datei mit der Zuordnung der Datenbankdatei zum Wiederherstellungszielpfad platzieren. Erstellen Sie eine database_name.json-Datei, und platzieren Sie sie am Speicherort C:\Program Files\Azure Workload Backup\bin\plugins\SQL*.

Der Inhalt der Datei sollte dieses Format haben:

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

Hier sehen Sie ein Beispiel:

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

Im oben stehenden Inhalt können Sie den logischen Namen der Datenbankdatei mit der folgenden SQL-Abfrage abrufen:

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>'"

Diese Datei muss abgelegt werden, bevor Sie den Wiederherstellungsvorgang auslösen.

Nächste Schritte

Weitere Informationen zu Azure Backup für SQL VMs.