Es ist kein Geheimnis, das Drive Snapshot zu meinen Lieblingen gehört. Bislang habe ich noch keine zuverlässigere und stressfreiere Datensicherungslösung kennengelernt. Aber leider ist das gute Stück nicht all zu bekannt, das ist zumindest mein Eindruck. Jeder kennt Acronis, BackupExec (Symantec, früher Veritas) und immer mehr kennen StorageCraft, BackupAssist, usw.

WICHTIG: Wer Server-Eye mit Drive Snapshot (oder umgekehrt ;-)) einsetzt, sollte den Beitrag bis zum Ende lesen! Vor allem dann, wenn meine Skripte (z.B. Rotationssicherung) zum Einsatz kommen.

Umso überraschter war ich, als ich einen Sensor bei Server-Eye für Drive Snapshot entdeckt habe. Bislang haben wir das so gehandhabt, das auf jeden Fall ein Log geschrieben wird und ggf. eine E-Mail entweder mit dem aktuellen Log oder der Auswertung des Errorlevels (getreu dem Motto “Ok oder nicht Ok”) versendet wird.

Mit Hilfe von Server-Eye können wir nun aber auch das an zentraler Stelle überwachen.

Der Sensor findet sich in der Kategorie “Backup”. Beim Anlegen des Sensors wird man nach dem Pfad und dem Dateinamen des Logs gefragt, an welchen Tagen und zu welcher Uhrzeit das Backup laufen sollte. Auch die maximale Dauer kann angegeben werden. Letzteres kann Hinweise darauf liefern, ob mit der Performance des zu sichernden Systems oder des Ziels etwas nicht stimmt oder ungewöhnlich viele Daten hinzugekommen sind.

Für etwas Verwirrung sorgte bei mir diese Angabe im Sensor: “Es ist die Log-Datei gemeint, die bei jedem Backup-Vorgang neu geschrieben wird und den Status des Backups enthält.”

Von Haus aus schreibt Drive Snapshot kein Log. Nun gibt es zwei Möglichkeiten:

1. Über den Parameter “–LogFile:DATEINAME” eine Log-Datei festlegen oder
2. via Skript “snapshot.exe C: …. > DATEINAME” die Ausgabe in eine Datei umleiten.

Ersteres hat den Vor- oder Nachteil, je nachdem wie man es sehen möchte, das an diese Datei die aktuellen Meldungen angehängt werden. Dieses Log kann dann sehr schnell unübersichtlich und “relativ” groß werden. Und “bei jedem Backup-Vorgang” neu geschrieben” haut dann ebenfalls nicht hin.

Bei der zweiten Möglichkeit, die ich in der Regel in den Skripten einsetze, entscheidet das Umleitungszeichen darüber, ob angehängt wird oder nicht. D.h.:

• > Erstellt eine neue bzw. Überschreibt eine vorhandene Datei.
• >> Hängt an eine Datei an oder erstellt Sie neu, sofern Sie noch nicht vorhanden ist.

Da der Server-Eye Sensor einen fest vorgegebenen Dateinamen benötigt, kann man sich überlegen, das man bei jedem Backup die Log-Datei überschreibt. Das birgt allerdings das Risiko, das man keinen Verlauf von Ereignissen mehr hat, was sich im Problemfall als ungünstig erweisen könnte.

Da kam dann der Gedanke auf, das beispielsweise so zu lösen:

snapshot.exe C: ... > current.log
copy current.log %date%.log

Via Umleitung wird ein aktuelles Log geschrieben und mittels copy wird Dieses dann mit dem aktuellen Datum versehen umkopiert. Dadurch hat man einmal das Log das der Sensor “abgrasen” kann und eines sozusagen für’s Archiv.

Verwirrung II

Für noch mehr Verwirrung oder eher Verunsicherung sorgt(e) der Umstand, das im Test ein Log herhalten musste, das einen Abbruch des Backups durch den Benutzer als auch ein erfolgreiches Backup enthält.

Das kam aber möglicherweise nur dadurch zustande, das der Abbruch an einem Tag erfolgte und das erfolgreiche Backup am Nächsten.

Zunächst schien es so, als prüfe der Sensor nur die Ereignisse an einem Tag. Ein weiterer Test, bei dem sowohl ein abgebrochenes als auch ein erfolgreiches Backup am gleichen Tag in einem Log stehen, lieferte allerdings ebenso ein “OK” zurück.

TILT

Weitere Tests lieferten dann nur noch ein

"ERROR|Es konnte kein Backup gelesen werden|"

zurück. Damit war dann die Verwirrung komplett. Also kurzerhand den Support kontaktiert. Dort teilte man mit, das der Sensor von einem weiteren Partner erstellt wurde, was soweit nichts ungewöhnliches oder gar schlimmes ist. Der Sensor sucht nach der Zeichenfolge

"start of snapshot"

Ich kann jetzt gar nicht sagen, ob ich das je so in einem Log von Drive Snapshot gelesen habe. Man schaut ja immer nur rein, ob alles ok ist. Sofern kein “Error”, “Abort” oder “Warning” auftaucht oder einem der Errorlevel etwas anderes erzählt ist ja in der Regel in alles Ordnung.

Jedenfalls kommt der Fehler schlicht dadurch zustande, wie das Log geschrieben wird. Wie eingangs erwähnt hat man zwei Möglichkeiten, den Parameter “–LogFile:” oder die Umleitung (Pipe). Und da ist der Haken: Wird “–LogFile:” verwendet, beginnen die Logs bzw. die Einträge des jeweiligen Backup-Vorgangs mit “start of snapshot”, bei der Umleitung nicht. Kurz gesagt, diese vier Zeilen fehlen bei der Umleitung:

00:26:21 Start of Snapshot 1.42 [May 13 2013] at 23.05.2013
00:26:21 Running on Windows Server 2008 R2 Small Business Server 64-bit (7600)
00:26:21 Memory Info: Total: 4095Mb, Free: 400Mb, Pagefile total: 11908Mb, Pagefile free: 2832Mb
00:26:21 Command line: snapshot.exe C: D:\Backup\$DISK.sna -L160000 -RW --LogFile:C:\Backup\$DATE.txt

Vergleicht man zwei Logs, die über die unterschiedlichen Möglichkeiten erstellt wurden, dann stellt man fest, das erst ab Zeile 5 sich Diese weitgehend gleichen. Aber dennoch gibt es weitere, wenn auch kleinere Unterschiede:

Mit anderen Worten: Das was ins Log geschrieben wird und das was auf der Konsole (für die Umleitung) angezeigt wird, unterscheidet sich geringfügig.

Kurz und knapp: Kleine Ursache, große Wirkung.

Das führt dann zu der Erkenntnis, das man seine (und das gilt nun auch für meine) Skripte unter Umständen anpassen darf bzw. muss. Wieder mit dem Hintergedanken, das man ja kein “Endlos-Log” haben möchte das unübersichtlich und “ewig” groß wird. Aufgrund des neuen Wissens wird dann ebenfalls schnell klar, das der weiter oben genannte “work-around” für den “statischen” Log-Namen, der für den Sensor relevant ist, so nicht funktioniert. Also muss eine andere Lösung her:

snapshot.exe C: ... --LogFile:current.log
copy current.log %date%.log

Also zunächst die Umleitung durch den Parameter “–LogFile:” ersetzen. Der copy-Befehl kann quasi so bleiben. Der Einsatz vom move-Befehl ist hingegen nicht ratsam, da man das current.log für den Sensor stehen lassen muss.

Am Beispiel meines Rotationssicherungs-Skript bedeutet das (grob angerissen) folgende Änderungen:

Damit nicht an das vorhandene Log angehängt wird, muss Dieses zunächst gelöscht werden. Also vor den “snapshot.exe”-Blöcken folgenden Befehl einfügen:

del %LogDir%\current.log /q

Dann müssen folgende Änderungen durchgeführt werden:

> %LogDir%\%Week%-%Weekday%.txt

und

>> %LogDir%\%Week%-%Weekday%.txt

durch

--LogFile:%LogDir%\current.log

ersetzen. Nach den “snapshot.exe”-Blöcken (Nicht nach jedem snapshot-Befehl, in den Abschnitten der vollständigen und differentiellen Sicherung) folgenden Befehl einfügen:

copy %LogDir%\current.log %LogDir%\%Week%-%Weekday%.txt /y

Das ist nun, wie erwähnt, grob angerissen. Eine neue Version des Skripts ist in Arbeit. Eine aktualisierte Version des Skripts findet sich hier.

Und so kann das dann in Server-Eye, im Guten wie im Bösen, aussehen:

Plan B

Es gibt gewissermaßen einen zweiten Weg, den man auch gehen kann. Mittels des Sensors “Log-Datei Ordnerüberwachung” (Dieser findet sich in der Kategorie “Logdateien”) kann man einen Ordner mit Log-Dateien auf ein Suchwort hin überwachen. Und zwar in der Art, das bei neu erstellten oder geänderten Dateien ein bestimmtes Wort auftauchen muss, damit es keinen Alarm gibt!

Das wäre dann in diesem Falle, wenn man die Umleitung und nicht den Parameter “–LogFile:” für Drive Snapshot verwendet:

Snapshot finished successfully

Update 12.06.2013

Wie ich per E-Mail erfahren habe, wird der Sensor komplett neu geschrieben. Anscheinend bin ich mit meinem Feedback da nicht ganz “unschuldig” daran. Ich sah da zuletzt kein Problem darin, wie es ist. Allerdings weiß ich auch nicht, wie es hinter den Kulissen aussieht.

Im übrigen meinte Tom Ehlert Software, der Hersteller von Drive Snapshot, das Sie kein Problem darin sehen, das die Konsolen- und Log-Ausgabe sich unterscheiden. Das ist ebenfalls nachvollziehbar, wenn auch dank des noch aktuellen Sensors von Server-Eye und der Art, wie man die Logs schreiben lässt, das durchaus zu Fehlalarmen führen kann.

Update 20.11.2013

Durch einen Fehlerfall bei einem Kunden bin ich darüber gestolpert, das der Server-Eye Sensor scheinbar nur auf die erste Erfolgs- bzw. -Fehlermeldung reagiert. So zeigte Server-Eye keinen Fehler bzw. “Backup erfolgreich abgeschlossen” an, obwohl das nur für die erste (und erfolgreich) gesicherte Partition galt.

Konkret ist es bei diesem Kunden so, das ein Windows Small Business Server 2011 Standard gesichert wird. Die Partitionsstruktur sieht dabei wie folgt aus:

1. Partition: Windows Boot (System-reserviert), unter Drive Snapshot als HD1:1 bzw. HD1-1 dargestellt.
2. Partition: System (C:)
3. Partition: Daten (D:)

Dabei kommt das Skript aus dem Beitrag Windows: Rotationssicherung mit Drive Snapshot – Version 3.0 zum Einsatz.

Drive Snapshot konnte HD1:1 erfolgreich sichern, aber ab Partition C: gab es Probleme. Der Server-Eye Support wurde entsprechend kontaktiert und man ist sich der Sache, das der Sensor überarbeitet werden soll, bewusst. Unsererseits wurde entsprechende Zusammenarbeit (Teststellung einer VM mit Drive Snapshot, Abklärung der Szenarien) angeboten. Sobald es etwas neues gibt, werde ich berichten.

Update 19.09.2014

Da die neue Version des Drive Snapshot-Sensor noch etwas auf sich Warten lässt, anbei ein workaround, wie trotz der Sicherung von mehreren Laufwerken bzw. Partitionen man im Fehlerfall via Server-Eye einen Alarm erhält.

Im Fehlerfall erstellt Drive Snapshot eine Datei mit dem Namen “snapshot_error.log” im gleichen Ordner in dem sich die “snapshot.exe” befindet. Das bloße vorhanden sein dieser Datei weißt schon auf ein Problem hin. Daraus ergibt sich, das man über den Sensor “Datei Existenz” eine Alarmierung regeln kann.

Im Test “zickte” der Sensor ein wenig, erst nachdem man einmalig von “Datei soll existieren” und wieder zurück gewechselt hatte, klappte die richtige Erkennung. Mit anderen Worten: Bei “Soll existieren” muss “false” stehen. Das ergibt sich erst dann, wenn man die Checkbox mal aktiviert hatte.

Der Drive Snapshot-Sensor macht dennoch Sinn, um mitzubekommen, ob das Backup überhaupt oder zum richtigen Zeitpunkt gelaufen ist.

Update 05.07.2016

Es passiert was: Es soll einen neuen Sensor geben (siehe dazu auch die Kommentare), damit dieser funktioniert, muss das Drive Snapshot-Skript über Erfolg oder Misserfolg einen Eintrag ins Anwendungs-Ereignisprotokoll schreiben.

Siehe dazu den Beitrag Server-Eye, Drive Snapshot und Einträge ins Ereignisprotokoll – Ideen und Umfrage

Update 06.10.2016

Wie man im aktuellen Changelog (Server-Eye Changelog Quartal 3/2016) nachlesen kann, befindet sich der neue Sensor im Beta-Stadium und kann nun von allen getestet werden.