vSphere erzeugt beim Snapshots-Erstellen NTFS-Fehler auf Windows-Servern (Event 50/57/137 …)

Problem

ntfs-fehler-event-55Das Erstellen eines oder mehrere Snapshots, zum Beispiel durch Backupsoftware (Veeam, R2Data, Tivoli …) erzeugt Fehler und Warnungen im Eventlog des Windows-Servers:

  • ID 50 NTFS Warning, delayed write failed / delayed write lost
  • ID 55 NTFS Fehler, In der Dateisystemstruktur wurde eine Fehler erkannt
  • ID 57 NTFS Warning, failed to flush data to the transaction log. Courruption may occur.
  • ID 137, NTFS Error, The default transaction resource manager on volume [] encountered a non-retryable error
  • ID 140, NTFS Warning, failed to flush data to the transaction log. Courruption may occur in VolumeID:
  • ID 12289 VSS Error, Volume Shadow Copy Service error: Unexpected error DeviceIOControl

Je nach Umstand können sogar echte Daten verloren gehen (unter Umständen sogar eine korrupte Datenbank). Die vmware-Version (vSphere 4/5/6, vRealize …) ist dabei irrelevant.

Lösung

Der Fehler liegt eigentlich am Windows Server und ist Microsoft bekannt (http://kb.vmware.com/kb/20068499). Eine Hotfix-Lösung gibt es leider (noch) nicht, aber bevor man mit defekten Daten hantiert und diese am Ende noch kaputt sichert, sollte man bei den betroffenen Systemen auf die quiescence verzichten:

  • Config-Datei für die vmware Tools bearbeiten (oder erstellen, wenn nicht vorhanden)
    C:\ProgramData\VMware\VMware Tools\Tools.conf
  • Diese Zeilen einfügen:
    [vmbackup]
    vss.disableAppQuiescing = true
    
  • Dann den vmware Tools-Dienst neu starten

Und schon laufen externe Snapshots ohne Quiescence auf diesem System. Hoffentlich wird das bald gefixt …

Veeam B&R: „Post-job script terminated with exit code 3“

Problem

veeam-post-job-script-exit-3In den Backup-Reports und in der Statusübersicht sind verschiedene Veeam-Sicherungen mit Post-Job Batch-Scripts mit „Warning“ markiert, obwohl der Job korrekt gelaufen ist. Das schreint ebenso für das Script zu gelten, es sind keine Fehler feststellbar.

Lösung

Veeam B&R wertet den Rückgabecode („ERRORLEVEL„) des Scripts aus. Alle Statuscodes außer „0“ werden als Warning im Bericht aufgeführt. Am einfachsten ergänzt man sein Script um einen exit mit dem code 0:

...
echo Done with hypercomplicated batch script.
exit 0

Veeam v8 „Post-job script timed out“

Problem

Seit dem Update auf Veeam v8 läuft die Sicherung von virtuellen Maschinen zwar fehlerfrei („SUCCESS“) durch, trotzdem erhält der Job am Ende aber den Status „Warning“. Grund ist die Meldung „Post-job script timed out“.

veeam-post-job-timeoutLösung

In v8 wurde ein Timeout eingeführt, das nach 15 Minuten für Scripts die nach der Sicherung abläuft. Die zeit ist reichlich knapp bemessen. Das Timeout lässt sich in der Registry zum Glück ändern:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

Einen REG_DWORD (32bit) Wert „PostJobScriptTimeoutSec“ hinzufügen und das Timeout in Sekunden angeben. Beispiel für fünf (5) Stunden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication]
"PostJobScriptTimeoutSec"=dword:00004650

Nach der Änderung müssen die Backup-Services neu gestartet werden.

NetAPP FAS schreibt sehr langsam Veeam reversed-incremental Backup-Jobs

Problem

Mit Veeam Backup and Replication geschriebene Sicherung von von virtuellen Maschinen (vmware oder Hyper-V) sind sehr langsam, wenn diese Faktoren zusammenkommen:

  • NetAPP Storage via CIFS
  • Sicherung im Reversed-Incremental Modus
  • Veeam B&R 6 oder 7

Lösung

Die CIFS-Sitzungsdaten in NetAPP Filern sind im Auslieferzustand für Windows 2000, IIS6 und SQL Server 2000 konfiguriert und lassen viele performancekritische Optimierungsmöglichkeiten vermissen, die Veeam nutzt.

Diese Einstellungen haben sich als „best practice“ erwiesen:

options cifs.max_mpx 1124
options cifs.tcp_window_size 2096560
options cifs.neg_buf_size 65535
options raid.mirror_read_plex_pref alternate

Veeam VMWare Backup Job „File is locked by running session (Jobname)“

Wenn man eine Veeam Backup-Server im falschen Moment (=mitten im Job) neu startet oder der Prozess sich mal unglücklich aufhängt, lässt sich ein Job schon mal nicht neu starten.

Man kann natürlich das SQL Management Studio Express installieren, man kann als fauler Admin aber auch auf dem binntools Verzeichnis das SQLCMD für die Reparatur nutzen:

sqlcmd -s SERVERNAME -Q "EXEC sp_databases;" 
  • Datenbanknamen holen, falls unbekannt
sqlcmd -s SERVERNAME -d "VeeamBackup" -Q "delete from [Backup.TrackedActions.LockItems]"

sqlcmd -s SERVERNAME -d "VeeamBackup" -Q "delete from [Backup.TrackedActions.Locks]"

sqlcmd -s SERVERNAME -d "VeeamBackup" -Q "delete from [Backup.TrackedActions.Locks]" 

Wenn der SQL Server im ersten Moment die Verbindung verweigert, muss die Remote-Verbindung erst zugelassen werden. Das geht im SQL-Server-Configuration-Manager; hier unter den Netzwerkprotokollen die NamedPipes aktivieren und in der Instanz die Netzwerkverbindungen auf „enable“ setzen. Es gibt auch einen Veeam-KB-Artikel dazu.

Veeam: „Host with uuid ‚xxxx-xxxx-xxx‘ was not found“ nach Hostupdate (oder Hardwareänderung)

Bei einem vSphere Update bekommt der jeweilige Host eine neue UUID. Das ist auch vollkommen korrekt so. Veeam verwaltet aber seine Lizenzen nach diesen UUIDs, was nach einer Hostupdate zu der irreführenden Fehlermeldung führt:

Veeam: "Host with uuid 'xxxx-xxxx-xxx' was not found"

Lösung: Zurücksetzen der Veeam-Lizenzen für den passenden Host.veeam_lizenzen_zuruecksetzen

  1. Dash -> Help -> License Information
  2. Licensed Hosts
  3. Host auswählen und „revoken“

 

 

Beim nächsten Backup (oder Replikation) werden die freien Lizenzen wieder neu vergeben.

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) konnte man über das Hilfe-Menü diese Logfiles schnell und einfach 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. Komplett 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
  • Linux:
    /var/log/VeeamBackup/