Kategorie-Archiv: Veeam

Veeam: Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 [0x8004231f].

Veröffentlicht am von — Keine Kommentare ↓

Veeam gibt diese Warnung in einem Backup-Job aus:

Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].

Lösung

Der Fehlercode 0x8004231f steht für „VSS_E_INSUFFICIENT_STORAGE“ oder auch „nicht genügend Speicherplatz für die Schattenkopie“. Die Festplatte ist voll.

Schattenspeicherplatz wird für die Systemwiederherstellungspunkte von Veeam Backup & Recovery verwendet, wenn „Appication Image Aware Processing“ eingeschaltet ist (was auch empfohne ist).

Der Fehler tritt auf wenn die Festplatte tatsächlich voll ist. Das kann zum Beispiel ungewollt passieren, wenn man der 100Mbyte großen Windows „EFI-Systempartition“ oder der (möglicherweise eingerichteten) „Widerherstellungspartition“ einen Laufwerksbuchstaben gegeben hat. Naturgemäß haben diese Partitionen praktisch keinen freien Speicherplatz. „Voll“ bedeutet hier, „nicht genug Platz für eine Volumenschattenkopie“. Bei Maschinen mit viel Arbeitsspeicherbedarf, zum Beispiel ERP-Systeme oder SQL-Server, kann das plötzlich sehr viel sein. Wir haben einen SQL-Server VSS Dump „mal eben“ 20Gbyte schreiben sehen.

Veeam Job Fail [Error Unhandled exception was thrown during licensing process]

Veröffentlicht am von — Keine Kommentare ↓

Jeden Tag laufen eine Menge Backup-Jobs. Einer nicht – oder besser, einige Maschinen darin nicht. Der Fehler im Veeam Backup & Replication Protokoll lautet:

[Error Unhandled exception was thrown during licensing process]

Die Lizenzierung wurde natürlich geprüft und alle Hosts und vCenter waren mit korrkten Lizenen ausgestatte. Es wurden auch keine Instanzen separat lizenziert oder ähnliches.

Lösung

Es stellte sich heraus, dass selbiges kein Lizenzproblem ist. Der genutzte vCenter-Server war einfach nicht erreichbar (502 nach Neustart). Der selbe Fehler tritt auch auf, wenn man das Passwort des Benutzers, der für die Verbindung mit VMware vCenter verwendet wird, ändert.

Als der vCenter wieder da war (respektive das Kennwort angepasst), läuft auch alles wieder einwandfrei.

Veeam „Active snapshots limit reached for datastore“ bei Pending VMs

Veröffentlicht am von — Keine Kommentare ↓

Letzten hatten wir einen „Fehler“ bei einem Sicherungsjob, der mehrere brandneue Proxy- und Repository-Server verwendete. Kein anderer Job verwendete die neuen Komponenten.

Trotzdem verarbeitete Veeam nur 4 VMs gleichzeitig; alle anderen hatten den Status „Pending“. Aber die Meldung war ergänzt um diese hilfreiche Aussage:

Resource not ready: Active snapshots limit reached for datastore

Nach kurzer Untersuchung fanden wir heraus, dass sich alle VMs auf einem VVOL befanden. Ein VVOL wird scheinbar wie ein einziges VMFS behandelt und das per-datastore Limit angewendet.

Lösung

Glücklicherweise gibt es eine einfache Lösung für diese Einschränkung. Man kann einen Registrierungsschlüssel auf dem VBR-Server (VBR, nicht Proxy!) erstellen, um das Limit aktiver Snapshots pro Datenspeicher zu erhöhen:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

MaxSnapshotsPerDatastore   REG_DWORD   <Anzahl (dezimal)>

Veeam Repository Firewall Regeln

Veröffentlicht am von — Keine Kommentare ↓

Um einen Veeam-Repository-Server mit der Veeam Infrastruktur zu verbinden, braucht man ein paar Firewall-Regeln. Die sind zum Glück auch hier ganz gut dokumentiert.

Um mir die Arbeit jedesmal aufs neue zu ersparen 🫡 hier eine schnelle Copypasty für die notwendigen Ports.

Repository-Services, Datamover und NFS-Server:

netsh advfirewall firewall add rule name="VEEAM Repository" dir=in action=allow protocol=tcp localport=2500-3300
netsh advfirewall firewall add rule name="VEEAM Datamover" dir=in action=allow protocol=tcp localport=6162
netsh advfirewall firewall add rule name="VEEAM vPower NFS" dir=in action=allow protocol=tcp localport=6161
netsh advfirewall firewall add rule name="VEEAM Backup Proxy" dir=in action=allow protocol=tcp localport=6160

# Nur wenn Veeam-Agenten auf das Repository sollen
netsh advfirewall firewall add rule name="VEEAM Backup Repository-Agents" dir=in action=allow protocol=tcp localport=10001

Daz braucht man dann nur noch 139/445 für das Deployment und Updates (für ein deutsches Windows 2019/2022). Dazu enablen wir einfach die „default“ Regeln und bauen keine zusätzlichen:

netsh advfirewall firewall set rule name="COM+-Netzwerkzugriff (DCOM-In)" new enable=yes
netsh advfirewall firewall set rule name="Datei- und Druckerfreigabe (SMB eingehend)" new enable=yes

Veeam Backup and Replication Logfile Pfade

Veröffentlicht am von — 4 Kommentare ↓

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/