Windows Server Sicherung – allCritical?

Hallo zusammen,

vor kurzem hatte ich die seltsame Situation, dass bei einem Kunden die wbadmin-Sicherung fehlschlug, da sie immer wieder versuchte, das Sicherungslaufwerk (-backupTarget) in die Sicherung mit einzuschließen.

Im Log äußerte es sich folgendermaßen:

wbadmin 1.0 – Sicherungs-Befehlszeilentool
(C) Copyright 2004 Microsoft Corp.

Volumeinformationen werden abgerufen…
Hierdurch wird das Volume „System-reserviert (100.00 MB),DATEN(D:),ARCHIV(E:),Backup(F:),Lokaler Datenträger(C:)“ in „\?\Volume{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}“ gesichert.
Der Sicherungsspeicherort ist ungültig. Ein in die Sicherung einbezogenes Volume kann nicht als Speicherort verwendet werden.

Ausgabe wbadmin – läuft nach einigen Sekunden auf diesen Fehler.

Der Vollständigkeit halber hier noch die Aufrufzeile für wbadmin:

wbadmin start backup -backupTarget:\?\Volume{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} -include:C:,D:,E: -vssfull -quiet -allCritical

Keine Spur von Laufwerk F:\, soweit… Die angegebene Volume-ID als Speicherungsort war jedoch identisch mit der ID des Laufwerks F:\ (Backup), dabei handelte es sich um ein eingebundenes iSCSI Laufwerk einer QNAP-NAS. Um die Volume-ID zu kontrollieren könnt ihr beispielsweise den Befehl „mountvol“ verwenden, oder über die Powershell eine WMI-Abfrage lostreten (Beispiele, und an dieser Stelle vielen Dank an Stackoverflow):

mountvol
[...]
Mögliche Werte für VolumeName mit aktuellen Bereitstellungspunkten:
\\?\Volume{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\     
     *** KEINE BEREITSTELLUNGSPUNKTE *** 
\\?\Volume{BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}\     
     C:\ 
\\?\Volume{CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC}\
     D:\
[...]
Get-WmiObject -Class Win32_Volume | Select Name,DeviceID
Name                                              DeviceID
----                                              --------
\?\Volume{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\  \?\Volume{AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA}\
C:\                                               \?\Volume{BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB}\
D:\                                               \?\Volume{CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC}\

Damit war zwar geklärt, dass es sich tatsächlich um die VolumeID des Backuplaufwerks handelte, aber nicht, warum wbadmin der Meinung war, es müsste mit gesichert werden.

Also muss der Sicherungslauf durch einen Parameter der Meinung sein, das Laufwerk F: sei für ihn relevant. Einige Recherchen zum Verhalten von wbadmin haben leider nur ergeben, dass die Dokumentation bestenfalls sehr knapp, siehe hier und hier (danke, aber nein danke, Microsoft). Da sich mittlerweile herausgestellt hat, dass die VSS-Writer (logischerweise durch -vssfull) ihre Finger im Spiel hatten, landete ich bei den Recherchen auf dieser Technet-Seite, die angeblich erklären soll, wann ein Volume als „critical“ angesehen wird: Technet und Link aus Social.Technet.

Critical volumes, such as the boot, system, and Windows Recovery Environment (Windows RE) volumes and the Windows RE partition that is associated with the instance of Windows Vista or Windows Server 2008 that is currently running. A volume is a critical volume if it contains system state information. The boot and system volumes are included automatically.

Critical Volumes-Auszug aus der oben verlinkten Technet Seite

Ein Volume ist also kritisch, wenn Systemstatusinformationen darauf gespeichert werden. Vielen Dank für das Gespräch. Das BackupTarget-Volume ist in diesem Fall eine leere NTFS-Partition mit genau einem Ordner „WindowsImageBackup“ (und natürlich dem üblichen NTFS-Kram „System Volume Information“ usw…). Auch die Kontrolle über die Datenträgerverwaltung bestätigte mich in der Annahme, dass an dem Volume nichts besonderes hängt. Laufwerk C:\ war die Startpartition, enthielt die Auslagerungsdatei und das Absturzabbild. Die 100 MB-große System-reservierte Partition von Windows hatte hier den Status System, Aktiv. Das Backuplaufwerk wurde „nur“ als Fehlerfrei und primäre Partition angezeigt. Soweit richtig.

Letzten Endes brachte mich der letzte Artikel in diesem Social.Technet Thread auf die richtige Spur (der übrigens 5 Jahre nach der ursprünglichen Diskussion eingefügt wurde…):

Server 2008 has DISKSHADOW command which shows all critical volume details from “list writers detailed” (see http://troubleshootingsql.com/2010/12/06/location-sql-binaries-can-flip-out-bare-metal-backups/).

Zitat vom User V.Sher aus oben verlinktem Beitrag

Über den „list writers detailed“ Befehl innerhalb vom VSS-Tool Diskshadow lassen sich alle relevanten Speicherorte für VSS Schattenkopien auflisten. Die Ausgabe war nach einem Testaufruf aber relativ groß (ca. 25.000 Zeilen), so dass ich mir zu dem Befehl eine Logdatei generieren musste. Leider klappt das nicht so einfach, wie man es von anderen Kommandozeilen gewohnt ist, da Diskshadow die Parameter anscheinend nicht einfach übernimmt, sondern zunächst einmal selbst ohne Parameter gestartet werden möchte, um dann den Befehl „list writers detailed“ ausführen zu können.

Um die Ausgabe in vernünftige Bahnen zu lenken habe ich dann kurzerhand eine Scriptdatei(.ds) angelegt, mit dem einfachen Inhalt „list writers detailed“ und Diskshadow dann folgendermaßen aufgerufen (die Dateinamenserweiterung .ds ist an der Stelle natürlich optional):

diskshadow /s C:\Pfad\zur\Scriptdatei.ds > DiskShadow.log

Damit wird die Ausgabe in die Datei DiskShadow.log umgeleitet, und man kann die Datei bequem mit dem Texteditor seines Vertrauens analysieren. Hierbei stellte sich heraus, dass ein VSS-Writer vom SQL Server aufgrund einer fehlgeschlagenen Installation der Meinung war, er hätte auf dem Laufwerk F:\ noch eine Instanz, die er der Sicherung hinzufügen müsste. Am einfachsten könnt ihr die Datei nach dem Laufwerksbuchstaben durchsuchen, der fälschlicherweise als „allcritical“ oder „systemstate“ markiert wird, und euch dann um die VSS-Writer kümmern, die auf den Pfad zugreifen wollen.

WRITER "System Writer"
[...]
 File List: Pfad = f:\sql\database\mssql12.sqlexpress\mssql\binn, Dateispez. = sqlagent.exe
[...] 
Von dieser Komponente betroffene Pfade:  
[...]
 f:\sql\database\mssql12.sqlexpress\mssql\binn 
[...]
Von dieser Komponente betroffene Volumes:
             - \?\Volume{33a42410-9328-11e2-88a4-806e6f6e6963}\ [C:]
             - \?\Volume{ffca78d8-a5e1-11e6-a19e-00155d640106}\ [F:]

In diesem Fall half die erneute, saubere Deinstallation der SQL-Instanz, ebenso wäre es z.B. denkbar gewesen, dem Backuptarget einen anderen Laufwerksbuchstaben zuzuweisen (die wbadmin-Sicherung bezieht sich in dem Aufrufpfad ja auf die VolumeID, diese bleibt immer gleich, egal welcher Buchstabe dahinter steckt), damit hätten die VSS-Writer den Pfad nicht mehr gefunden, und ihn für die Sicherung vermutlich ignoriert, ich habe es aber nicht selbst getestet.

Ich hoffe, das hilft dem ein oder anderen weiter 🙂

Viele Grüße!
Hannes

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert