Behandeln von Problemen mit geplanten Sicherungsaufträgen im Data Protection Manager

In diesem Artikel wird erläutert, wie Sie geplante Sicherungsauftragsfehler in Microsoft System Center Data Protection Manager (DPM) beheben.

Ursprüngliche Produktversion: System Center Data Protection Manager
Ursprüngliche KB-Nummer: 4456295

Manchmal werden Wiederherstellungspunktaufträge nicht wie geplant ausgeführt, obwohl der Schutzstatus der jeweiligen Datenquellen in der DPM-Konsole weiterhin grün (OK) angezeigt wird. Dieses Problem tritt in der Regel auf, wenn SQL Server-Agent das DPM-Modul nicht aufrufen kann, um den geplanten Auftrag auszuführen.

Notiz

Dieses Problem wirkt sich nicht auf ad-hoc manuelle Aufträge aus, da SQL Server-Agent nicht verwendet wird, wenn Sie manuelle Aufträge über die DPM-Konsole ausführen.

Funktionsweise der geplanten Auftragsausführung

Wenn Schutzgruppen eingerichtet sind, erstellt DPM Sicherungsaufträge (inkrementelle Synchronisierungen, express full usw.) in SQL Server für jede Datenquelle zusammen mit anderen Wartungsaufträgen. Eine Komponente, die als TriggerJob.exe "DPM"-Modul bezeichnet wird, wird verwendet, indem die Auftragsdefinitions-ID für die Datenquelle übergeben wird, um mit der Ausführung des Sicherungsauftrags zu beginnen. TriggerJob.exewird vom SQL Server-Agent Scheduler zur geplanten Zeit über die folgende Befehlssyntax ausgeführt:

triggerjob.exe <JobDefinitionID> <ScheduleID> <FQDN-DPMServer>

Die folgende ist ein Beispiel für einen typischen Befehl, der von Schedule Agent Scheduler ausgeführt wird, um mit der Ausführung des Auftrags zur geplanten Zeit zu beginnen:

C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\bin\TriggerJob.exe 1bd305ae-f158-4948-93f8-e935103b168f 1e53fd39-0339-4d41-96ec-89fdf587f1e5 <FQDN-DPMServer>

Notiz

Dieser Pfad kann je nach DPM-Version unterschiedlich sein und ob es sich um ein Upgrade (denselben Pfad) oder eine Neuinstallation (unterschiedlicher Pfad) handelt.

Aus irgendeinem Grund wird der Befehl nicht ausgeführt und aufgerufen Triggerjob.exe, das DPM-Modul wird nicht aufgerufen. Der Sicherungsauftrag wird also nicht ausgeführt. Da SQL Server den Befehl nicht ausgeführt hat, weiß DPM nicht über diesen Fehler und zeigt weiterhin den Schutzstatus der Datenquellen als grün an.

In den folgenden Abschnitten finden Sie einige Techniken zur Problembehandlung geplanter Sicherungsauftragsfehler.

Überprüfen des Anwendungsprotokolls

Wenn ein geplanter Sicherungsauftrag nicht von SQL Server aufgerufen werden kann, löst DPM keine Warnungen für diese Auftragsfehler aus, da es sich um einen Fehler auf der SQL Server-Seite handelte. Diese Ereignisse werden jedoch je nach Ursache des Problems im Anwendungsprotokoll als SQL Server-, Windows-Fehlerberichterstattung- oder MSDPM-Ereignisse erfasst. Stellen Sie sicher, dass Sie das Anwendungsprotokoll Ereignisanzeige auf Ereignisse von SQL Server überprüfen, die mit dem geplanten Auftragsfehler zusammenhängen. Wenn Ihr DPM-Computer remote SQL Server für DPMDB verwendet, überprüfen Sie das Anwendungsprotokoll auf dem Remoteserver.

Das folgende Ereignis kann z. B. im Anwendungsprotokoll gefunden werden, um anzugeben, dass das SQL Server-Agent ein Problem auftritt, wenn versucht wurde, die Befehlszeile auszuführen.

Protokollname: Application
Quelle: SQLAgent$MSDPM2012
Datum: <Datum und Uhrzeit>
Ereignis-ID: 208
Aufgabenkategorie: Auftragsmodul
Ebene: Warnung
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <DPMServerName>
Beschreibung:
Sql Server Scheduled Job '00890b12-9058-4f42-8143-291dc3de4d78' (0xC52C50485ED1754EB12D16117B258DD7) - Status: Fehlgeschlagen - Aufgerufen am: Datum & Uhrzeit>- Nachricht: <Der Auftrag fehlgeschlagen. Der Auftrag wurde von Benutzerbenutzername <>aufgerufen. Der letzte auszuführende Schritt war Schritt 1 (Standardauftragsschritt).

Hier ist ein Beispielereignis aus Windows-Fehlerberichterstattung:

Fehler-Bucket , Typ 0
Ereignisname: DPMException
Antwort: Nicht verfügbar
CAB-ID: 0

Problemsignatur:
P1: TriggerJob
P2: 3.0.7696.0
P3: TriggerJob.exe
P4: 3.0.7696.0
P5: System.UnauthorizedAccessException
P6: System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal
P7: 20B9A72D
P8:
P9:
P10:

Ein weiteres Beispielereignis des DPM-Moduls:

Protokollname: Application
Quelle: MSDPM
Datum: <Datum und Uhrzeit>
Ereignis-ID: 976
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: N/V
Computer: <FQDN von DPMServerName>
Beschreibung:
Die Beschreibung für die Ereignis-ID 976 aus der MsDPM-Quelle wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, auf Ihrem lokalen Computer nicht installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.
Fehler des DPM-Auftrags, da er nicht mit dem DPM-Modul in Kontakt treten konnte.

Problemdetails:
<JobTriggerFailed__System ID 9/ID><Seq>0</Seq><TimeCreated Date & TimeCreated><><>< Source>TriggerJob.cs</Source><Line>76</Line><HasError>True</HasError></__System><Tags><JobSchedule /></Tags></JobTriggerFailed<>><><>

Manuelles Ausführen des Auftrags aus SQL Server Management Studio

Sie können versuchen, den Auftrag manuell aus SQL Management Studio auszuführen. Gehen Sie dazu wie folgt vor:

1. Starten Sie SQL Server Management Studio, und stellen Sie eine Verbindung mit der SQL Server-Instanz her, die für die DPMDB-Datenbank verwendet wird. Erweitern Sie SQL Server-Agent> Jobs. Die GUIDs-Werte in der Liste unter "Aufträge " geben die Zeitplan-ID für jeden Auftrag an. Klicken Sie mit der rechten Maustaste auf einen Auftrag, und wählen Sie dann im Kontextmenü "Auftrag starten" aus .

   

2. Wenn der Auftrag nicht ausgeführt wird, sollten Sie eine Fehlermeldung erhalten, die etwa wie folgt aussieht.

   Fehler bei der Ausführung des Auftrags '00890b12-9058-4f42-8143-291dc3de4d78'.

   

3. Diese Meldung bestätigt, dass der SQL Server-Agent aufgrund falscher Berechtigungen oder eines anderen Grunds den Auftrag nicht ausführen konnte. Weitere Informationen finden Sie im Abschnitt "Anmeldekontoanmeldeinformationen überprüfen", um dieses Problem zu beheben.

Manuelles Ausführen des Auftrags an einer Eingabeaufforderung

Sie können an einer Befehlszeile ausführen Triggerjob.exe , um manuell zu überprüfen, ob der Befehl ausgeführt wird und der Sicherungsauftrag ordnungsgemäß in DPM gestartet wird. Gehen Sie dazu wie folgt vor:

1. Starten Sie SQL Server Management Studio, und stellen Sie dann eine Verbindung mit der SQL Server-Instanz her, die für die DPMDB-Datenbank verwendet wird. Erweitern Sie SQL Server-Agent> Jobs. Klicken Sie mit der rechten Maustaste auf einen der Aufträge, und wählen Sie dann "Eigenschaften" aus.

   

2. Wählen Sie im Dialogfeld "Eigenschaften" die Option "Schritte auf der linken Seite" und dann unten die Schaltfläche "Bearbeiten" aus.

   

3. Kopieren Sie im Dialogfeld "Auftragsschritteigenschaften " den Befehl aus dem Eingabeaufforderungsfenster, wie im folgenden Screenshot gezeigt.

   

4. Führen Sie den kopierten Befehl entsprechend aus:

   • Führen Sie an einer Eingabeaufforderung mit erhöhten Rechten auf dem DPM-Server (die eine lokale Instanz von SQL Server ausführt) den folgenden Beispielbefehl aus:

     C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\bin\TriggerJob.exe F60C8734-2DF5-4E86-8C7D-43558BD5A071 2F481ACB-2C3D-4F48-8C70-CA989C3E8FF2 <FQDN of DPMServer>
     

     Wenn der Befehl erfolgreich ausgeführt wird, hängt das Problem wahrscheinlich mit falschen Berechtigungen oder Anmeldeinformationen zusammen. Lesen Sie den Abschnitt "Anmeldekontoanmeldeinformationen überprüfen", um dieses Problem zu beheben.

   • Führen Sie an einer Eingabeaufforderung mit erhöhten Rechten auf dem Remote-SQL-Server den folgenden Beispielbefehl aus (falls zutreffend):

     C:\Program Files\Microsoft Data Protection Manager\DPM2012R2\SQLPrep\TriggerJob.exe F60C8734-2DF5-4E86-8C7D-43558BD5A071 2F481ACB-2C3D-4F48-8C70-CA989C3E8FF2 <FQDN of DPMServer>
     

     Wenn der Befehl im Remote-SQL Server-Szenario erfolgreich auf dem DPM-Server abgeschlossen wurde, aber auf dem Remote-SQL Server fehlschlägt, konzentrieren Sie sich auf die Problembehandlung auf dem Remote-SQL Server, um Berechtigungen, Netzwerk- und Firewallprobleme auszuschließen.

     Notiz

     Wenn Sie sich die Liste der Zeitplan-IDs für die Aufträge in SQL Server ansehen, kann es schwierig sein, die Zuordnung der Zeitplan-ID und der Datenquelle zu finden, der sie zugeordnet ist. Sie können die folgende SQL-Abfrage ausführen, um weitere Details zu den Aufträgen zu finden, die einige benutzerfreundliche Informationen enthalten:

     use DPMDB –Change to actual name of DPMDB if it is different
     
     select
     
     sche.ScheduleId as 'SQL agent Schedule Job Name',
     
     sche.JobDefinitionId,
     
     prot.FriendlyName as 'Protection Group', am.ServerName as 'Servername or NULL',
     
     case
     
     when jobd.type = 'C9B259D2-6402-486D-8E36-C6C1ADAE0912' then 'Maintenance job that runs @ midnight'
     
     when jobd.Type = '3D859D8C-D0BB-4142-8696-C0D215203E0D' then 'Synchronization (file/volume) / Express Full (application)'
     
     when jobd.Type = '84021B5E-B4DC-9B27-2B7E-3B99BB1225FF' then 'Volume/Share/System State Recovery Point'
     
     when jobd.Type = '913afd2d-ed74-47bd-b7ea-d42055e5c2f1' then 'Backup to tape (D-T)'
     
     when jobd.Type = 'B5A3D25C-8EB2-4032-9428-C852DA5CE2C5' then 'Backup to tape (D-D-T)'
     
     when jobd.Type = 'C4CAE2F7-F068-4A37-914E-9F02991868DA' then 'Consistency Check'
     
     when jobd.Type = '5ECC82D0-3475-4E81-8ADD-55B1C1D23DB1' then 'SharePoint catalog generation'
     
     when jobd.Type = '6E7C76F4-A832-4418-A772-8E58FD7466CB' then 'Azure Online backup'
     
     end
     
     as Operation
     
     from tbl_SCH_ScheduleDefinition sche
     
     left join dbo.tbl_JM_JobDefinition jobd
     
     join tbl_IM_ProtectedGroup prot
     
     on jobd.ProtectedGroupId = prot.ProtectedGroupId
     
     on sche.JobDefinitionId = jobd.JobDefinitionId
     
     left join dbo.tbl_AM_Server AM
     
     on AM.ServerId = jobd.serverid
     
     where sche.IsDeleted = '0' and jobd.ProtectedGroupId is not null
     
     order by prot.FriendlyName
     

     Die Ausgabe der SQL-Abfrage ähnelt dem folgenden Beispiel. Basierend auf dieser Ausgabe können Sie eine Zeitplan-ID für eine Datenquelle auswählen, die klein und schnell zu Testzwecken ist.

     

Überprüfen, ob SQL Server-Aufträge deaktiviert sind

Die geplanten Aufträge sind möglicherweise in SQL Server deaktiviert. Führen Sie die folgenden Schritte aus, um die Aufträge zu überprüfen und zu aktivieren:

1. Stellen Sie in SQL Server Management Studio eine Verbindung mit der SQL Server-Instanz für DPM her, und führen Sie dann die SQL-Abfrage aus, die im vorherigen Abschnitt erwähnt wird, um die Liste der geplanten Aufträge zu finden.

2. Erweitern Sie SQL Server-Agent> Jobs. Vergleichen Sie die dort aufgeführten Aufträge mit der Ausgabe aus der SQL-Abfrage, die Sie in Schritt 1 ausgeführt haben. Wenn ein Auftrag aus der Abfrage als deaktiviert aufgeführt ist (Pfeil nach unten), klicken Sie mit der rechten Maustaste auf den Auftrag, wählen Sie "Aktivieren" aus, und führen Sie den Auftrag dann manuell aus SQL Server aus, indem Sie die im Abschnitt "Ausführen des Auftrags manuell" genannten Schritte in einem Eingabeaufforderungsbereich ausführen.

   

Überprüfen der Anmeldekontoanmeldeinformationen

DPM gibt den Namen des SQL Server-Agent Kontos in die Registrierung ein. Anschließend wird dieses Konto bei jedem Start überprüft. Die internen Schnittstellen zu DPM werden mithilfe dieses Kontos gesichert, sodass der Kontoname mit dem Kontonamen übereinstimmen muss, den die SQL Server-Agent verwendet.

Notiz

Das Konto, das von SQL Server-Agent- und SQL Server-Diensten für die SQL Server-Instanz verwendet wird, die DPMDB hostt, sollte ein lokales Konto sein (z. B. MICROSOFT$DPM$Acct oder NTAuthority\System). Wenn diese Dienste für die Ausführung unter einem Domänendienstkonto konfiguriert sind, überprüfen Sie, ob es einen bestimmten Grund gibt, warum diese für die Verwendung eines Domänenkontos konfiguriert wurden. Die Szenarien, für die ein Domänenkonto für SQL Server-Dienste erforderlich wäre, umfassen Folgendes:

• Remote SQL Server: DPM ist so konfiguriert, dass eine SQL Server-Remoteinstanz zum Hosten der DPMDB-Datenbank verwendet wird.
• Die Bibliotheksfreigabe ist aktiviert: Überprüfen Sie, ob die Bibliotheksfreigabe aktiviert ist. Wenn dies nicht der Grund ist, ändern Sie das Konto an beiden Speicherorten in das lokale Konto (SQL Server-Dienste und die Registrierungsschlüssel, die in Schritt 2 in den folgenden Schritten erwähnt werden). Oder ändern Sie die Registrierungsschlüsselwerte entsprechend dem Domänenkonto, das von SQL Server-Diensten verwendet wird, je nach Situation.

Führen Sie die folgenden Schritte aus, um die Kontoinformationen zu überprüfen und bei Bedarf Änderungen vorzunehmen:

1. Überprüfen Sie das Anmeldekonto, das für die folgenden Dienste der SQL Server-Instanz für DPM konfiguriert ist:

   • SQL Server (Instanzname)
   • SQL Server-Agent (InstanceName)

2. Überprüfen Sie die Werte im folgenden Registrierungsunterschlüssel, um zu überprüfen, ob die Werte unterschiedlich sind. Aktualisieren Sie die Werte, um das Benutzerkonto widerzuspiegeln, das für den SQL Server-Agent-Dienst verwendet wird.

   HKLM\Software\Microsoft\Microsoft Data Protection Manager\Setup

   • SqlAgentAccountName
   • SchedulerJobOwnerName

   Notiz

   Die Schritte zum Überprüfen der SQL Server-Konten, die sich in der Registrierung befinden, finden Sie unter System Center 2012 R2 Data Protection Manager-Installation schlägt fehl und generiert ID: 4323: "Ein Mitglied konnte nicht hinzugefügt werden".

3. Nachdem Sie die Kontoinformationen in der Registrierung geändert haben, starten Sie die SQL Server-Agent und die SQL Server-Dienste neu.

4. Wählen Sie auf dem DPM-Server die Schutzgruppe aus, wählen Sie im Menüband " Ändern" und dann die Schutzgruppe aus, ohne Änderungen vorzunehmen.

   Notiz

   Dieser Schritt ist erforderlich, um die Aufträge in SQL Server mithilfe der aktualisierten Kontoinformationen neu zu generieren.

5. Wenn Sie ein anderes Konto als das Microsoft$DPM$Acct-Dienstkonto verwenden, aktualisieren Sie die DDCOM-Start- und Zugriffsberechtigungen, um den Berechtigungen zu entsprechen, die Microsoft$DPM$Acct gewährt wurden. Gehen Sie dazu wie folgt vor:

   1. Starten Sie DCOMCNFG.exe an einer Eingabeaufforderung, und navigieren Sie dann zu Component Services>Computers>My Computer>DCOM Config>Microsoft System Center Data Protection Manager 2010 Service.

   2. Klicken Sie mit der rechten Maustaste auf den Dienstnamen, und wählen Sie dann "Eigenschaften" aus.

   3. Wählen Sie die Registerkarte "Sicherheit " und dann "Bearbeiten" im Bereich "Start- und Aktivierungsberechtigungen" aus.

   4. Fügen Sie das neue Konto hinzu, und erteilen Sie ihm alle Berechtigungen.

6. Überprüfen Sie die Berechtigungen für die folgenden Ordner (in denen sich Triggerjob.exe befinden), wie zutreffend:

   • DPM-Server: C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\bin

   • Remote SQL Server: C:\Program Files\Microsoft Data Protection Manager\DPM2012R2\SQLPrep

     Das DPM-Dienstkonto, Microsoft$DPM$Acct oder das Konto, das gemäß dem vorherigen Abschnitt verwendet wird (wenn sql Server remote ist), sollte über Vollzugriffsberechtigungen verfügen.

Überprüfen des triggerjob.exe Pfads auf dem Sql Server-Remoteserver

Wenn Sie eine SQL Server-Remoteinstanz für DPM 2012 SP1 und DPM 2012 R2 verwenden, überschreibt die DPM 2012 R2 SQL Server Prep den Triggerjob.exe Pfad auf dem Remote-SQL Server für DPM 2012 SP1 und ändert den Pfad wie gezeigt:

• Vorher

  %DPMInstall%\Program files\Microsoft Data Protection Manager\DPM2012\SQLPrep

• Nachher

  %DPMInstall%\Program files\Microsoft Data Protection Manager\DPM2012R2\SQLPrep

Dieses Verhalten bewirkt, dass die SQL Server-Agent nicht Triggerjob.exe finden, wenn geplante DPM 2012 SP1-Aufträge ausgeführt werden. Wenn dieses Symptom Ihrem Szenario entspricht, führen Sie DPM 2012 SP1 SQL Server Prep erneut aus, um das Problem zu beheben.

Weitere Informationen zu diesem spezifischen Symptom finden Sie in diesem Blogartikel zu System Center Data Protection Manager.

Überprüfen der Netzwerk- und Firewalleinstellungen

Wenn Sie mehrere Netzwerkschnittstellencontroller (NETWORK Interface Controller, NICs) und unterschiedliche Netzwerke für SQL Server oder DPM verwenden und die SQL Server-Agent oder Hostdatei auf dem SQL Server auf den DPM-Server verweist, führen Sie die folgenden Tests aus, um eine ungültige IP-Adresse oder falsche Firewalleinstellungen auszuschließen:

1. Stellen Sie sicher, dass Triggerjob.exe sich der angegebene Pfad befindet.

2. Führen Sie den Triggerjob.exe Befehl manuell aus, indem Sie den Hostnamen und die IP-Adresse des DPM-Servers verwenden. Überprüfen Sie dann, ob der Befehl abgeschlossen ist, und ruft das DPM-Modul erfolgreich auf.

3. Stellen Sie sicher, dass die DNS-Auflösung ordnungsgemäß funktioniert und dass eine Firewall die Kommunikation nicht blockiert. Gehen Sie dazu wie folgt vor:

   1. Fügen Sie auf dem SQL Server einen Hostdateieintrag für den DPM-Servernamen und die IP-Adresse hinzu.

   2. Fügen Sie die folgenden Firewallregeln auf dem DPM-Server hinzu:

      • advfirewall firewall add rule name="SMB for installation (TCP-139,445-In)" dir=in action=allow profile=any localport=139,445 protocol=tcp remoteip=agentIPAddresses

      • advfirewall firewall adds rule name="SMB for installation (UDP- 137,138-In)" dir=in action=allow profile=any localport=137,138 protocol=udp remoteip=agentIPAddresses

      • advfirewall firewall adds rule name="RPC for DPM (TCP- 135,5718,5719,49152-65535-In)" dir=in action=allow profile=any localport=135,5718,5719,49152-65535 protocol=tcp remoteip=agentIPAddresses,SQLIPAddress

Proaktive Überwachung auf geplante Auftragsfehler

Sie können eine Warnung außerhalb von DPM einrichten, um SQL Server-Agent Scheduler-Fehler zu überwachen. Wenn Sie beispielsweise System Center 2012 Operations Manager in Ihrer Umgebung bereitgestellt haben, können Sie es so konfigurieren, dass Warnungen für Warnungen oder Fehlermeldungen, die von SQLAgent$MSDPM2012 der Quelle generiert werden, überwacht und generiert werden. Sie können auch speziell die Ereignis-ID 208 überwachen.

Notiz

Um Überraschungen zu vermeiden, stellen Sie sicher, dass Sie regelmäßig den Status von Wiederherstellungspunktaufträgen und deren Verfügbarkeit überprüfen, indem Sie die Wiederherstellungspunkte im Wiederherstellungsaufgabenbereich in der DPM-Konsole überprüfen.