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:
- Über den Parameter “–LogFile:DATEINAME” eine Log-Datei festlegen oder
- 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:
- Partition: Windows Boot (System-reserviert), unter Drive Snapshot als HD1:1 bzw. HD1-1 dargestellt.
- Partition: System (C:)
- 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.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Hi Andy,
sehr cooler Blog und sehr gute Berichte.
Ich bin auch ein großer Fan von Drive Snapshot. Einfach ein tolles einfaches und zuverlässiges Programm.
Ich bin durch deinen Bericht auf Server-Eye aufmerksam geworden. Wir setzen zur Zeit GFIMAX ein. Ist ein bißchen überladen und auch nicht richtig günstig. Ich wollte einmal wissen wie bist du mit Server-Eye zu frieden? Setzen du es bei vielen Servern ein und welche Sensoren sind deine wichtigsten?
Danke und Gruss
Peter
Hallo Peter,
GFI MAX kenn ich auch, vor allem in der gehosteten Lösung bzw. Distribution durch Acmeo.
Man muss die beiden Produkte “ein wenig” voneinander abgrenzen, da GFI MAX nicht nur Monitoring, sondern auch Fernzugriff und Patch-/Software-Management bietet (zumindest war das vor > 3 Jahre so, habe es seitdem nicht mehr gesehen).
Server-Eye ist eine reine Monitoring-Lösung. Im Gegensatz zu GFI MAX finde ich persönlich es wesentlich einfacher in der Handhabung als auch übersichtlicher und unterm Strich, zumindest bei uns ist es so, auch stressfreier.
Der Support reagiert schnell und beantwortet alle Fragen, ferner ist der Kontakt generell gut.
Regelmässig wird man befragt, ob alles in Ordnung sei und man zufrieden ist. Kurzum: Der Hersteller kümmert sich um einen.
Folglich kann ich sagen, das ich sehr zufrieden bin. Ob es für einen die richtige Lösung ist, muss man nicht zuletzt davon abhängig machen, was man überwachen möchte.
Das lässt sich im Vorfeld alles testen, dürfte also kein Problem sein.
Wir setzen Server-Eye bei allen Kunden mit Wartungsvereinbarung ein, das fängt dann beim Handwerker mit einem PC an und Endet beim Unternehmsnetzwerk im Mittelstand.
Die wichtigsten Sensoren sind für uns Großteils die Windows-relevanten, als auch Securepoint UTM, RAID-Controller und G Data.
Hallo Andy,
ich zerbreche mir bereits den ganzen Tag den Kopf.
Ich setze ebenfalls SE ein und schließe mich deiner Meinung vollständig an.
Allerdings bin ich mit deinem Workaround und dem Sensor der Verzweiflung nahe.
Es funktioniert einfach nicht.
Ich halte im Log nun immer 2 Dateien vor (ist das richtig so?)
Der Sensor meldet mir ständig den Fehler das er die Logdatei nicht findet.
Dies obwohl ich exakt dein Script verwende und auch alle anderen DInge angepasst habe.
Zusätzlich dazu, wie soll der Sensor die Tage auslesen? Also ich möchte täglich sichern und stelle das auch im Sensor ein (Mo,Di,Mi,…….) Auch da kam die Meldung das da was nicht stimmt.
Gibt es da schon neue Erkentnisse?
Seitens Server-Eye scheint sich bislang nicht weiter am DS-Sensor getan zu haben.
Wir setzen von daher seit langem auf den workaround, das schlicht nur auf das Vorhandensein der Error-Datei geprüft wird (siehe Update 19.09.2014).
Alles andere hat bislang für uns nicht oder nicht zufriedenstellend funktioniert.
Ganz glücklich mit ich mit dieser Lösung nicht, da man nun nicht sieht, wann oder ob überhaupt das Backup gelaufen ist.
Auf der anderen Seite muss ich allerdings auch sagen, das die Aufgabenplanung von Windows (ab 2000) schon sehr robust ist und mich bislang nicht im Sitch gelassen hat.
Hallo Andy,
vielen Dank für die vielen Updates und Aktualisierungen zu dem Thema.
Ich hatte gerade heute nochmal ein Gespräch mit dem Support bei Drive-Snapshot und wir werden alles tun dieses Jahr eine neue Version herauszubringen.
Es gibt da mehrere Ansätze, die uns gegeben wurden und die werden wir nun evaluieren welche die beste im Sinne des Sensors ist.
Aber was auf jeden Fall funktionieren sollte, wäre der Weg über den EventLog zu gehen. Dazu müsste man im Skript einen kleinen Teil hinzufügen (ähnlich deiner E-Mail Komponente) und wir könnten die Daten darüber viel besser auswerten. Das ist dann auch unabhängig davon wie die snapshot.exe aufgerufen wird.
Wenn du möchtest kann ich dich hier auf dem aktuellen Stand halten 🙂
Grüße Patrick (vom Server-Eye Team)
Hallo Patrick,
danke für die Rückmeldung, da bin ich ja mal gespannt.
Wir setzen auch die Kombi Server-Eye / Drivesnapshot ein. Mittlerweile bei einigen Kunden und es werden mehr!
Die Überwachung läuft derzeit ganz ordentlich. Ein Problem tut sich allerdings nun vermehrt auf! Bei der Rotationssicherung kommt (warum auch immer) die Meldung das das Image (diff) bereits vorhanden sei und das BAckup bricht ab. Eine Idee? Wir verwenden das Script 3.1 eigentlich unverändert (für 1 oder 2 Wochen)!
Hallo Martin,
das ist seltsam, bei uns und unseren Kunden taucht dieses Phänomen nicht auf.
Man könnte abr leicht eine Änderung einbauen, das zuerst das alte Backup gelöscht wird, bevor gesichert wird.
Ich vermute es liegt an dem Tag der Vollsicherung im Script.
Wenn ich eine Vollsicherung am Samstag haben möchte setze ich das im Script auch ein! Starte ich den ersten Job dann an einem Mittwoch erstellt das Scrip ja die HSH Dateien mit dem Namen Full-1-Saturday-c.hsh. Das nächste Backup ist dann eine Diff-1-Wednesday-c.sna obwohl es dann eigentlich ein Full Backup ist. Kann da das Problem liegen? Ich hänge mal die original Meldung aus dem Log an:
18:00:19 Command line: snapshot.exe C:+D:+G:+H: \192.168.0.242backup_zielSnapshotZielDiff-1-Monday-$disk.sna -h\192.168.0.242backup_zielSnapshotzielFull-1-Thursday-$disk.hsh -RW –USeVSS -L0 –LogFile:C:BackupLogsCurrent.log –FullIfHashIsMissing
18:00:24 The names of the differential and original image are identical.
Please choose a different image name.
Sollte eigentlich gehen, die Meldung hatte ich allerdings auch schon mal, komme aber gerade nicht drauf, was da los war.
Alternativ mal die Variable Weekday auf den Tag der Vollsicherung setzen (Zeile 42, “REM SET Weekday=Monday”, das REM weg und den Tag anpassen) und das Vollbackup ausführen, danach die Änderung wieder rückgängig machen.
das kann ich allerdings mal machen. das hatte ich auch irgendwo schon mal gelesen. ich berichte.