Es wurde ja inzwischen schon die Behauptung geäußert, wenn sich überhaupt jemand mit VSS streitet, dann bin ich das. Es sei zudem ein Hobby von mir. Mitnichten, muss ich mitteilen, ich hätte nur gerne die Variante VSS in „funktionierend“. Ein Murmeltierblogpost…
Deswegen schlage ich mich in den unterschiedlichsten Infrastrukturen mit dem Thema VSS herum, ab und zu in Verbindung mit „Windows Server Sicherung“, mal mit DPM, mal mit Altaro. Selten jedoch ist ein solches Thema in Verbindung mit Veeam, da die Herrschaften Veeam eine äußerst intelligente Möglichkeit angestrengt haben, mit solchen „zickigen“ VM’s online umzugehen.
Herausgekommen sind da mehrere Lösungsansätze und Fallstricke. Zuletzt hatte ich sogar über einen Fehlschlag geschrieben, anfänglich sogar über einen Lösungsansatz bei der Behandlung von Scopesnapshots, in jenem man auch gut die Vorraussetzungen für ein generell funktionierendes HyperV – VSS findet. Doch dieser Knaller hier ist ein ganz simpler, der jedoch den meisten Aufwand zur Lösung benötigt hat, dieses Mal musste ich den Microsoft Support zu Rate ziehen.
Zum ersten Mal habe ich dann den (wirklich sehr netten und geduldigen) Microsoft Support auch nach 2 Monaten „ratlos“ gesehen. So etwas hätten sie auch noch nicht gesehen. Es seien ja alle Vorraussetzungen für ein Funktionieren erfüllt.
Dabei ist die Lösung wirklich simpel! In meiner Beobachtung bemerkte ich das Pausieren eines Domänencontrollers während des Backups. Ein wirklich unschöner Vorgang, da ich mit solch einem Verhalten auch gegen die „bewährten Methoden“ verstoße, und einen USN-Rollback provozieren kann. Fast jeder weiß, welcher Terror und Arbeitsaufwand mit einem solchen AD-Szenario verbunden ist. Deswegen sind gespeicherte Hütten für Administratoren per se eine Katastrophe, DC’s ganz besonders.
Wie dem auch sei, die o.g. Punkte habe ich auf der betreffenden Hütte abgearbeitet. Es ist ein Server 2012 Standard Edition Gast, in einer 2008R2 HyperV Umgebung, deaktiviertem Scope-Snapshot. Es müsste eigentlich funktionieren, doch tat es nicht. Die Hütte ging in den gespeicherten. Nichts mit Onlinesicherung.
Eine Überprüfung mittels folgendem
diskshadow > c:\log.txt list writers detailed
brachte im Ergebnis, dass die betreffende Gastmaschine mit nichten mittels „using child partition“ online gesichert wird, sondern „using saved state“. Aber warum nur? Eine Anforderung des Supports war:
1. Make sure you have SCSI Controller installed on both VMs (check this in VM settings).
2. Check if a Shadow Storage assignment of a volume inside the virtual machine is explicitly set to a different volume other than itself.
Erledigt. Die Hütte hat einen SCSI Controller, Shadow Storage Assignment passt. Keine Chance. Selbst der Host wurde überprüft, neu gestartet. Jeder kann sich vorstellen, dass jenes ein unschönes Ereignis ist, insbesondere, wenn in der Kundenumgebung dieses die einzige Hütte ist (KMU, <10 Anwender), welche HyperV und die Produktionsumgebung bereitstellt.
Doch warum ritten die so auf dem SCSI Controller rum. Ich erinnerte mich, in der letzten Zeit lege ich per se nur noch SCSI VHDX an, eigentlich nutze ich IDE gar nicht mehr. Was ist nun mit dem SCSI Controller und wird der überhaupt genutzt? Kurzerhand lege ich eine Test-Festplatte an dem SCSI Controller an, nur um mal zu schaun, vielleicht ist eine einzelne IDE Platte wirklich so problematisch:
Neustart des Gastes, starten von Windows Server Sicherung. Siehe da: Es klappt. WBAdmin hält die Maschine während der Sicherung nicht mehr an.
Lösung: Bei Problemen reicht es nicht zu überprüfen, ob der SCSI Controller vorhanden ist. Es muss explizit darauf geachtet werden, dass der SCSI Controller mindestens eine Festplatte enthält. Die generell verwendete IDE Platte wird dann wie üblich problemlos gesichert. Dieses Szenario wäre also noch ein weiterer Grund, generell und ausschließlich SCSI Controller, sowie adäquate Platten bei der VM-Konfiguration zu verwenden.