Veeam hat seine Availability Suite in der Version 9.5 veröffentlicht. Bereits vor einigen Wochen wurden im Rahmen der VeeamON die neuen Funktionalitäten vorgestellt.

Hauptaugenmerk liegt demnach insbesondere auf der Unterstützung der neuen Funktionalitäten von Microsoft Windows Server 2016 bzw. von Veeam unter dem Oberbegriff „Microsoft 2016“ zusammengefasste Produkte und Features. Hierzu gehören die Unterstützung der aktuellen Versionen von Microsoft Active Directory, Exchange, SharePoint und SQL Server sowie der Nano Server, PowerShell Direct und Storage Spaces Direct (btw: sehr coole, neue Features 🙂 )

Veeam unterstützt Microsofts Storage Spaces Direct und Nano Server in Windows Server 2016

Auch unterstützt die Version 9.5 das neue Hyper-V Backup Framework, wodurch die Abhängigkeit zu VSS-Snapshots entfällt und somit die Performance verbessert. Da Microsoft in der neuesten Hyper-V Version durch Resilient Change Tracking endlich Changed-Block-Tracking unterstützt, entfällt auch die Notwendigkeit des hauseigenen Filtertreibers.

Apropos, wenn Du die Hyper-V Umgebung mit Veeam sichern willst, könnte diese eBook für dich interessant sein: All You Need to Know About Microsoft Windows Server 2016 Virtualization

In Folge von diversen Anwender-Feedback hat das Team eine verbesserte Funktionalität im Zusammenhang mit Microsoft Azure implementiert, sodass nun direkt vom On-Premises Server nach Microsoft Azure wiederhergestellt werden kann.

Restore nach Microsoft Azure

Es gibt mal wieder einige interessante neue Features. Wie schon das eine oder andere Mal geschrieben, ist Veeam wirklich ein klasse Stück Software, dass uns Virtualisierungs-Admins wirklich eine Menge Ärger erspart und ruhig durchschlafen lässt 🙂 In der offiziellen Ankündigung findest Du weitere Informationen zu den Neuerungen.


Veeam Backup & Replication im Enterprise Umfeld hatte ich schon ein paar Mal erwähnt. Nach wie vor echt klasse diese Software. Kürzlich war ich auf aber eine Problematik gestoßen, die mich einige Stunden Suche gekostet haben.

Was war passiert? Auf sämtlichen virtuellen Maschinen, die eine oder mehrere Microsoft SQL Server Instanzen halten, erfolgt eine periodische Sicherung der Transaktionsprotokolle. Dies klappt normalerweise auf Anhieb, wenn die entsprechenden Einstellungen gesetzt sind:

  • Wiederherstellungsmodell (Recovery Model) in den Eigenschaften der Datenbank auf „Vollständig“ („Full“) setzen

    Wiederherstellungsmodell in den Datenbank-Eigenschaften

  • Im Veeam B&R Job die Option „Enable application-aware processing“ aktivieren und entsprechenden SQL-Einstellungen setzen

    Veeam Backup & Replication: Sicherung von Transaktionsprotokollen

Dennoch wurde die Datenbank auf einem Server nicht korrekt gesichert. Folglich wuchs das Transaktionsprotokoll (LDF-Datei) massiv an, erreichte einige Gigabyte und ließ die Partition langsam, aber sicher volllaufen.

Hätte ich das Protokoll vom Veeam etwas aufmerksamer gelesen, wäre ich vielleicht sogar schneller auf die Ursache gestoßen 🙄  Dennoch, eine fehlgeschlagene Sicherung wurde nie gemeldet, sodass ich mir zunächst nichts dabei gedacht habe. Bis ich dann auf folgende Zeile aufmerksam wurde: „Skipping AutoClose databases: XXXX“

Veeam Backup & Replication: Skipping AutoClose databases Meldung

Was hat es damit auf sich? Ich muss zugeben, AutoClose ist eine Option, auf die ich vorher nicht sonderlich geachtet habe. Standardmäßig ist diese Option bei einer SQL-Datenbank eigentlich deaktiviert. AutoClose ist ein Überbleibsel aus grauer Vorzeit und von Microsoft wird schon seit Jahren die Deaktivierung empfohlen.

Problematische Einstellung: AutoClose

Normalerweise soll die Einstellung sicherstellen, dass der SQL Server sämtliche beanspruchten Ressourcen (Speicher, CPU, I/O etc.) wieder freigibt, sobald die letzte User-Session getrennt worden ist. Nun kann es aber passieren, dass sich der letzte User für ein paar Sekunden (oder Zehntel Sekunden) abmeldet, dann aber sofort wieder anmeldet. Dennoch werden die Ressourcen freigegeben und sofort wieder beansprucht. Folglich kann dieser vermeintlich gut gemeinte Vorgang das System deutlich verlangsamen. Weitere Informationen zu der AutoClose-Funktion könnt ihr bei SQL Server Pro und Microsoft nachlesen.

Genau an dieser Einstellung stört sich auch Veeam und überspringt entsprechende Datenbanken. Nach Rücksprache mit dem Software-Hersteller, welcher die Datenbank für seine Software verwendet, bestand aber kein Grund, diese Option aufrecht zu erhalten. Folglich konnte ich AutoClose wieder auf False setzen und Veeam sichert nun ohne Probleme die Datenbank 🙂

 


Neulich stellten wir auf einigen Servern fest, dass es Probleme mit MSI-Installern beim Aktualisieren oder Deinstallieren gab (u. a. erhielt man den MSI Fehler 1719 – „Auf den Windows Installer-Dienst konnte nicht zugegriffen werden“) . Das Problem trat unabhängig auf verschiedenen Windows Server 2012 R2 Servern auf, die unterschiedliche Applikationen betrieben.

Nach einiger Recherche in den Systemen konnte der Schuldige ausgemacht werden: KB3139923, welches kürzlich installiert wurde und zu welchem sich zu diesem Zeitpunkt keine negativen Aussagen im Web finden ließen, war für die Probleme verantwortlich. Nach der Deinstallation des Patches. Eigentlich sollte KB3139923 Probleme mit MSI-Installern beheben, in diesem Fall verursachte es welche, die es vorher nicht gab.   🙄

Im TechNet-Forum gibt es diesbezüglich inzwischen auch einen Thread. Hier wird ferner vermutet, das Problem von KB3139923 trete bei fehlendem KB3072630 auf. Den Zusammenhang muss ich nochmal nachprüfen, zumal über KB3072630 aber auch diverse negative Anmerkungen im Web zu finden sind.


Sicherlich habt ihr auch die Schlagzeilen über die jüngste Ransomware Locky gelesen. Cryptolocker und Teslacrypt, die Pest. Locky anscheinend noch schlimmer. Wie viele andere nistet sich Locky auf dem Client ein, schaut aber auch noch links und rechts, was es so auf Dateiservern im Firmennetzwerk verschlüsseln kann. Nahezu jeder Anwender dürfte Zugriff auf entsprechende Projekt- oder Abteilungslaufwerke haben und schon nimmt das Unheil seinen Lauf. Auch wenn sich hoffentlich relativ zügig Backups einspielen lassen und der oder die verseuchten Clients aus dem Netzwerk entfernen lassen, heißt es erstmal wieder extra Stunden investieren.

Weiterlesen