Windows: Rotationssicherung mit Drive Snapshot – Version 3.0

Die Version 2.0 ist noch gar nicht so lange her, aber dennoch gibt es ein paar kleine Änderungen:

  • Umstellung beim Schreiben der Logs auf den Parameter „–LogFile:“. Diese Änderung wurde notwendig, damit der Sensor von Server-Eye die Datensicherung erfolgreich überwachen kann. Siehe dazu auch diesen Beitrag.
  • Überwachen des Errorlevels von Drive Snapshot um anhand dessen eine einfache E-Mail mit dem Text „Die Datensicherung … war (NICHT) erfolgreich“ versenden zu können. Der Befehl zum Versenden des vollständigen Logs ist nach wie vor vorhanden.
  • Als „Voreinstellung“ ist nun ein lokales Backup-Ziel (statt Netzlaufwerk) eingetragen.

Voraussetzungen

  • Einen Ordner “C:\Backup”, einen Unterordner “C:\Backup\Tools” und “C:\Backups\Logs” anlegen.
  • Die Tools weekday.exe (ab 3.2 nicht zwingend erforderlich) und smtpsend.exe herunterladen und in den Unterordner “Tools” speichern.
  • Eine Datei „week.txt“ mit dem Inhalt „4“ (ohne Anführungszeichen) unter „C:\Backup“ erstellen, damit das erste erstellte Backup mit der „Woche 1“ beginnt.
  • Wird das Skript als „Geplanter Task“ (bis Windows XP/Server 2003) bzw. „Aufgabe“ (ab Windows Vista/Server 2008) ausgeführt, muss unter „Ausführen in:“ bzw. „Starten in (optional):“ „C:\Backup“ eingetragen werden.

Das Skript

Das Skript muss (wie gehabt) auf die eigenen Anforderungen (Lokales oder Netzwerk-Backup, E-Mail-Versand, zu sichernde Laufwerke, etc.) angepasst werden.

DSRotBackup_v3.zip

DSRotBackup_v31.zip – Änderungen siehe Update vom 28.08.2015 am Ende des Beitrags.

DSRotBackup_v32.zip – Ändernugen siehe Update vom 12.01.2017 am Ende des Beitrags.

Für Windows ab Vista wird die Boot-Partition (HD1:1) berücksichtigt.

Als maximale Größe für die Abbilddatei wird mittels des Parameters “-L” für die Boot-Partition ab Windows Vista 350 MB (Vista/7/2008/2008 R2 = 100MB, 8/2012 = 350MB) und für das Laufwerk “C:\” 300 GB angegeben.

Möchte man dieses Skript unter Windows XP verwenden, so sind die Zeilen mit “snapshot.exe HD1:1…” mit einem vorangestellten “rem” auszukommentieren.

Verwendet man ein Netzlaufwerk, so ist das Skript entsprechend abzuändern.

Sichert man mehr als das Laufwerk “C:\” so kann man einfach weitere Laufwerke entsprechend anhängen:

snapshot.exe C:+D:...

 Links

Windows: Fehler mit Drive Snapshot v1.41 und dem Parameter “–AllWriters” vermeiden

Windows: Drive Snapshot 1.41

Windows: Drive Snapshot, Windows 8 und Windows Server 2012

Windows: VSS-Fehler mit Drive Snapshot vermeiden

Update 28.08.2015

In Version 3.1 gibt es ein paar wenige „kosmetische“ Veränderungen. So wurden die Parameter „–FullIfHashIsMissing“ und „–CreateDir“ an die Snapshot-Befehle angehängt (siehe Snapshot – Kommando Zeilen Parameter für Windows). Ferner wurde „-L“ auf „-L0“ geändert (siehe dazu Drive Snapshot – Online-Hilfe und Handbuch – Ein Vergleich lohnt sich). Darüber hinaus ist im neuen ZIP-Archiv bereits die Ordnerstruktur und die Weekday.exe enthalten.

Insgesamt sollte es mit der neuen Version einfacher bzw. schneller sein, Drive Snapshot mit diesem Skript zum Laufen zu bringen. An die persönlichen Anforderungen anpassen muss man das Skript dennoch.

Tipp: Möchte man nicht via „–FullIfHashIsMissing“ die erste Vollsicherung erstellen, so kann man Zeile 42 („REM SET Weekday=Monday“)einkommentieren und das Skript einmalig ausführen. Anschließend die Zeile wieder auskommentieren.

Update 12.01.2017

Mit Version 3.2 gibt es ein paar weitere Änderungen:

Ab Zeile 42:

Alternative zur „Weekday.exe“ hinzugefügt. Keine Abhängigkeit zu externem Tool. Diese Änderung wurde notwendig, da unter Umständen AutoIt-Anwendungen als Aufgabe „hängen“ bleiben.

Siehe dazu auch die Kommentare unter

Windows: weekday.exe – Ein kleines Tool für die Kommandozeile und Skripts

Ab Zeile 82:

Vor dem Start der eigentlichen Vollsicherung wird der alte Backup-Satzes entfernt, um Platz-Problemen vorzubeugen (DS benötigt ggf. mehr Speicher während die Sicherung erstellt wird) und um zu verhindern, das versucht wird von unvollständigen Satz wiederherzustellen.

Ab Zeile 93:

Ereignisprotokoll-Einträge werden erstellt (relevant für neuen Server-Eye DriveSnapshot-Sensor), siehe dazu:

Server-Eye, Drive Snapshot und Einträge ins Ereignisprotokoll – Ideen und Umfrage

154 Gedanken zu „Windows: Rotationssicherung mit Drive Snapshot – Version 3.0

  1. Wäre es nicht besser, die Woche in WEEK erst nach einer erfolgreichen Sicherung in die Datei week.txt zu schreiben?
    So kann es passieren, dass ich mir je eine erfolgreich Sicherung überschreibe wenn ich das Backup an diesem Tag noch einmal starte weil ja week immer hochgezählt wird.

  2. Kann passieren, aber nur wenn etwas schief läuft.
    Das geschieht allerdings bei uns intern oder bei Kunden extrem selten.
    Selbst wenn es mal vorkommt setzen wir einfach die week.txt zurück.
    Das wäre soweit die organisatorische Lösung.

    Eine techn. Änderung ist machbar, das könnte wie folgt aussehen (ungetestet):

    Zeile 80 (löschen oder auskommentieren): echo %Week% > week.txt
    Zeile 88 (neu einfügen): if %error%==false echo %Week% > week.txt

    Auf der anderen Seite muss man allerdings bedenken, das bei der Diff-Sicherung automatisch ein Full gemacht wird, wenn das aktuelle Full nicht gefunden wird.
    Daraus ergibt sich, wenn man die techn. Änderung vornimmt und ein Problem erst später auffällt man dann dennoch evtl. einen intakten Sicherungssatz „zersägt“ hat.
    Wenn z.B. nur zwei Wochen gesichert werden, sind dann schlimmstenfalls beide Wochen dahin.

  3. Hi!
    Welcher Scheduler wird zur automatischen Ausführung emphohlen?
    Mit der Windows Aufgabenplanung startet das Script nicht.

  4. Wir verwenden nur die Windows-Aufgabenplanung, die letzten Jahre war das problemfrei (ausgehend von Windows XP und neuer).
    Neben dem eigentlichen Skript noch bei „Starten in (optional)“ „C:Backup“ eintragen.
    Erhöhte Rechte („Mit höchsten Privilegien ausführen“) benötigt die Aufgabe ebenfalls, da sonst nicht gesichert werden kann.

  5. Hallo andy,
    danke für die schnelle Antwort.

    Nutze die Windows Aufgabenplanung auch schon seit vielen Jahren mit eigenen DS-Scripten. Lief auch bisher ohne Probleme.

    Versuche jetzt Dein Script auf einem Srv2012R2 einzurichten – Rechte / Pfade alle OK. Der Aufgabenplaner zeigt im Status „wird ausgeführt“ aber es passiert einfach nichts.
    Die eigenen Scripte werden ausgeführt. Bin ein wenig ratlos 🙁

    Gruß Rüdiger

  6. Seltsam, bei uns als auch jeder Menge Kunden läuft das ohne Probleme.
    Anbei ein paar Fragen ob das Problem einzugrenzen:

    Wird ein Log erstellt?
    Läuft die „snapshot.exe“ (siehe Taskmanager)?
    Funktioniert das Skript wenn man es von einer Eingabeaufforderung mit erhöhten Rechten aus startet?

  7. Das Script startet über die Eingabeaufforderung und wird fehlerfrei ausgeführt.

    Über den A.-Planer passiert nichts, im Taskmanager wird nichts angezeigt – weder cmd.exe noch snapshot.exe und natürlich auch kein log.

  8. Da sag ich mal „Jeden Tag was Neues“.
    Die Aufgabe schon mal gelöscht und neu angelegt?
    Oder der Aufgabe mal ein anderes Skript zuweisen, das z.B. nur ein „hello world“ ins Log schreibt?

  9. Aloha

    Ich hab das auf mehreren 2012er am laufen und bis auf 0x2 als Ergebnis klappt es einwandfrei.

    Wichtig bei der Aufgabenerstellung ist Höchste Privilege und Ausführen wenn niemand angemeldet ist und dann noch als XP 2003 ausführen (Wenn man das nicht nimmt erscheint nichts in der Aufgabenplanung).Dann noch den Pfad zur Batch-Datei eintragen (Programm Reiter)….

  10. Hallo,
    ich trage mal hier die Einstellungen ein, die bei mir seit Langem einwandfrei funktionieren:
    Allgemein:
    Beim Ausführen etc. folgendes Benutzerkonto: meins
    unabhängig von der Benutzeranmeldung ausführen
    – Kennwort nicht speichern
    – mit höchsten Privilegien ausführen
    Konfigurieren für: Windows 10
    Trigger:
    Wöchentlich um hh:mm jeden Montag
    Aktionen:
    (1) Programm starten:
    c:WindowsSysWOW64cmd.exe /c „Pfad_zum_skript“
    (2) Programm starten:
    shutdown.exe -s
    Bedingungen:
    Computer zum Ausführen der Aufgabe reaktvieren
    Einstellungen:
    Ausführung bei Bedarf zulassen
    Falls Aufgabe scheitert, neu starten alle 10 Minuten
    Neustartversuche maximal: 3
    Ausführung beenden falls Ausführung länger als 3 Tage
    Beenden der aktiven Aufgaben erzwingen etc.
    keine neue Instanz starten
    Verlauf:
    z. Z. deaktiviert

    Was passiert, ist eine wöchentliche Sicherung kurz nach Mitternacht. Im Skript habe ich eine Pause von 2 Minuten eingeführt, bis das System wirklich „wach“ ist, davor hat es Pannen gegeben.
    Nach erfolgter Sicherung fährt alles brav runter.
    Die Aufgabe steht im Scheduler, problemlos zu editieren.

    Hope it helps.
    Grüße,
    A.

  11. „… Ich hab das auf mehreren 2012er …“

    Wir verwenden das Skript als auch DS auf unterschiedlichen System, angefangen von Windows XP und Server 2003, über Windows 7 und Server 2008 R2 bis hin zu 2012 mit und ohne R2. Bislang ohne Probleme und immer nur minimal angepasst (betrifft i.d.R. nur die Partitionen bzw. Laufwerke als auch das Backup-Ziel).

    „…bis auf 0x2 als Ergebnis …“

    Bei uns kommt als Ergebnis 0x0.

    „…noch als XP 2003 ausführen …“

    Hm, ich nehm‘ immer das höchste was verfügbar ist, also bei Win 2012 R2 eben „Windows Server 2012 R2“.

  12. @Andrei

    Danke für die ausführliche Beschreibung.

    Das mit Pause am Anfang hatten wir vor langer Zeit gelegentlich bei der Sicherung auf Netzlaufwerken, manchmal hat es einen Moment gedauert, bis das dieses vollständig verbunden war.

    Wir stellen i.d.R. weniger ein. Bei manchen Kunden haben wir eine nächtliche Arbeitsplatzsicherung am Laufen, bedeutet: Die PCs werden per WoL gestartet, dann läuft das Skript und am Ende vom Skript steht der shutdown-Befehl.

  13. Hallo Andy,
    in deinem Rotationsscript verwendest du sowohl für die Differentail- als auch die Vollsicherung jeweils immer zwei Sicherungsbefehle, unterschieden nach Partitionen die mit und ohne VSS gesichert werden. Das mache ich in meinen Scripten völlig identisch. Seit der Version 1.44 von Drivesnapshot ist es jetzt ja möglich eine ganze Festplatte am „Stück“ zurück zu sichern. Ich habe in diesem Zusammenhang bisher die Erkenntnis gemacht, dass das aber nur möglich ist, wenn alle Partitionen einer Platte über einen einzigen Befehl gesichert werden und somit auf die Unterscheidung mit VSS und ohne VSS verzichtet wird, die ja durchaus einen Sinn macht. Hast du die gleiche Erfahrung gemacht ?

  14. Via Skript habe ich die Neuerung noch nicht getestet. Ob der Restore der gesamten HDD von einer diff. Sicherungen möglich ist, wollte ich mal testen.

  15. Hallo Andy,

    erstmal vielen Dank für das Script.
    Ich habe leider ein Problem mit der Rotation.

    Die erste Sicherung fängt mit 4 an, statts mit 1.
    Die Datei „week.txt“ hatte inhaltlich eine 4.

    Ich habe die Sicherung trotzdem eine Woche zum testen durchlaufen lassen und bekam heute erstmals folgende Fehlermeldung:

    The names of the differential and original image are identical. Please choose a different image name.

    Das ganze läuft unter Windows 2012 R2.

    Ich habe das Script in der Version 3.1 eigentlich nur bei den Pfaden, Festplatten, Email angepasst.

    Es wäre schön wenn Du vielleicht noch eine Idee hättest was ich falsch mache.

    Viele Grüße
    Bernd

  16. > Die erste Sicherung fängt mit 4 an, statts mit 1.
    > Die Datei “week.txt” hatte inhaltlich eine 4.

    Das ist richtig, da in der Voreinstellung vier Wochen aufbewahrt werden und automatisch bei der 4 dann der Wechsel zu 1 kommt.
    Würde eine 1 in der Datei stehen, wäre die erste Sicherung 2.

    > The names of the differential and original image are identical. Please choose a different image name.

    Diese Meldung gab es bereits schonmal in den Kommentaren, leider weiß ich nicht warum.
    Aktuell teste ich in einer virtuellen Maschinen und bekomme diese Meldung bislang nicht.
    Auf all unseren Produktivsystemen erscheint diese Meldung ebenfalls nicht,
    von daher bekomme ich das im Moment nicht nachvollzogen.

  17. Nur heißen meine Sicherungen dann leider genauso wie ich Sie in die „week.txt“ eintrage und nicht plus 1. Ich habe gerade in die „week.txt“ eine 1 eingetragen und auf ein leeres Ziel gesichert. Als Ergebnis bekomme ich Diff-1 u. Full-1, vorher als die 4 eingetragen war hießen sie Diff-4 und Full-4. Vielleicht sollte ich noch erwähnen das mein Sicherungsziel ein Webdav Laufwerk ist. Damit hatte ich anfänglich Probleme mit der Windows Größenbeschränkung (FileSizeLimitInBytes). Der Webdav Standardwert ist ca. 50 MB und max = 4gb.

  18. Steht in der „week.txt“ nur die Zahl oder Zahl mit Leerstelle (z.B. „4 „)?
    Das Skript filtert das Leerzeichen aus. Ich kann aber nicht sagen, ob es da einen Zusammenhang mit den genannten Problemen gibt.

    Mit WebDAV als Ziel habe ich keine Erfahrung, dazu kann ich nichts sagen.
    Wir sichern entweder auf lokale Laufwerke, USB-Festplatten, Netzlaufwerke oder UNC-Pfade.

  19. Kleines Update zur Meldung „The names of the differential and original image are identical. Please choose a different image name.“

    Bei mir trat es im Test nur auf, wenn an dem Tag, an dem die Vollsicherung nachgeholt wurde eine Diff-Sicherung erstellt werden soll. Das kann beim Testen „gerne“ passieren. Abhilfe ist entweder gezielt die Vollsicherung durch „set Weekday=Monday“ zu erstellen oder „set Weekday=“ auf einen anderen Tag als den aktuellen zu setzen.

  20. Pingback: Server-Eye, Drive Snapshot und Einträge ins Ereignisprotokoll – Ideen und Umfrage | Andys Blog – Linux, Mac, Windows

  21. Eine Frage: Gibt es eine Möglichkeit, das differentielle Backup zu beschleunigen? Mit meinem anderen Programm, Backup-Manager, geht das binnen 5 Minuten. Snapshot braucht dagegen 45 Minuten.

    Oder liegt es am Typ des Backups? Backup-Manager macht ein Dateibackup, da es wegen meiner mit Diskcrypter verschlüsselten SSD kein Plattenbackup machen kann, im Gegensatz zu Snapshot.

  22. > Oder liegt es am Typ des Backups?

    Vermutlich ja, da Drive Snapshot Image-basiert arbeitet und dabei „nur“ Voll- und Diffenrenzsicherung kennt.
    Die Differenzsicherung sichert die seit der Vollsicherung geänderten Blöcke auf dem Laufwerk.
    Je länger die Vollsicherung zurückliegt, desto größer sind meist die Änderungen und folglich umso länger benötigt die Differenzsicherung.
    Ferner kommt es darauf an, um welche Datenmengen es sich handelt. Bei mehreren hundert GB oder gar im TB-Bereich dauert das Berechnen der Prüfsummen seine Zeit.

    Kommt auch darauf an wie Backup-Manager (ich kenne das Programm leider nicht, Hersteller und Link wären interessant) arbeitet. Bei Datei-Backups kann die ganze Datei, nur geänderte Dateien oder auch nur die Änderung innerhalb einer Datei (Delta) kopiert werden. Ferner kommt es darauf an, ob die Änderung anhand von Zeitstempel oder Prüfsummen ermittelt wird und welche Kopier- und Datensicherungsverfahren (Inkrementell, Differentiell, Kopie, VSS, …) verwendet werden.

  23. Danke. Nachdem ich die erste Snapshot-Zeile im Batch mit „HD1:1“ rausgenommen habe (ich habe nur eine einzige Partition auf der Platte), lief das differentielle Backup auch mit Snapshot binnen 5 Minuten durch. Scheint also das Problem schon erledigt zu sein.

    Der Backup-Manager ist der hier:
    http://www.digital-dynamic.org/de/advanced-backup-manager/

    Eigentlich ein super Programm, deutlich günstiger als Snapshot, deutlich schneller beim Sichern auf NAS über WLAN, und man kann sich damit diese Scripterei sparen, weil Diff-, Inkr- und Vollbackups sauber automatisch verwaltet werden. Es gibt regelmäßig Aktualisierungen und Patches.

    Leider jedoch kann das Programm keine verschlüsselten Platten sichern, d.h. das geht natürlich schon, aber es will immer die ganze Platte sichern und nicht nur die belegten Sektoren. Der Entwickler (auch aus BRD) will das aber irgendwann unterstützen. Daher kann ich nur auf Dateiebene sichern, was aber im Falle eines Plattencrashs nicht wirklich hilft.

  24. Hallo Andy,
    habe Deine Sicherung nach Neuinstallation von Windows 10 Neu eingerichtet dabei ist mir folgendes aufgefallen:
    ***
    Wird das Skript als “Geplanter Task” (bis Windows XP/Server 2003) bzw. “Aufgabe” (ab Windows Vista/Server 2008) ausgeführt, muss unter “Ausführen in:” bzw. “Starten in (optional):” “C:Backup” eingetragen werden.
    ***
    Unter Windows 10 müßen „“ bei C:Backup weggelassen werden.
    Vielleicht habe auch nur ich das so interpretiert. Brauchte eine Weile um den (meinen) Fehler herauszufinden.
    Ansonsten läuft mittlerweile alles wunderbar.
    Danke Klaus

    https://blog.blackseals.net/2012/11/10/windows-aufgabe-bricht-mit-fehler-2147942667-ab/

  25. Hallo Andy,
    kannst Du mir sagen was ich falsch gemacht habe ??
    Platz müßte vorhanden sein.
    **********************************************************
    16:26:37 free space info: total 983GB, 775.749MB free, 231.530MB must be saved
    16:26:39 D: -> Diff-4-Sunday-D.sna
    16:51:11 ***********************************************************
    16:51:11 Snapshot error NTCOPY, line 820
    16:51:11 could not write 131072 of 131072 bytes at filepos 156.685.440K
    16:51:11 last Windows Error: 70-Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung.
    16:51:12 Error occurred – exitcode 6

  26. Während das Backup ausgeführt wird, wird ggf. temporär mehr Speicherplatz benötigt, als nur für die reinen Änderungen, von daher ist es immer gut, wenn mehr Platz vorhanden ist. Möglicherweise ist das Ziel aber auch nicht erreichbar, das kann z.B. bei instabilen Netzwerk- oder USB-Verbindungen der Fall sein, oder der Virenscanner funkt dazwischen (am besten die „snapshot.exe“ als Ausnahme definieren).

  27. Hallo Andy,
    das Platzproblem habe ich mittlerweile gelöst.
    Beim ersten PC läuft auch alles (mit monatlicher Montags Voll und Mittwochs wöchentlicher Diff Sicherung mit E-Mail benachrichtigung sehr gut.
    Nun habe ich beim zweiten PC eine anderen Fehler..
    Bekomme bei der ersten Sicherung (Leere Sicherungsordner) folgende Fehlermeldung:

    ************************
    11:29:57 Start of Snapshot 1.44.17514 [Aug 17 2016] at 26.08.2016
    11:29:57 Running on Windows 10 32-bit (14393)
    11:29:57 Memory Info: Total: 2815Mb, Free: 1988Mb, Pagefile total: 5631Mb, Pagefile free: 4814Mb
    11:29:57 Command line: snapshot.exe HD1:1 D:BackupSnapshotPRAXIS-PCDiff-4-Friday-$disk.sna -hD:BackupSnapshotPRAXIS-PCFull-4-Monday-$disk.hsh -W –novss -L0 –LogFile:C:BackupLogsCurrent.log –CreateDir –FullIfHashIsMissing
    11:29:58 Differential backup failed because the hash file D:BackupSnapshotPRAXIS-PCFull-4-Monday-C.hsh is missing. Starting a full backup
    11:29:58 Disks in backup:
    11:29:58 C: -> D:BackupSnapshotPRAXIS-PCDiff-4-Friday-C.sna
    11:29:58 Start backup of C: -> D:BackupSnapshotPRAXIS-PCDiff-4-Friday-C.sna
    11:29:59 free space info: total 199.551MB, 167.845MB free, 27.764MB must be saved
    11:30:01 C: -> D:BackupSnapshotPRAXIS-PCDiff-4-Friday-C.sna
    11:40:49 C: 31.706MB in use – stored in 17.051MB – 10:50 minutes
    11:40:49 Success
    11:40:49 Snapshot finished successfully
    11:40:49 End of Snapshot 1.44 [Aug 17 2016] at 26.08.2016

    11:40:49 Start of Snapshot 1.44.17514 [Aug 17 2016] at 26.08.2016
    11:40:49 Running on Windows 10 32-bit (14393)
    11:40:49 Memory Info: Total: 2815Mb, Free: 2017Mb, Pagefile total: 5631Mb, Pagefile free: 4890Mb
    11:40:49 Command line: snapshot.exe C: D:BackupSnapshotPRAXIS-PCDiff-4-Friday-$disk.sna -hD:BackupSnapshotPRAXIS-PCFull-4-Monday-$disk.hsh -RW –AllWriters -L0 –LogFile:C:BackupLogsCurrent.log –FullIfHashIsMissing
    11:40:50 The names of the differential and original image are identical.
    Please choose a different image name (D:BackupSnapshotPRAXIS-PCDiff-4-Friday-C.sna).
    11:40:50 Error occurred – exitcode 1
    11:40:50 End of Snapshot 1.44 [Aug 17 2016] at 26.08.2016
    *************
    Gruß Klaus
    P.S.: Kann ich übe Dich eine
    SNAPSHOT Arbeitsplatz Lizenz Email Version
    bestellen ??

  28. „The names of the differential and original image are identical.“ diesen Fehler habe ich bei mir immer nur dann reproduzieren können, wenn am gleichen Tag Voll- als auch Diff-Sicherung erstellt wurden. Ist dann auch logisch, da mit „–FullIfHashIsMissing“ angegeben ist, das eine Vollsicherung erstellt werden soll wenn keine vorhanden ist. Dabei wird das Hash-File zwar mit dem Tag im Namen der geplanten Vollsicherung erstellt, aber die Abbilddatei (*.sna) bekommt den Tag der Ausführung im Namen „verpasst“. Daraus ergibt sich dann, das man seine Vollsicherung und davon abhängige Diff-Sicherungen „zerschiesen“ würde, wenn dieses Überschrieben wird. Abhilfe schafft im Skript den eigentlichen Voll-Backup-Tag zu „simulieren“ (set Weekday=…).

    Siehe dazu mein Kommentar vom 5.Juli 2016.

    Lizenzen gibt’s direkt beim Hersteller: http://www.drivesnapshot.de/de/order.htm oder über uns http://www.computerservice-haibach.de/

  29. Hallo Andy,
    bei mir tritt plötzlich ein Problem auf, das nicht direkt mit Snapshot zu tun hat, aber mit dem Aufruf des Skripts per Aufgabenplanung, in dem auch Snapshot auftritt und eine Rotationssicherung machen soll..Hat alles monatelang bestens funktioniert.
    Ich habe das Skript jetzt um ein paar Dinge ergänzt und plötzlich heißt es im Verlaufsprotokoll der Aufgabenplanung:
    „Die Aufgabenplanung hat die Aufgabe „MicrosoftWindowsAutobackup“, Instanz „{c6afa896-041d-4d61-a752-037a86722d1a}“, Aktion „C:WindowsSysWOW64cmd.exe“ mit Rückgabecode 2147942401 erfolgreich abgeschlossen.“

    **Das Skript wird gar nicht ausgeführt!** Keine Protokolldatei, nichts. Ich habe lange gegoogelt und zu diesem Code nichts gefunden, außer dass er auf eine „Invalid function“ hindeutet und etwas mit Windows Backup und Restore zu tun hat. Diese rufe ich aber gar nicht auf.

    Beim ersten Testlauf lief alles sauber (Hibernation, Reaktivierung, Skript ausführen und runterfahren).

    Die Einstellungen der Aufgabe habe ich hier am 27. April 2016 um 18:26 veröffentlicht.

    Was ist jetzt los?? Irgendeine Idee??

  30. Diesen Fehler kenne ich leider nicht. Da es aber seit Dezember mit der „weekday.exe“ und der Aufgabenplanung Probleme gibt (genauergesagt mit verschiedenen AutoIt-Programmen und der Aufgabenplannung) sollte man zuerst die „weekday.exe“ durch native Windows-Befehle ersetzten. Siehe dazu entweder die aktuelle Version des Skriptes (3.2) oder die Kommentare zu Windows: weekday.exe – Ein kleines Tool für die Kommandozeile und Skripts

    Parallel dazu die Fragen:

    – Welches OS?
    – Funktioniert die Sicherung, wenn man sie manuell auslöst (ohne Aufgabenplanung)?
    – Welche Änderungen wurden vorgenommen?

  31. Weekday.exe benutze ich nicht.
    Deine Fragen:
    – bei mir läuft Windows 10 Pro 1607
    – der .cmd-Skript läuft bei manueller Auslösung, sowohl im cmd.exe-Fenster als Administrator, als auch mit der Aufgabenplanung („Ausgewähltes Element ausführen“)
    – die Änderungen sind in dem .cmd-Skript, der eben nicht ausgeführt wird. Es wird eine Datei kopiert zusätzlich zur Snaphot Sicherung.

    EINMAL lief das Ganze sauber durch, wie oben gesagt. Dann nicht mehr. Der Rückgabecode ist in Hex 0x80070001
    Das Problem ist nicht mein Skript.
    Welche Probleme meinst du mit „verschiedenen AutoIt-Programmen“?

  32. Hier im Blog gibts Meldungen und vereinzelt sehen wir das auf unseren als auch Kunden-Systemen, das Programme die in AutoIt geschrieben sind, plötzlich nicht mehr als Aufgabe durchlaufen. Davon betroffen ist unter anderem die „weekday.exe“, die bislang im DS_Skript Verwendung fand. Um sicher zu gehen, das es nicht daran liegt, sollte man wie erwähnt die „weekday.exe“ durch den anderen Code ersetzen.

    Parallel dazu habe ich noch die von dir genannten Einstellungen angeschaut. So starten wir bislang kein Skript oder Programm. Nicht auszuschließen ist allerdings, das auch dieses Problem eine Windows 10-Kinderkrankheit ist.

  33. „Parallel dazu habe ich noch die von dir genannten Einstellungen angeschaut. So starten wir bislang kein Skript oder Programm.“
    Dann wäre es vielleicht eine Hilfe, wie es besser anders sein sollte – jedenfalls bin ich damit bis zu dieser Situation gut gefahren, cmd.exe wurde immer! ausgeführt, entspr. auch der Skript.
    Danke jedenfalls!

  34. Ich musste bislang nie eine „cmd…“ angeben. Alle Aufgaben die ich seit Jahren anlege laufen i.d.R. einfach. Einzig das man ggf. „Ausführen in“ angeben muss ist das einzige was wir so spontan einfällt was man je nach Skript oder Programm beachten muss.

    Der Fehlercode 2147942401 wird laut Recherche mit ungültigem Pfad in Verbindung gebracht, also auf jeden Fall mal „Ausführen in“ prüfen und ggf. eintragen.

    Quelle(n):

    2012 Task Scheduler Batch Fails
    why windows 7 task scheduler task fails with error 2147942667

    Bitte mal schauen, ob (sofern die „weekday.exe“ noch verwendet wird) die Datei „weekday.txt“ aktualisiert wird. So könnte man eingrenzen, in wie weit das Skript evtl. läuft oder alternativ mal ein wenig „Debug-Code“ einbauen. Wie z.B. das man in jedem Abschnitt ein „echo >> debug.txt“, so könnte man sehen ob das Skript überhaupt gestartet wird und falls ja, bis zu welcher Stelle es läuft.

    Bevor der Fehler auftrat wurden da irgendwelche Updates (Windows, AV, …) installiert? Möglicherweise gibt es da einen Zusammenhang. Wegen der „AutoIt“-Problematik wurde spekuliert, das es mit Windows Updates zusammenhängen könnte.

  35. Ha.
    Das war’s wohl: Aktion „C:WindowsSysWOW64cmd.exe“

    Habe nun mein Skript direkt eingesetzt, Protokolldatei als Argument, den Pfad in „Ausführen in“ und es lief.
    Jetzt beobachte ich mal, was im Dauerbetrieb passiert. Ich glaube, die Idee mit SysWOWcmd.exe bzw System32cmd.exe habe ich irgendwo aufgeschnappt – doppelt gemoppelt. Wieso es mal lief, mal nicht, ist mir immer noch schleierhaft.

    Jedenfalls herzlichen Dank, auch wenn’s kein Snapshot-Problem war! Dein Skript läuft jedenfalls seit 1 1/2 Jahren perfekt.

  36. Danke für die Info.

    Wie erwähnt, „cmd…“ habe ich nirgends im Einsatz und das läuft so seit min. Windows XP bzw. Server 2003-Zeiten bislang ohne Probleme ganz gleich mit welchen Batch-Skripten (gibt ja noch mehr als Backup).

    Möchte allerdings nicht bestreiten, das es Unterschiede, Vor-/Nachteile, etc. geben kann. Vlt. hatte ich ja auch nur Glück.

  37. Jetzt am Abend wieder mit dem verdammten Code 2147942401 gescheitert. Macht mich fix & fertig.

  38. Der Vollständigkeit-halber gefragt: Mit höchsten Rechten, höchste OS-Version, gespeicherte Admin-Daten etc. ausgeführt?

    Geht es evtl. immer nur nicht, wenn kein Benutzer angemeldet ist?

  39. Ja und ja und ja.

    Die Task soll den Rechner reaktivieren, d.h. auch, ich bin angemeldet beim Wechsel ins Hibernate.

    Getestet habe ich das unter dien Bedingungen: Hibernate, abwartet, bis die Task startet. Wenn der Rechner herunterfährt, heißt es, dass das Skript abgearbeitet wurde (letzter Befehl). Wenn nicht, dann ist was schiefgelaufen.

    Ein Verdacht kommt mir auf. Vor ein paar Wochen hatte ich einen bösen Windows-Absturz und musste alles mit Snapshot restoren – mit dem Rescue-Stick von dir (Snapshot als Option eingebaut). Ging alles wunderbar und funktioniert seither soweit einwandfrei. Kann es sein, dass bei der Gelegenheit der Task Scheduler irgendwie alten Schrott findet und ins Stolpern kommt? Ich hatte die c: Platte nicht neu formatiert.

  40. Beim Restore überschreit DS alles, es wird ja nicht auf Datei- sondern auf Block-Ebene gearbeitet. Da sollten folglich keine „Altlasten“ übrig bleiben.

    Gibt es evtl. weitere Unstimmigkeiten in Windows, z.B. Einträge in den Ereignisprotokollen, evtl. mal mit sfc, dism, chkdsk, usw. prüfen.

    Vielleicht sollte man mal mit einer Alternative zur Windows-eigenen Aufgabenplanung testen, z.B. Z-Cron o.ä. (habe damit allerdings keine Erfahrung).

  41. Jetzt habe ich den Eintrag „Unabhängig von der Anmeldung“… abgewählt und stattdessen „Wenn angemeldet…“ — und siehe da, es lief wieder.
    Alles mit höchsten Privilegien.
    Mal sehen. Heute Abend um 22:45 ist der normale Lauf vorgesehen.
    chkdsk, sfc etc. lasse ich vorher noch laufen.
    Die Ereignisprotokolle in der Ereignisanzeige zeigen exakt das, was auch in der Aufgabenplanung erscheint, ist wohl dieselbe Quelle.

  42. Ich drück mal die Daumen!

    Die Frage nach den Ereignissen war darauf bezogen, ob vielleicht noch andere/weitere Fehler protokolliert werden.
    Oft ist es so, das es Probleme in Windows oder mit anderen Programmen gibt, die man als Anwender nicht mitbekommt, aber in den Logs vieles gelb oder rot ist.

  43. Ich habe sfc/scannow ausgeführt, einige Sachen wurden repariert, andere aber nicht.

    Daraufhin habe ich dism ausgeführt, mit diesem Ergebnis (davor die Windows 10 PRO x64 ISO heruntergeladen und install.wim mit 7Zip extrahiert):

    C:WINDOWSsystem32>DISM /Online /Cleanup-Image /RestoreHealth /Source:C:DownloadsWin_10_ISOinstall.wim
    Tool zur Imageverwaltung für die Bereitstellung
    Version: 10.0.14393.0
    Abbildversion: 10.0.14393.0
    [== 4.5% ]
    Fehler: 1726
    Der Remoteprozeduraufruf ist fehlgeschlagen.
    Die DISM-Protokolldatei befindet sich unter „C:WINDOWSLogsDISMdism.log“.

    Die dism.log und CBS.log sind sehr umfangreich und detailliert, zuviel zum Posten. Könnte ich evtl separat per Email machen.

    Jetzt warte ich ab, was der Task Scheduler macht.

  44. Kleiner Erfahrungswert am Rande: Ich habe heute auf einem Windows 10-Tablet von Maxdata mit dem Erstellen einer Aufgabe „gekämpft“. Dort sollte ein simples Batch-Skript hinterlegt werden, allerdings wurde man ständig „angemeckert“ das Argumente fehlen würden oder falsch sind, dabei gab es überhaupt keine. Es spielte zudem keine Rolle, wie das Skript angesprochen wird (mit/ohne „cmd.exe…“ vorweg), ob mit „Starten in“ oder Ohne. Letztlich wurde die halbfertige Aufgabe gelöscht und alles nochmal von vorne gemacht und plötzlich ging’s. Das hatte zwar nun nichts mit DS zu tun, aber zeigt das wohl die Aufgabenplanung in Windows 10 irgendwie „speziell“ ist. Solche Schwierigkeiten kenne ich von anderen Windows-Versionen bzw. deren Aufgabenplanungen nicht.

  45. Alerdings. Nach der ersten beiden korrekten Läufe ging es plötzlich wieder nicht mehr (Fehlercode s.oben).. Ich hatte nichts geändert.

    sfc /scannow meldet nicht reparierbare Fehler.

    Mit DISM habe ich Folgendes Male versucht:
    1. die ISO Windows 10 Pro x64 heruntergeladen und auf eine DVD gebrannt – Laufwerk F:.
    2. Im Administrator_konto_ mit administrativen Rechten das Kommando-Fenster geöffnet und diesen Befehl eingegeben:
    Dism /Online /Cleanup-Image /RestoreHealth /Source:wim:F:sourcesinstall.wim:1 /LimitAccess

    Bei mehrmaligen Versuchen kam bei 91,2% (vielleicht auch 91,3 oder 91,4%) die Meldung:
    Quelle nicht gefunden etc. pp.

    Die DISM.log listet eine enorme Menge an Meldungen, die ich alle nicht deuten kann.

    Ein Lauf von chkdsk /r hat sehr lange gedauert, ich musste weg, in meiner Abwesenheit kamen in die CBS.log jede Menge Infos von dieser Art:
    WU creates the package, AppID:UpdateOrchestrator, UpdateID:{6B1BDF42-539B-4C6F-AD6C-727D06B404E1}, revision: 201

    Ich weiß nicht weiter und muss aufgeben 🙁

  46. Meines Wissens nach sind in den Logs Meldungen mit „error“ relevant.
    Ich persönlich suche dann immer Fall-spezifisch nach den Fehlern im Netz, in der Hoffnung eine Lösung zu finden.
    Wenn alles nichts hilft, bleibt nur die Neuinstallation.

    Die CBS/WU creates…-Meldung klingt danach, als ob da noch Windows Updates im Hintergrund „rödeln“.

  47. Der fehlerhafte Lauf wiederholt sich. Ich habe jetzt mit dem Tool MyEventViewer genauer hingeschaut. Im Zeitfenster ab Start der Aufgabe 22:45:00 bis „erfolgreichem“ Ende 22:45:14 gibt es nur ein Event, das seltsam klingt:
    „21673 System Information 09.02.2017 22:45:01 Microsoft-Windows-Kernel-General 5 1 Andrei-i7 0 280 Mögliche CVE-Erkennung: 2017-02-09T21:45:01.500000000Z Zusätzliche Informationen: 2017-02-09T17:42:20.727704100Z Dieses Ereignis wird generiert, wenn eine bekannte Exploit-Sicherheitslücke (2017-02-09T21:45:01.500000000Z) erkannt wird. Dieses Ereignis wird durch einen Benutzermodusprozess ausgelöst. “

    Keine Ahnung, was das sein kann, Kaspersky meldet nichts.

    Die übrigen Events der Vollständigkeit halbe (Seagate ist meine NAS-Festplatte):

    21674 System Information 09.02.2017 22:45:01 Microsoft-Windows-Kernel-Boot 0 18 Andrei-i7 0 148
    21675 System Information 09.02.2017 22:45:01 Microsoft-Windows-Kernel-Boot 0 32 Andrei-i7 0 148
    21676 System Information 09.02.2017 22:45:01 Microsoft-Windows-Kernel-Boot 32 25 Andrei-i7 0 160
    21677 System Information 09.02.2017 22:45:01 Microsoft-Windows-Kernel-Boot 33 27 Andrei-i7 0 148
    21678 System Warning 09.02.2017 22:45:01 e1iexpress 0 27 Andrei-i7 44 244 Gigabit-Netzwerkverbindung Intel(R) 82578DC Network link is disconnected.
    37359 Application Information 09.02.2017 22:45:02 Seagate Dashboard Services 0 0 Andrei-i7 0 248 PowerEvent wurde vom Dienst erfolgreich verarbeitet.
    37360 Application Information 09.02.2017 22:45:03 Seagate Dashboard Services 0 0 Andrei-i7 0 248 PowerEvent wurde vom Dienst erfolgreich verarbeitet.
    21679 System Information 09.02.2017 22:45:05 e1iexpress 0 32 Andrei-i7 44 244 Gigabit-Netzwerkverbindung Intel(R) 82578DC Network link has been established at 1Gbps full duplex.

  48. Das sagt mir leider nichts.

    Der Vollständigkeit- bzw. Sicherheitshalber:

    – Neueste DS-Version verwendet? (Nicht nur nach der Versionsnummer schauen, am besten aktuelle Exe runterladen und freischalten.)
    – Min. „snapshot.exe“ bzw. „snapshot64.exe“ in Kaspersky ausschließen oder mal mit deaktivierem Schutz testen
    – Ist die „weekday.exe“ durch den anderen Code ersetzt worden?

Schreibe einen Kommentar

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