Veeam Backup and Replication Logfile Pfade

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003:
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7:
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux:
    /var/log/VeeamBackup/

Veeam Backup & Replication Console startet nicht (veeam.backup.shell.exe System.Xml.XmlException)

Problem

Die Veeam Backup & Replication Console startet „auf einmal“ nicht mehr. Gestern ging es noch, heute passiert (scheinbar) nichts mehr, es ist nicht einmal der Anmeldedialog zu sehen. Im Ereignisprotokoll sind nach jedem Versuch veeam.backup.shell.exe zu starten diese Fehler zu sehen:

  • Protokoll: Anwendung
  • Quelle: .NET Runtime
  • Ereignis-ID: 1026
Anwendung: veeam.backup.shell.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.Xml.XmlException
bei System.Xml.XmlTextReaderImpl.Throw(System.Exception)
bei System.Xml.XmlTextReaderImpl.ParseText(Int32 ByRef, Int32 ByRef, Int32 ByRef)
bei System.Xml.XmlTextReaderImpl.ParseText()
bei System.Xml.XmlTextReaderImpl.ParseElementContent()

[...]

Lösung

Warscheinlich ist nur die Benutzerkonfiguration der Konsole kaputt. Das .NET Framework ist (ausnahmsweise) da mal nicht schuld.

Es hilft das Löschen der Datei:

%USERPROFILE%\AppData\Local\Veeam_Software_Group_GmbH\veeam.backup.shell.exe_Url_hu1utqnj52thvmhrg5kie2bl15o22i22\10.0.0.0\user.config

Danach startet die Konsole sofort wieder.

Windows Eventlog CAPI2 Event 513 „AddLegacyDriverFiles: Unable to back up image of binary“

Problem

Bei jedem Backup das einen externen VSS-Agenten benutzt, beispielsweise Veeam B&R mit Application Awareness, werden diese Fehler vom Kryptografiedienst (CAPI2 steht für „Windows CryptoAPI v2“) gemeldet. In der Meldung steht „Zugriff zudem verweigert“, was auf fehlenden Zugriffsrechte hindeutet.

Fehler beim Kryptografiedienst während der Verarbeitung des „OnIdentity()“-Aufrufobjekts „System Writer“.

Lösung

Das Dienstobjekt „Microsoft Link-Layer Discovery Protocol“ hat tatsächlich nicht die korrekten Berechtigungen, um vom VSS System Writer gelesen zu werden.

Man kann die Berechtiugung manuell hinzufügen, oder das die Kommandozeile erledigen lassen:

C:\> sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;CCLCSWLOCRRC;;;SU)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)

Danach ist die Meldung sofort verschwunden 🙂

Update: Microsoft hat dazu einen KB-Artikel veröffentlicht https://support.microsoft.com/en-us/help/3209092/event-id-513-when-running-vss-in-windows-server

Veeam Update „Warning 1327.Invalid Drive D:\“

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.

Veeam „Unable to update SQL backupset for instance SQLEXPRESS : Code = 0x80040e09 Code meaning = IDispatch error #3081“

Veeam Backup&Replication beendet seit dem Update 3a alle Backup-Jobs die Windows Server mit einem installierten SQL-Server Express Edition beinhalten mit einem gelben „Warning“ Hinweis. Das passiert auch bei SQL-Servern, deren Application-Aware Benutzer zu wenig Berechtigungen auf den Datenbanken besitzt. Die Maschine an sich wird aber gesichert.

Die Warnung lautet

Unable to update SQL backupset for instance SQLEXPRESS : Code = 0x80040e09
Code meaning = IDispatch error #3081 Source = Microsoft OLE DB Provider for SQL Server
Description = The UPDATE permission was denied on the object 'backupset', database 'msdb', schema 'dbo'.

Das passiert, weil der Benutzer der von Veeam für das Application-Aware Processing genutzt wird, standartmäßig zu wenig Berechtigungen in einer SQL Express Edition (EE) Datenbanken besitzt um die Transaktionsprotokolle zu markieren. Der Fehler tritt erst seit Update 3a auf, weil Veeam dort das Verhalten des Agenten geändert (=korrigiert) hat.

Lösung

Die Berechtigungen in der Datenbank müssen nur schnell angepasst werden. Das geht am einfachsten mit dem SQL Management Studio. Standartmäßig steht eine SQL-Express Instanz alledings nur auf dem lokalen Host zu Verfügung, weswegen man das SSMS entweder auf dem betrroffenen Server installieren muss, oder die SQL-Instanz über das Netzwerk erreichbar macht.

Welche Application-Aware Processoin Credentials werden verwendet?

Das kann man direkt im Job nachschlagen, unter Guest Processing > Guest OS Credentials.

Dann …

  • SSMS „Als Administrator“ starten und mit localhost\sqlexpress verbinden
  • Falls noch nicht geschehen, unter Sicherheit > Anmeldungen den betreffenden Benutzer hinzufügen.
  • Dann dem Benutzer links unter „Serverrollen“ die Rolle „sysadmin“ zuweisen.