Le Job signale l'avertissement "Failed to truncate transaction logs for SQL instances: Possible reasons: lack of permissions, or transaction log corruption."

Le Job peut signaler un avertissement : "Failed to finalize guest processing. Details: Failed to process 'TruncateSQLLog' command. Failed to truncate transaction logs for SQL instances: <instance name>. Possible reasons: lack of permissions, or transaction log corruption."

La troncature des logs SQL est effectuée sous le compte utilisateur spécifié dans AAIP dans les paramètres Job, si elle échoue, le GuestHelper essaie de tronquer les logs de transactions sous le compte LocalSystem.

Pour comprendre pourquoi la troncature des logs SQL a échoué, vous devrez ouvrir le log de GuestHelper dans Guest VM, et recherchez la ligne "Truncation Statistics".

• Windows 2008 et plus récents
  \\GUESTVM\c$\ProgramData\Veeam\Backup\VeeamGuestHelper_%date%.log
• Windows 2003
  \\GUESTVM\c$\Documents and Settings\All Users\Application Data\Veeam\Backup\VeeamGuestHelper_%date%.log

Erreurs connues et solutions

1. Erreur: OpenFromInitializationString failed. [Login failed for 'DOMAIN\user'.]
   Solution: Donnez les permissions "DOMAIN\user" sur l’instance SQL et ajoutez le rôle db_backupoperator pour toutes les bases de données FULL et BULK, ou bien donnez-lui le rôle «sysadmin».
    
2. OLEDB Error: 'The server principal "DOMAIN\user" is not able to access the database "DATABASE" under the current security context.', HelpCtx: '0'
   Solution: Donnez un rôle "DOMAIN\user" db_backupoperator pour toutes les bases de données FULL et BULK, ou bien donnez-lui un rôle sysadmin.
    
3. OLEDB Error: 'BACKUP detected corruption in the database log. Check the error log for more information.', HelpCtx: '0'
   Solution: l'erreur indique une corruption possible et des problèmes avec le serveur SQL
    
4. OLEDB Error: 'BACKUP LOG cannot be performed because there is no current database backup.'
   
   En règle générale, ceci est un problème avec le noeud secondaire du SQL toujours sur le cluster. Vous pouvez résoudre ce problème en effectuant une sauvegarde de la base de données en question via SQL Management Studio. Sinon, vous pouvez définir le noeud secondaire comme principal pour une seule exécution du job de backup. En conséquence, tous ses bases de données seront sauvegardées sans drapeau "copier uniquement" et l'erreur disparaîtra.
   
   Le problème se produit lorsque le nœud secondaire a toujours été sauvegardé avec un drapeau "copier uniquement" et ses bases de données indépendantes n'ont aucune sauvegarde complète. Ainsi, lors de la troncation des journaux de la base de données indépendante, nous obtenons le message mentionné ci-dessus.
   
   La même solution s'applique si vous obtenez ce message pour la base de données vCenter / Veeam exclue.
    
5. "Query timeout expired" Si vous voyez cette entrée dans le journal VeeamGuestHelper, cela signifie généralement que nous ne pouvons pas tronquer les journaux SQL dans le temps alloué (par défaut, le délai d'attente n'est que de 300 secondes). Habituellement, vous pourriez rencontrer de tels problèmes avec des bases de données assez volumineuses, et avec une grande quantité de journaux des transactions.
   Solution: Implémenter la valeur de registre suivante dans les machines virtuelles affectées dans [HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\] and [HKLM\SOFTWARE\Wow6432Node\VeeaM\Veeam Backup and Replication] (s'il n' y en a pas, vous devrez la créer).:
   • SqlExecTimeout
   • Type: REG_DWORD
   • Default value: 300 (in seconds, decimal)
   Essayez d'étendre cette valeur et lancez une sauvegarde par la suite, il faut généralement le régler à 600 secondes.

Si vous observez l'avertissement suivant "Failed to truncate transaction logs for SQL instances: MICROSOFT WID" sur Veeam B&R version 8.0.0.2084, veuillez contacter Veeam Support pour le hot-fix.