Bei der Auseinandersetzung mit dem Thema, Windows-Systeme mittels Networker-NMM - also der konsequent auf VSS-Snapshots basierenden Sicherung via Networker - zu sichern, bin ich auf die Aussage gestoßen, dass die in den Windows-Servern implementierte VSS-Unterstützung stets zuerst eventuell vorhandene VSS-Hardware-Provider zu nutzen versucht und bei Notwendigkeit anschließend den Microsoft Software Shadow Copy Provider mit der Erstellung des Snapshots beauftragt. Nun gut, eine Regelung muss es ja geben. Sinnvoll ist sie außerdem: erst mal versuchen, zu delegieren, dann doch selber machen ...

Auf die Konsequenzen aus diesem Verhalten wurde ich kürzlich aufmerksam: Ein Zwei-Node MSCS-Activ-Activ-Cluster (Windows 2003) nutzt per SnapDrive den Storage einer NetApp. Für die in den virtuellen Servern installierte (und nicht weit verbreitete) Applikation gibt es keinen SnapManager, der beim Backup Unterstützung liefert. Die Betreiber des Clusters waren beunruhigt über Fehlermeldungen des Servers, die auf massive Probleme des Volume Shadow Copy Service (VSS) hinwiesen. Außerdem würden in unregelmäßigen Abständen Laufwerke an den Clusternodes angezeigt, deren Herkunft sich niemand erklären konnte. Wichtig war der Hinweis, dass beide Phänomene im zeitlichen Zusammenhang mit der nächtlich ausgeführten Networker-Sicherung zu stehen scheinen.

Apropos NetWorker Sicherung, wie würde ich vorgehen?
Nun, ich würde in diesem Fall die auf shared LUNs abgelegten Daten aus dem letzten (oder einem anderen) Snapshots des Volumes, in dem die LUN liegt, per SnapDrive zugänglich machen, die NetWorker-Sicherung ausführen und anschließend den Clone der LUN wieder entfernen. Also die Networker-Sicherung mit vor- und nachgeschalteten Befehlen "abrunden".

Aber das Vorhandensein eines NetWorker-Savesets "ALL" ist wohl zu verlockend: es kümmert sich um alles und wird es schon richten. Das dies spätestens beim Einsatz des vom Konzept her genialen NMM überhaupt nicht mehr funktioniert, habe ich in einem früheren Beitrag bereits dargelegt. Die Nodes des MSCS waren beide für die Sicherung per Saveset ALL eingerichtet, wobei die durch die virtuellen Server genutzen Laufwerke sowie die Quorum-Disk aus der Sicherung ausgeschlossen wurden oder ausgeschlossen werden sollten.

Gesichert werden sollte also nicht ALL, sondern der "Systemstate" und die Dateien des Betriebssytemlaufwerkes (C:\). Eine in diesem Umfang testhalber ausgeführte Sicherung war die erste auf diesen Systemen überhaupt, die völlig ohne Warnungen oder gar Fehler ausgeführt werden konnte.

Was war also passiert: Der Networker beauftragt seinen Client, doch erst mal das System klar zu machen dafür, "ALL"es zu sichern, denn später kann er ja immer noch darauf verzichten, auch alle Daten "abzuholen".

Da standardmäßig der für Datenkonsistenz  sorgende Weg über VSS-Backups gegangen wird, geht der Auftrag an alle VSS-Writer raus, die VSS-Sicherung "auf breiter Front" (Saveset ALL !) vorzubereiten, was von diesen auch problemlos quittiert werden kann. Nun sind die VSS-Provider an der Reihe, die Snapshots zu erstellen: der in SnapDrive implementierte NetApp-VSS-Hardwareprovider zuerst, dann der Microsoft-Software-Provider.

Und SnapDrive reagiert so, wie es von SnapDrive erwartet wird: von allen angeschlossenen LUNs wird ein Snapshot erstellt. Stimmt natürlich nicht: das Snapshot wird jeweils von dem Volume erstellt, in dem sich die LUN befindet. Und um sicherzugehen, dass das auch funktioniert hat, prüft SnapDrive den Zugiff auf die LUN im gerade erstellten Snapshot und greift kurzzeitig auf eine *.rws - LUN zu. Diese Snapshots werden aber gar nicht benötigt, da die LUN-Inhalte ja extra "excluded" wurden. Jetzt haben wir ein Snapshot, dass keiner haben wollte und niemend braucht - und fast zeitgleich legt der Software-Provider los, und will nun seinerseits von "ALL"em Datenbestand eine Schattenkopie anlegen; mitunter wohl auch von der zwecks Test nur kurzzeitig gemounteten LUN im Snapshot (die im nächsten Moment aber schon wieder "weg" sein kann, wenn dann die Daten abgeholt werden könnten). Fallen diese Zugriffe zeitlich "unglücklich" zusammen, dann sorgt der Zugriff auf die temporäre LUN dafür, dass SnapDrive diese nicht wieder entfernen kann. Damit sind sowohl die sporadisch "aus dem Nichts" auftauchenden Disks als auch die massiven Probleme im VSS-Bereich erklärt.

Die von mir oben beschriebene Methode für das Networker-Backup aus dem letzten Snapshot heraus werde ich die nächsten Tage einrichten und damit für ein System sorgen, in dessen Ereignisanzeige weder gelbe noch rote Hinweise auftauchen.

Nach und nach gibt es immer mehr Situationen, in denen Networker-Saveset ALL nicht eingesetzt werden kann: bereiten wir uns auf den Abschied vom Networker Saveset ALL vor !