Job riporta l’avviso "Failed to truncate transaction logs for SQL instances: Possible reasons: lack of permissions, or transaction log corruption."

Il job può segnalare un avviso: "Failed to finalize guest processing. Details: Failed to process 'TruncateSQLLog' command. Failed to truncate transaction logs for SQL instances: . Possible reasons: lack of permissions, or transaction log corruption."

Il troncamento del log di SQL viene eseguito con l'account utente specificato in AAIP nelle impostazioni del job, in caso contrario, GuestHelper tenta di troncare i log delle transazioni con l'account LocalSystem.

Per capire il motivo per cui SQL segnala il troncamento fallito, bisogna aprire il log GuestHelper che si può rintracciare all’interno della VM guest e cercare "Truncation Statistics".

• Windows 2008 o più recente or later
  \\GUESTVM\c$\ProgramData\Veeam\Backup\VeeamGuestHelper_%date%.log
• Windows 2003
  \\GUESTVM\c$\Documents and Settings\All Users\Application Data\Veeam\Backup\VeeamGuestHelper_%date%.log

Errori conosciuti e Soluzioni

1. Errore: OpenFromInitializationString failed. [Login failed for 'DOMAIN\user'.]
   Soluzione: assegnare a DOMAIN\user i permessi per l’istanza SQL e il ruolo db_backupoperator per tutti i database FULL e BULK, oppure assegnargli il ruolo sysadmin.
    
2. Errore OLEDB: 'The server principal "DOMAIN\user" is not able to access the database "DATABASE" under the current security context.', HelpCtx: '0'
   Soluzione: gassegnare a DOMAIN\user il ruolo db_backupoperator per tutti i database FULL e BULK, oppure assegnargli il ruolo sysadmin.
    
3. Errore OLEDB: 'BACKUP detected corruption in the database log. Check the error log for more information.', HelpCtx: '0'
   Soluzione: errore indica la potenziale corruzione e problemi con il server SQL
    
4. Errore OLEDB: 'BACKUP LOG cannot be performed because there is no current database backup.'
   
   Tipicamente, è un problema con il nodo secondario del cluster SQL AlwaysOn. Per risolverlo, basta eseguire il backup della DB in questione tramite SQL Server Management Studio. Altrimenti, bisogna impostare il nodo secondario come primario per una sessione di backup. Di conseguenza, tutti i suoi DB verranno backupati senza il parametro "copy only" e l'errore sparisce
   
   Il problema si verifica quando il nodo secondario è sempre stato backupato con il flag "copy only" e i suoi DB standalone non hanno alcun backup completo. Perciò, durante il troncamento dei log dei DB standalone, si verifica il messaggio di sopra.
   
   La stessa soluzione vale se questo messaggio apppare riguardo i database di vCenter/Veeam esclusi.
    
5. "Query timeout expired"

SqlExecTimeout
Type: REG_DWORD
Default value: 300 (in secondi, decimale)

SqlExecTimeout
Type: REG_DWORD
Default value: 300 (in secondi, decimale)

Se riceve il seguente avviso "Failed to truncate transaction logs for SQL instances: MICROSOFT WID" sulla versione Veeam B&R 8.0.0.2084, si prega di contattare il Supporto Veeam per l’installazione dell’hotfix.