Résoudre les échecs de travaux de sauvegarde planifiés dans Data Protection Manager

Cet article explique comment résoudre les échecs de travaux de sauvegarde planifiés dans Microsoft System Center Data Protection Manager (DPM).

Version d’origine du produit : System Center Data Protection Manager
Numéro de la base de connaissances d’origine : 4456295

Parfois, les travaux de point de récupération ne sont pas exécutés comme prévu, même si la status de protection des sources de données respectives continue d’apparaître en vert (OK) dans la console DPM. Ce problème se produit généralement quand SQL Server Agent ne parvient pas à appeler le moteur DPM pour exécuter le travail planifié.

Fonctionnement de l’exécution planifiée des travaux

Lorsque des groupes de protection sont configurés, DPM crée des travaux de sauvegarde (synchronisations incrémentielles, express full, etc.) dans SQL Server pour chaque source de données, ainsi que d’autres travaux de maintenance. Un composant appelé TriggerJob.exe est utilisé pour appeler le moteur DPM en transmettant l’ID de définition de travail de la source de données pour commencer l’exécution du travail de sauvegarde. TriggerJob.exeest exécuté par le planificateur SQL Server Agent à l’heure planifiée via la syntaxe de commande suivante :

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

Voici un exemple de commande classique exécutée par Schedule Agent Scheduler pour commencer l’exécution du travail à l’heure planifiée :

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>

Pour une raison quelconque, la commande ne s’exécute pas et n’appelle Triggerjob.exepas , le moteur DPM n’est pas appelé. Par conséquent, le travail de sauvegarde ne s’exécute pas. Étant donné que SQL Server n’a pas exécuté la commande, DPM n’est pas au courant de cet échec et continue d’afficher le status de protection des sources de données en vert.

Les sections suivantes fournissent quelques techniques pour résoudre les échecs de travaux de sauvegarde planifiés.

Vérifier le journal des applications

Lorsqu’une tâche de sauvegarde planifiée ne parvient pas à être appelée par SQL Server, DPM ne déclenche aucune alerte pour ces échecs de travail, car il s’agit d’un échec côté SQL Server. Toutefois, ces événements sont capturés dans le journal des applications en tant qu’événements SQL Server, Rapport d'erreurs Windows ou MSDPM, selon la cause du problème. Veillez à case activée le journal de l’application dans observateur d'événements pour tous les événements de SQL Server liés à l’échec du travail planifié. Si votre ordinateur DPM utilise des SQL Server distants pour DPMDB, consultez le journal des applications sur le serveur distant.

Par exemple, l’événement suivant se trouve dans le journal des applications pour indiquer que le SQL Server Agent rencontrer un problème lorsqu’il a essayé d’exécuter la ligne de commande.

Nom du journal : Application
Source : SQLAgent$MSDPM2012
Date : <date & heure>
ID d’événement : 208
Catégorie de tâche : Moteur de travail
Niveau : Avertissement
Mots clés : classique
Utilisateur : N/A
Ordinateur : <DPMServerName>
Description :
SQL Server travail planifié « 00890b12-9058-4f42-8143-291dc3de4d78 » (0xC52C50485ED1754EB12D16117B258DD7) - État : Échec - Appelé sur : <Date & Heure> - Message : Le travail a échoué. Le travail a été appelé par User <UserName>. La dernière étape à exécuter était l’étape 1 (JobStep par défaut).

Voici un exemple d’événement de Rapport d'erreurs Windows :

Compartiment d’erreur , type 0
Nom de l’événement : DPMException
Réponse : Non disponible
ID du cab : 0

Signature du problème :
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 :

Autre exemple d’événement du moteur DPM :

Nom du journal : Application
Source : MSDPM
Date : <date & heure>
ID d’événement : 976
Catégorie de la tâche : Aucun
Niveau : Erreur
Mots clés : classique
Utilisateur : N/A
Ordinateur : <nom de domaine complet de DPMServerName>
Description :
La description de l’ID d’événement 976 du MSDPM source est introuvable. Le composant qui déclenche cet événement n’est pas installé sur votre ordinateur local, ou l’installation est endommagée. Vous pouvez installer ou réparer le composant sur l’ordinateur local.
Le travail DPM a échoué, car il n’a pas pu contacter le moteur DPM.

Détails du problème :
<JobTriggerFailed__System ID 9/ID><Seq>0</Seq><TimeCreated><Date & Time></TimeCreated><Source>TriggerJob.cs</Ligne>source><76</Line><HasError>True</HasError></__System><Tags><JobSchedule /></Tags></JobTriggerFailed<>><><>

Exécuter le travail manuellement à partir de SQL Server Management Studio

Vous pouvez essayer d’exécuter le travail manuellement à partir de SQL Management Studio. Pour cela, procédez comme suit :

1. Démarrez SQL Server Management Studio et connectez-vous au SQL Server instance utilisé pour la base de données DPMDB. Développez SQL Server Agent>Jobs. Les valeurs GUID de la liste sous Travaux fournissent l’ID de planification pour chaque travail. Cliquez avec le bouton droit sur un travail, puis sélectionnez Démarrer le travail à l’étape dans le menu contextuel.

   

2. Si le travail ne s’exécute pas, vous devez recevoir un message d’erreur semblable à ce qui suit.

   Échec de l’exécution du travail « 00890b12-9058-4f42-8143-291dc3de4d78 ».

   

3. Ce message confirme que le SQL Server Agent n’a pas pu exécuter le travail en raison d’autorisations incorrectes ou d’une autre raison. Consultez la section Vérifier les informations d’identification du compte de connexion pour résoudre ce problème.

Exécuter le travail manuellement à une invite de commandes

Vous pouvez exécuter Triggerjob.exe sur une ligne de commande pour case activée manuellement si la commande sera exécutée et si le travail de sauvegarde démarrera correctement dans DPM. Pour cela, procédez comme suit :

1. Démarrez SQL Server Management Studio, puis connectez-vous au SQL Server instance utilisé pour la base de données DPMDB. Développez SQL Server Agent>Jobs. Cliquez avec le bouton droit sur l’un des travaux, puis sélectionnez Propriétés.

   

2. Dans la boîte de dialogue Propriétés , sélectionnez Étapes sur la gauche, puis sélectionnez le bouton Modifier en bas.

   

3. Dans la boîte de dialogue Propriétés de l’étape du travail , copiez la commande à partir de la fenêtre d’invite de commandes, comme illustré dans la capture d’écran suivante.

   

4. Exécutez la commande copiée, le cas échéant :

   • À une invite de commandes avec élévation de privilèges sur le serveur DPM (qui exécute une instance locale de SQL Server), exécutez l’exemple de commande suivant :

     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>
     

     Si la commande s’exécute correctement, le problème est probablement lié à des autorisations ou des informations d’identification d’ouverture de session incorrectes. Pour résoudre ce problème , consultez la section Vérifier les informations d’identification du compte de connexion.

   • À une invite de commandes avec élévation de privilèges sur le serveur SQL distant, exécutez l’exemple de commande suivant (le cas échéant) :

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

     Dans le scénario de SQL Server à distance, si la commande se termine correctement sur le serveur DPM mais échoue sur le SQL Server distant, concentrez vos efforts de résolution des problèmes sur le SQL Server distant pour exclure les problèmes d’autorisations, de réseau et de pare-feu.

     Remarque

     Lorsque vous examinez la liste des ID de planification pour les travaux dans SQL Server, il peut être difficile de trouver le mappage de l’ID de planification et de la source de données à laquelle il est associé. Vous pouvez exécuter la requête SQL suivante pour obtenir plus de détails sur les travaux qui incluent des informations conviviales :

     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
     

     La sortie de la requête SQL ressemble à l’exemple suivant. Sur la base de cette sortie, vous pouvez choisir un ID de planification pour une source de données petite et rapide à des fins de test.

     

Vérifier si SQL Server travaux sont désactivés

Les travaux planifiés peuvent être désactivés dans SQL Server. Pour case activée et activer les travaux, procédez comme suit :

1. Dans SQL Server Management Studio, connectez-vous au SQL Server instance pour DPM, puis exécutez la requête SQL mentionnée dans la section précédente pour rechercher la liste des travaux planifiés.

2. Développez SQL Server Agent>Jobs. Comparez les travaux qui y sont répertoriés avec la sortie de la requête SQL que vous avez exécutée à l’étape 1. Si un travail de la requête est répertorié comme Désactivé (flèche pointant vers le bas), cliquez avec le bouton droit sur le travail, sélectionnez Activer, puis exécutez le travail manuellement à partir de SQL Server en suivant les étapes mentionnées dans la section Exécuter le travail manuellement à une invite de commandes.

   

Vérifier les informations d’identification du compte d’ouverture de session

DPM entre le nom du compte SQL Server Agent dans le registre. Il vérifie ensuite ce compte chaque fois qu’il démarre. Les interfaces internes à DPM étant sécurisées à l’aide de ce compte, le nom du compte doit correspondre au nom du compte utilisé par le SQL Server Agent.

Procédez comme suit pour vérifier les informations de compte et apporter les modifications nécessaires :

1. Vérifiez le compte d’ouverture de session configuré pour les services suivants du SQL Server instance pour DPM :

   • SQL Server (InstanceName)
   • SQL Server Agent (InstanceName)

2. Vérifiez les valeurs de la sous-clé de Registre suivante pour vérifier que les valeurs sont différentes. Mettez à jour les valeurs pour refléter le compte d’utilisateur utilisé pour le service SQL Server Agent.

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

   • SqlAgentAccountName
   • SchedulerJobOwnerName

   Remarque

   Pour connaître les étapes de vérification des comptes SQL Server qui se trouvent dans le Registre, consultez Échec de l’installation de System Center 2012 R2 Data Protection Manager et génère l’ID : 4323 : « Un membre n’a pas pu être ajouté ».

3. Après avoir modifié les informations de compte dans le Registre, redémarrez le SQL Server Agent et les services SQL Server.

4. Sur le serveur DPM, sélectionnez le groupe de protection, sélectionnez Modifier dans le ruban, puis terminez et mettez à jour le groupe de protection sans apporter de modifications.

   Remarque

   Cette étape est nécessaire pour régénérer les travaux dans SQL Server à l’aide des informations de compte mises à jour.

5. Si vous utilisez un compte autre que le compte de service Microsoft$DPM$Acct , mettez à jour les autorisations de lancement et d’accès DDCOM pour qu’elles correspondent à ce qui a été accordé à Microsoft$DPM$Acct. Pour cela, procédez comme suit :

   1. Démarrez DCOMCNFG.exe à partir d’une invite de commandes, puis accédez à Services de composants>Ordinateurs>Mon ordinateur>DCOM Configuration>Microsoft System Center Data Protection Manager 2010 Service.

   2. Cliquez avec le bouton droit sur le nom du service, puis sélectionnez Propriétés.

   3. Sélectionnez l’onglet Sécurité , puis modifier dans la zone Autorisations de lancement et d’activation .

   4. Ajoutez le nouveau compte et accordez-lui toutes les autorisations.

6. Vérifiez les autorisations sur les dossiers suivants (dans lesquels se trouve Triggerjob.exe), le cas échéant :

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

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

     Le compte de service DPM, Microsoft$DPM$Acct ou le compte utilisé dans la section précédente (si le SQL Server est distant) doit disposer des autorisations Contrôle total.

Vérifiez le chemin d’accès triggerjob.exe sur le SQL Server distant

Si vous utilisez un SQL Server instance distant pour DPM 2012 SP1 et DPM 2012 R2, DPM 2012 R2 SQL Server Prep remplace le chemin d’accès Triggerjob.exe sur le SQL Server distant pour DPM 2012 SP1 et modifie le chemin d’accès comme indiqué :

• Avant

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

• Après

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

Ce comportement empêche la SQL Server Agent de trouver Triggerjob.exe lors de l’exécution des travaux planifiés DPM 2012 SP1. Si ce symptôme correspond à votre scénario, réexécutez DPM 2012 SP1 SQL Server Prep pour résoudre le problème.

Pour plus d’informations sur ce symptôme spécifique, consultez cet article de blog System Center Data Protection Manager.

Vérifier les paramètres du réseau et du pare-feu

Si vous utilisez plusieurs contrôleurs d’interface réseau (NIC) et différents réseaux pour SQL Server ou DPM, et que le fichier SQL Server Agent ou hôte sur le SQL Server pointe vers le serveur DPM, exécutez les tests suivants pour exclure une adresse IP incorrecte ou des paramètres de pare-feu incorrects :

1. Vérifiez que Triggerjob.exe se trouve dans le chemin spécifié.

2. Exécutez la Triggerjob.exe commande manuellement en utilisant le nom d’hôte et l’adresse IP du serveur DPM, chacun à son tour. Ensuite, case activée si la commande se termine et appelle correctement le moteur DPM.

3. Assurez-vous que la résolution DNS fonctionne correctement et qu’un pare-feu ne bloque pas les communications. Pour ce faire, procédez comme suit :

   1. Sur le SQL Server, ajoutez une entrée de fichier hôte pour le nom et l’adresse IP du serveur DPM.

   2. Ajoutez les règles de pare-feu suivantes sur le serveur DPM :

      • 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

Surveiller de manière proactive les échecs de travaux planifiés

Vous pouvez configurer une alerte en dehors de DPM pour surveiller les échecs SQL Server Agent Scheduler. Par exemple, si System Center 2012 Operations Manager est déployé dans votre environnement, vous pouvez le configurer pour surveiller et générer des alertes pour les messages d’avertissement ou d’erreur générés par SQLAgent$MSDPM2012 la source. Vous pouvez également surveiller spécifiquement l’ID d’événement 208.