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 du produit d’origine : System Center Data Protection Manager
Numéro de 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 l’état 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 lorsque SQL Server Agent ne parvient pas à appeler le moteur DPM pour exécuter le travail planifié.

Note

Ce problème n’affecte pas les travaux manuels ad hoc, car SQL Server Agent n’est pas utilisé lorsque vous exécutez des travaux manuels à partir de la console DPM.

Fonctionnement de l’exécution du travail planifié

Lorsque des groupes de protection sont configurés, DPM crée des travaux de sauvegarde (synchronisations incrémentielles, express complet, et ainsi de suite) dans SQL Server pour chaque source de données, ainsi que d’autres travaux de maintenance. Composant connu comme TriggerJob.exe utilisé pour appeler le moteur DPM en transmettant l’ID de définition de travail pour la source de données afin de commencer l’exécution du travail de sauvegarde. TriggerJob.exe est exécuté par le planificateur sql Server Agent au moment planifié 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>

Note

Ce chemin peut différer selon la version de DPM et s’il s’agit d’une mise à niveau (même chemin) ou d’une nouvelle installation (chemin différent).

Pour une raison quelconque, la commande ne s’exécute pas et n’appelle Triggerjob.exepas, le moteur DPM n’est pas appelé. La tâche de sauvegarde ne s’exécute donc pas. Étant donné que SQL Server n’a pas exécuté la commande, DPM ne sait pas ce problème et continue d’afficher l’état 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’un travail de sauvegarde planifié ne peut pas être appelé par SQL Server, DPM ne déclenche aucune alerte pour ces échecs de travail, car il s’agissait 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, Rapports d’erreurs Windows ou MSDPM, en fonction de la cause du problème. Vérifiez que vous vérifiez le journal des applications dans l’Observateur d’événements pour tous les événements de SQL Server liés à l’échec du travail planifié. Si votre ordinateur DPM utilise SQL Server distant pour DPMDB, passez en revue le journal d’application sur le serveur distant.

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

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

Voici un exemple d’événement du 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 :

Un autre exemple d’événement du moteur DPM :

Log Name: Application
Source : MSDPM
Date : <date et heure>
ID d’événement : 976
Catégorie de tâche : None
Niveau : Error
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <nom de domaine complet de DPMServerName>
Description :
La description de l’ID d’événement 976 de la source MSDPM 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 &TimeCreated><><>< Source>TriggerJob.cs</Source><Line>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 ce faire, procédez comme suit :

1. Démarrez SQL Server Management Studio et connectez-vous à l’instance SQL Server utilisée pour la base de données DPMDB. Développez les travaux de SQL Server Agent>. Les valeurs des 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 l’Agent SQL Server 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 d’ouverture de session pour résoudre ce problème.

Exécuter le travail manuellement à l’invite de commandes

Vous pouvez exécuter Triggerjob.exe à une ligne de commande pour vérifier manuellement si la commande sera exécutée et que le travail de sauvegarde démarre correctement dans DPM. Pour ce faire, procédez comme suit :

1. Démarrez SQL Server Management Studio, puis connectez-vous à l’instance SQL Server utilisée pour la base de données DPMDB. Développez les travaux de SQL Server Agent>. 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 à gauche, puis sélectionnez le bouton Modifier en bas.

   

3. Dans la boîte de dialogue Propriétés de l’étape de 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é aux autorisations incorrectes ou aux informations d’identification d’ouverture de session. Consultez la section Vérifier les informations d’identification du compte d’ouverture de session pour résoudre ce problème.

   • À 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 SQL Server distant, si la commande se termine correctement sur le serveur DPM, mais échoue sur le serveur SQL Server distant, concentrez vos efforts de résolution des problèmes sur le serveur SQL Server distant pour exclure les autorisations, le réseau et les problèmes de pare-feu.

     Note

     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 associée. Vous pouvez exécuter la requête SQL suivante pour obtenir plus d’informations 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. En fonction de cette sortie, vous pouvez choisir un ID de planification pour une source de données petite et rapide pour les tests.

     

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

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

1. Dans SQL Server Management Studio, connectez-vous à l’instance SQL Server 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 les travaux de SQL Server Agent>. Comparez les travaux répertoriés ici 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 dans une section d’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 sont sécurisées à l’aide de ce compte. Le nom du compte doit donc correspondre au nom du compte utilisé par SQL Server Agent.

Note

Le compte utilisé par SQL Server Agent et les services SQL Server pour l’instance SQL Server qui héberge DPMDB doit être un compte local (par exemple, MICROSOFT$DPM$Acct ou NTAuthority\System). Si ces services sont configurés pour s’exécuter sous un compte de service de domaine, vérifiez s’il existe une raison spécifique quant à la raison pour laquelle ceux-ci ont été configurés pour utiliser un compte de domaine. Les scénarios qui nécessitent un compte de domaine pour les services SQL Server incluent les éléments suivants :

• Remote SQL Server : DPM est configuré pour utiliser une instance SQL Server distante pour héberger sa base de données DPMDB.
• Le partage de bibliothèque est activé : vérifiez si le partage de bibliothèque est activé. Si ce n’est pas le cas, remplacez le compte par le compte local aux deux emplacements (services SQL Server et clés de Registre mentionnées à l’étape 2 dans les étapes suivantes). Ou modifiez les valeurs de clé de Registre pour qu’elles correspondent au compte de domaine utilisé par les services SQL Server, en fonction de la situation.

Procédez comme suit pour vérifier les informations du compte et apporter des modifications si nécessaire :

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

   • SQL Server (nom_instance)
   • 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

   Note

   Pour connaître les étapes de vérification des comptes SQL Server qui se trouvent dans le Registre, consultez l’installation de System Center 2012 R2 Data Protection Manager échoue et génère l’ID : 4323 : « Impossible d’ajouter un membre ».

3. Après avoir modifié les informations du compte dans le Registre, redémarrez 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.

   Note

   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 correspondre à ce qui a été accordé à Microsoft$DPM$Acct. Pour ce faire, procédez comme suit :

   1. Démarrez DCOMCNFG.exe à l’invite de commandes, puis accédez au >service Microsoft System Center Data Protection Manager 2010 sur les>>ordinateurs des services>de composants.

   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 sélectionnez Modifier dans la zone Lancer et Autorisations 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 distant : C:\Program Files\Microsoft Data Protection Manager\DPM2012R2\SQLPrep

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

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

Si vous utilisez une instance SQL Server distante pour DPM 2012 SP1 et DPM 2012 R2, la préparation SQL Server DPM 2012 R2 remplace le chemin d’accès Triggerjob.exe sur le serveur SQL Server distant pour DPM 2012 SP1 et modifie le chemin comme indiqué :

• Avant le

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

• Après

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

Ce comportement entraîne l’échec de la recherche de l’agent SQL Server Triggerjob.exe lorsque les travaux planifiés DPM 2012 SP1 sont exécutés. Si ce symptôme correspond à votre scénario, réexécutez DPM 2012 SP1 SQL Server 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 et différents réseaux pour SQL Server ou DPM, et que l’Agent SQL Server ou le fichier hôte sur le serveur 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 qu’il Triggerjob.exe se trouve dans le chemin d’accès spécifié.

2. Exécutez la Triggerjob.exe commande manuellement à l’aide du nom d’hôte et de l’adresse IP du serveur DPM, chacun à son tour. Vérifiez ensuite 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 SQL Server, ajoutez une entrée de fichier hôte pour le nom du serveur DPM et l’adresse IP.

   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 du planificateur sql Server Agent. 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 avertissements ou les messages d’erreur générés par SQLAgent$MSDPM2012 source. Vous pouvez également surveiller spécifiquement l’ID d’événement 208.

Note

Pour éviter toute surprise, veillez à vérifier régulièrement l’état des travaux de point de récupération et leur disponibilité en examinant les points de récupération dans la zone des tâches de récupération dans la console DPM.