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

184 Kommentare

  • Hallo Andy, bin durch Zufall auf dein Script gestoßen und möcht mich erstmal dafür bedanken!
    ich habe zwar bereits regelmäßige Sicherungen mittels DS am laufen, möchte das „System“ aber nun auf diesen Script umstellen.
    Die nötigen Anpassungen liefen ohne größere Probleme. Diese gab es aber beim Mailversand mit dem Tool.
    es kam immer die Meldung: „Permanent message handling problem [60]“ zu deutsch User/Passwort falsch.
    kopierte ich die smtpsend.exe… Zeile aus dem Script in eine eigene Batch, lief alles einwandfrei?????!!!!!!
    Als Ursache für das Verhalten konnte ich schließlich die Zeile:
    setlocal disableextensions disabledelayedexpansion im Block :eventlog ermitteln!
    Sobald ich diese auskommentiere läuft alles! 🙂
    Ich weiß nicht ob das Auskommentieren irgendwelche Auswirkungen hat, wollte es aber der Vollständigkeithalber hier anmerken!
    Ach ja, das System läuft auf W10-64 Ausgabe 1703

    Ich verwende übrigens eine Laufwerksvariable in der Art:
    Set Quelle=C:
    ……
    snapshot.exe %Quelle% …..

    das vereinfacht die Anpassung auf einzelne Laufwerke erheblich! 😉

    Gruß
    franz

  • „setlocal …“ kommt von der Server-Eye respektive Ereignisprotokollerweiterung für’s Monitoring:

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

    Eigentlich hatte ich „setlocal disableextensions disabledelayedexpansion“ extra eingebaut, damit es keine Schwierigkeiten gibt und seinerzeit auch erfolgreich getestet.
    Was genau da nun schief läuft kann ich leider nicht sagen.

  • hallo andy,
    der vollständigkeithalber zu meinem Post oben:
    „setlocal enableextensions“ entfernt aus allen Variablen die NACH dem Befehl per Set… definiert werden eventuell vorhandene ‚!‘
    aus set test = abc!123 wird also abc123
    Da ich in meinem Mailpasswort ein ‚!‘ verwende, war bei Smtpsend dann logischerweise das Passwort (dank fehlendem ‚!‘) falsch!!!!
    vielleicht hilft der tipp ja jemandem! 😉

    Gruß
    franz

  • Ich nutze folgendes Script für Backup, es wird bmail.exe und ftp2use benötigt. Beide kostenlos.
    ———————————————————-
    @echo off
    rem ************************************** VARIABLEN setzen ******************************************
    set ServerIP=192.*.*.*
    set Firma=**********
    set Backuppfad=Backup
    set Passwort=******
    set Benutzer=******
    set Mailserver=mail.******.de
    set MailAbsender=backup******.de
    set MailEmpfaenger=info******.de
    set /A AnzahlTageDiffBackup=19
    set /A AnzahlTageAlleBackup=150
    set WindowsLaufwerk=C
    set Medium=SYNOLOGY

    IF EXIST %public%%FIRMA%_%MEDIUM%_%WINDOWSLAUFWERK%.hsh (
    set Backup=DIFF
    ) ELSE (
    set Backup=FULL
    )

    rem ***************************** Backup erstellen und emailversand **********************************

    C:
    cd %public%
    snapshot64.exe HD1:* ftp://%BENUTZER%:%PASSWORT%@%SERVERIP%/%BACKUPPFAD%/%COMPUTERNAME%/$date_$hour$minute_%BACKUP%_$disk.sna -h%public%%FIRMA%_%MEDIUM%_$disk.hsh -l0 –FullIfHashIsMissing –CreateDir -R –PrintTotals –LogFile:%public%snapshot.log
    if %errorlevel% == 0 (
    bmail.exe -s %MAILSERVER% -t %MAILEMPFAENGER% -f %MAILABSENDER% -a „Reportmailer (%FIRMA% – %COMPUTERNAME%)“ -b „%BACKUP% Backup erfolgreich angelegt | %MEDIUM%“ -h -m snapshot.log
    ) else (
    bmail.exe -s %MAILSERVER% -t %MAILEMPFAENGER% -f %MAILABSENDER% -a „Reportmailer (%FIRMA% – %COMPUTERNAME%)“ -b „%BACKUP% Backup NICHT erfolgreich angelegt | %MEDIUM%“ -h -m snapshot.log
    )

    rem ****************** Hashfile und Log löschen, um ein Vollbackup generieren **************************

    del %public%snapshot.log /q

    Forfiles /P %public% /M %FIRMA%_%MEDIUM%_%WINDOWSLAUFWERK%.hsh /D -%AnzahlTageDiffBackup% /C „cmd /c del /q %FIRMA%_%MEDIUM%_*.hsh“

    C:
    cd“Program FilesFerro SoftwareFtpUse“
    ftpuse X: %SERVERIP%/%BACKUPPFAD% %PASSWORT% /USER:%BENUTZER% /HIDE
    ping localhost -n3
    Forfiles /P X:%COMPUTERNAME% /M ??????_????_FULL*.* /D -%AnzahlTageAlleBackup% /C „cmd /c del /q @path“
    Forfiles /P X:%COMPUTERNAME% /M ??????_????_DIFF*.* /D -%AnzahlTageDiffBackup% /C „cmd /c del /q @path“
    ftpuse X: /DELETE

  • Hi,
    ich nutze eine (meine) Variante des Scripts.
    Nun möchte ich das Script mehrmals am Tag laufen lassen, d.h. es soll jede zwei Stunden ein Differenzielles Backup gemacht werden.

    Man müsste wahrscheinlich irgenwie was hochzählen?!

    Gibt es dafür evtl. schon einen Lösungsansatz?

    Vielen Dank & Gruß
    Benjamin

  • Hallo Benjamin,

    diese Variante, gemeint ist mehrere Sicherungen am Tag, steht bei mir schon länger auf der ToDo-Liste. Im Ansatz habe ich daran schon gearbeitet, aber ist noch nicht „spruchreif“.
    Bei dieser Rotationssicherung wird ja auf Basis des Tages gearbeitet. Das Ganze müsste man dann entweder um eine Version oder einen Zeitstempel erweitern, damit nicht immer die differentielle Sicherung überschrieben wird.
    Darüber hinaus ist der Zeitpunkt der Vollsicherung relevant, z.B. statt wie bisher Montags-Nachts dann eben Montags-Früh.

    Auf Basis nur von Versionen wurde schonmal was umgesetzt:

    Windows: Versions-basierte Drive Snapshot-Sicherungen

  • Ich lasse jetzt zwei Batch Files unabhängig von einander laufen.

    Nachts auf ein Share, welches Fallweise mit einem eigenen User verbunden und anschließend wieder getrennt wird.

    Tagsüber auf eine externe Platte, die anschließend gewechselt werden sollt.

    Gibt es Erfahrungswerte mit RDX Laufwerken?

  • RDX in Verbindung mit Drive Snapshot habe ich nie verwendet. Meine generellen Erfahrungen mit diesen Laufwerke findet man über die Suche des Blogs:

    https://www.andysblog.de/?s=rdx&submit=Suchen

  • Sorry for english 🙂
    Still the best tool and script i found. Working very reliable on W7, W10 1903 and server 2016.
    Anyone able to put the log file in a decent way in a windows event after finishing (of course with different event id’s).

    I added the creation of event’s at start and end of the script via „EVENTCREATE /so DriveSnapShot /ID 820 /D „backup batchfile started“ /T INFORMATION /L APPLICATION >nul“
    Also added the creation of a 4098 / 8001 event to simulate a MS W7 / MS NT backup event so the RMM tool (maxfocus/solarwinds) is able to monitor the backup status. I used an old MS toolkit utility „logevent“ that is able to write event >1000

    Something like
    if %error%==true Toolslogevent -s E -r NTBackup „End Operation: Warnings or errors were encountered. Consult the backup report for more details.“ -e 8019
    if %error%==true Toolslogevent -s E -r „Windows Backup“ „End Operation: Warnings or errors were encountered. Consult the backup report for more details.“ -e 4104
    and
    if %error%==false Toolslogevent -s I -r NTBackup „End Backup of ‚System State'“ -e 8001
    if %error%==false Toolslogevent -s I -r „Windows Backup“ „End Backup of ‚System State'“ -e 4098
    Works like a charm since 2016.

  • Hallo Andy,

    seit ich Dein Script nun auch auf Win10 verwende, habe ich das Problem der Rechte, d.h. bei jedem Aufruf von DriveSnapshot muss ich die Ausführung als Administrator bestätigen und das Script läuft dann natürlich nicht durch.

    (Asche auf mein Haupt, aber ich finde leider nicht die richtige Vorgehensweise der Rechtevergabe bzw. klappte das bisher nicht… )

    Danke für die Unterstützung …. und bleib gesund!
    Gruß Reinhard

  • Unterschiedliche Partitionierungen der Versionen von Win10

    Problem: Sicherungen von HD1:1 … HD1:2 … HD1:3 usw. bis HD1:7

    Mir ist aufgefallen, dass nach Updates der verschiedenen Builds von Windows 10 urplötzlich eine weitere Partition aufgetaucht ist und umgekehrt auch wieder verschwunden ist. Außerdem hatte sich ebenfalls auch die Reihenfolge geändert.

    Ich hatte heute das Script auf dem Win10 – Rechner meiner Frau angepasst auf 3.2 und erstaunt festgestellt, dass die beiden LW´s C und D doppelt gesichert wurden. Tja, klar – um keine Partition auszulassen, sichere ich HD1:1 bis HD1:7, dabei kommen dann natürlich wiederum „C“ und „D“ vor – war mir vorher nicht bewusst. Aufgefallen ist mir, dass in der Vergangenheit plötzlich eine HD1:xx gefehlt hatte und dafür eine andere gesichert wurde, wobei das Script nur speziell die Partitionen angesprochen hatte, die ich lt. Table zu dem Zeitpunkt eingestellt hatte – das war von Build 1803 auf 1903.

    Nun hat sich schon wieder was geändert mit Build 1909, HD1:5 wurde zu HD1:6 und wieder eine weitere Partition hat sich angefügt HD1:7

    Was passiert da?

    Wenn ich versuche nicht vorhandene zu sichern, passiert eigentlich nur der Abbruch des Versuches, also nicht so schlimm. Insofern wäre es dann vielleicht sinnvoll, den Parameteraufruf der 1.Partition HD1:1 mit –novss zu machen und alle anderen mit HD1:2 ,3 ,4 usw. –Allwriters

    Die Bezeichungen „Full-1-Wochentag_LW“ werden automatisch umgesetzt und geschrieben

    Sinnvoll oder Unsinn?

    Ist das schon einmal beobachtet worden?

    Liebe Grüße und bleib gesund!
    Reinhard

  • Ich lass‘ die Skripte meist als Aufgabe laufen, da gibt’s dann sofern „Mit höchsten Rechten ausführen“ ausgewählt ist keine Schwierigkeiten. Möchte man das Skript manuell starten, geht das natürlich auch, dann sollte man aber am Anfang (nach „@echo off“) noch den Wechsel ins Arbeitsverzeichnis einfügen, z.B.:

    C:
    cd C:Backup

  • > Problem: Sicherungen von HD1:1 … HD1:2 … HD1:3 usw. bis HD1:7

    > Mir ist aufgefallen, dass nach Updates der verschiedenen Builds von Windows 10 urplötzlich eine weitere Partition aufgetaucht ist und umgekehrt auch wieder verschwunden ist. Außerdem hatte sich ebenfalls auch die Reihenfolge geändert.

    Habe ich bislang noch nie gesehen.
    Sind das OEM-Installationen oder selbst/sauber mit Original-MS-ISO installiert?

    > Was passiert da?

    Keine Ahnung, wie erwähnt, habe ich das noch nicht gesehen.
    Relevant ist i.d.R. das die eigentlichen Laufwerke, also C:, z.B. noch D: und was man so hat gesichert sind.
    Die „Boot-Partionen“ kann man zur Not manuell wieder herstellen. Ist aber im Restore-/Recovery-Fall dann nicht gerade mein größtes Hobby. Das macht das Ganze ja auch wieder komplizierter.

    > nsofern wäre es dann vielleicht sinnvoll, den Parameteraufruf der 1.Partition HD1:1 mit –novss zu machen und alle anderen mit HD1:2 ,3 ,4 usw. –Allwriters

    Ist ja bereits so. Die Partionen und Laufwerke muss man immer für den jeweiligen Computer anpassen. Die HD… sind für die Microsoft- und ggf. vorhandene OEM-Partitionen vorgesehen.
    C:, D: etc. dann in der darauffolgenden Zeile.

    Letztlich gibt es verschiedene Möglichkeiten und persönliche Vorlieben wie auch Ansprüche.

    Ich persönlich find es lesbarer und einfacher zu unterscheiden, das die Boot-Partionen mit HD… bezeichnet sind und die System- und Daten-Laufwerke dann eben mit C:, D:, …

  • 1. Werde ich probieren, ein Link auf die Backup.cmd liegt auf dem Desktop, da drückt meine Frau drauf, nachdem sie die Backup-HD eingeschaltet hat…. das nervt aber, wenn jeder Befehl erst bestätigt werden muss, da DS Adminrechte haben will und das entsprechende Fenster aufpoppt… und wenn sie das Bestätigen vergisst, ist nicht alles gesichert und die Meldung bleibt aus 🙁

    2. ist ne OEM-Version mit dem Kauf des Notebooks und ja, in den anderen Partitionen liegen die Rescue Dateien und … ? brauchte ich bisher nicht und hoffe, dass sich das auch nicht ändern wird. Vermutlich könnte ich das plattmachen, da ich System und Daten schon getrennt habe und das Recover somit aller Wahrscheinlichkeit sowieso nicht mehr funktionieren wird. (dafür hat man ja DS)

    HD1:1 = Boot
    HD1:2 = 16MB
    HD1.3= System „C“
    HD1.4= 806MB Microsoft Recovery
    HD1.5= Daten „D“
    HD1.6= 25GB Basic Data, Notebook Firm, Rescue
    HD1.7= 1000MB Basic Data

    … und die Partitionsnamen werden ja auch so geschrieben, wie vorgesehen…

    Danke für die Kommentare

    Gruß Reinhard

  • Was das Admin-Thema betrifft, das ist ja nicht explizit die „Schuld“ von DS, sondern liegt schlicht daran, das DS einen Treiber ausführen möchte und das benötigt seit Windows Vista zwingend erhöhte Rechte.
    Man könnte zwar die UAC (Benutzerkontensteuerung) deaktivieren, damit geht allerdings ein gutes Stück Sicherheit verloren.

    Entweder so testen wie bereits beschrieben.
    Ansonsten, vor sechs Jahren hatte ich mal für einen Kunden mit der gleichen Anforderung (Backup per Doppelklick starten) mittels AutoIt eine Exe gebaut, die explizit zu Beginn der Datensicherung (noch bevor DS startet) die erhöhten Rechte anfordert. Anbei der echt simple Quellcode:

    ; AutoIt TrayIcon ausblenden

    #NoTrayIcon

    ; Erhöhte Rechte anfordern

    #RequireAdmin

    ; Skript ausführen

    Run ("backup.cmd", "", @SW_HIDE)

  • Zum Thema HD1:1, HD1:2 etc. weiter oben:
    Ich verwende HDWIN:* wie hier beschrieben: http://www.drivesnapshot.de/de/commandline.htm
    Damit muss ich mich nicht mehr darum kümmern.

    Hätte aber an Andy eine andere Frage, die nicht direkt mit DS zu tun hat:

    Vorab: Mein Backup-Skript läuft per Aufgabenplanung und nach Reaktivieren aus dem Hibernate.
    Frage: Wie kann ich per Skript sicherstellen, dass eine Freigabe auf der NAS tatsächlich aktiv ist? Mehrfach hat DS moniert, dass Nutzername und Passwort falsch sind, und hat abgebrochen. Dabei hatte die NAS zu lange gebraucht, um hochzufahren, oder Windows, um die Verbindung herzustellen. Das Skript lasse ich eh 60Sek warten, damit alle aufwachen… auch noch nach mehreren Pings, die alle korrekt zurück kamen.

    Habe an sowas gedacht wie:
    :nochmal
    if exist go to ok
    else goto nochmal
    :ok
    sicherung.läuft

    Mit dem Risiko einer Endlosschleife 🙁

    Danke für einen Tipp, wäre sehr hilfreich!
    Bleibt’s alle g’sund!
    Andrei

  • Das Problem mit NAS und Aufwachen ist unabhängig von DS bekannt.

    Probleme beim ersten Zugriff auf USB- oder NAS-Laufwerke nach StandBy

    > Das Skript lasse ich eh 60Sek warten

    An welcher Stelle wird gewartet? Nur Aufgabenverzögerung oder auch innerhalb des Skripts?

  • Hallo Andy,
    die Verzögerung ist am Anfang des Skripts, danach die Pings. Die Aufgabe selbst ist nicht verzögert.

  • Erhöhte Rechte anfordern (Beispiel)

    demnach müsste innerhalb der Script´s folgender Befehl funktionieren (noch nicht probiert), und das für jeden Aufruf von snapshot?

    #RequireAdmin

    ; Skript ausführen

    ; Run („backup.cmd“, „“, @SW_HIDE)

    Run („snapshot64.exe HD1:1 %Destination%Full-%Week%-%Weekday%-$disk.sna -WT –novss -L0 –LogFile:%LogDir%Current.log –CreateDir“, „“, @SW_HIDE)

    da bei mir unter WIN10 jeder Aufruf von snapshot aus dem Backup.cmd die Einforderung der Adminrechte einfordert. Höhere Rechte für das Backup.cmd selbst verhindern leider nicht, dass für snapshot die Rechte vererbt werden, warum auch immer.

  • Hallo Andy,

    Erhöhte Rechte anfordern (Beispiel)

    demnach müsste innerhalb der Script´s folgender Befehl funktionieren (noch nicht probiert), und das für jeden Aufruf von snapshot?

    #RequireAdmin

    ; Skript ausführen

    ; Run („backup.cmd“, „“, @SW_HIDE)

    Run („snapshot64.exe HD1:1 %Destination%Full-%Week%-%Weekday%-$disk.sna -WT –novss -L0 –LogFile:%LogDir%Current.log –CreateDir“, „“, @SW_HIDE)

    da bei mir unter WIN10 jeder Aufruf von snapshot aus dem Backup.cmd die Einforderung der Adminrechte einfordert. Höhere Rechte für das Backup.cmd selbst verhindern leider nicht, dass für snapshot die Rechte vererbt werden, warum auch immer.

  • Das wird so nichts, da min. die Variablen nicht übergeben werden.

    > Höhere Rechte für das Backup.cmd selbst verhindern leider nicht, dass für snapshot die Rechte vererbt werden, warum auch immer.

    Was genau ist damit nun gemeint?

  • ich rufe backup.cmd als Admin auf, aber die Aufrufe innerhalb des Scriptes werden als Admin abgearbeitet und müssen einzeln quittiert werden.

    Wie erwähnt, das passiert nur bei Windows 10, unter Win7 gibt es das Problem nicht.. Ich verzweifle…

    wieso habe ich anscheinend nur das Problem?

  • > ich rufe backup.cmd als Admin auf, aber die Aufrufe innerhalb des Scriptes werden als Admin abgearbeitet und müssen einzeln quittiert werden.

    Ich glaube an der Formulierung stimmt etwas nicht.
    Oder ist mit „als Admin“ aufrufen das Benutzerkonto und nicht die erhöhten Rechten gemeint?

    Also bei mir und meinen Kunden war’s bislang immer so, ganz gleich ob Win 7, 8.x oder 10, das wenn man das Skript mit erhöhten Rechten (Rechtsklick – Als Administrator ausführen) startet, dann alles durchläuft.
    Ein einzelnes Bestätigen oder zusätzliches Bestätigen von DS habe ich bislang nicht beobachtet.

    Wurde denn ggf. etwas an der UAC verändert?

  • mir ist nicht bewusst, ob ich an der UAC generell etwas verändert habe, allerdings habe ich versucht DS speziell mehr Rechte zu verpassen ohne Erfolg, die Abfrage kommt trotzdem immer.

    und ja, oben habe ich mich fasch ausgedrückt, Du hast Recht, „als Administrator ausführen“ und es muss heißen „die Aufrufe innerhalb des Scriptes werden eben nicht als Administrator abgearbeitet.

    Einzelne Programme, z.B. TotalCommander bei Aufruf als Administrator, bringen immer auch die Abfrage, ob ich das auch wirklich will – das nervt, da liegt das Problem. Ich suche gerade anderweitig nach der Lösung. Das muss doch abzustellen sein – aber natürlich nicht generell.

    Wenn ich schon explizit als Admin aufrufen will, wozu dann doppelt gemoppelt… da liegt kaum Sinn drin.

  • Hatte die gleichen Rechte-Probleme mit Server2019, das Script backup.cmd wurde über die Aufgabenplanung gestartet.
    Leider weiß ich die genaue Fehler-Ursache nicht mehr. Laut TE-Software hängt es damit zusammen das alle Befehle mit kompletter Pfad-Angabe erfolgen müssen sonst greifen die Rechte nicht.

    Habe von TE-Software folgende Lösung bekommen:

    Am Anfang des Scripts den Programm-Pfad definieren:
    rem Pfad des Backup-Script Ordners festlegen
    set ScrDir=C:Backup

    Bei allen Befehlen die Variable angeben:
    z.B.:
    %ScrDir%Toolsweekday.exe > %ScrDir%weekday.txt
    set /p Weekday=< %ScrDir%weekday.txt

    oder
    %ScrDir%snapshot.exe HD1:1 %Destination%Diff-%Week%-%Weekday%-$disk.sna -h%Destination%Full-%Week%-%FullBackupDay%-$disk.hsh -W –novss -L0 –LogFile:%LogDir%Current.log –CreateDir –FullIfHashIsMissing

    Damit läuft das Script durch.

  • Das hatte ich bei Server 2019 bislang nicht.
    Wobei ich dazu sagen muss, das ich bei der Aufgabe immer auch „Ausführen in“ ausgefüllt habe. Mache seit Windows Server 2003 so, bislang immer ohne Überraschungen.

  • ohjee, wenn eines klappt, dann läuft was anderes nicht 🙁

    also:

    unter Totalcommander oder Windows Explorer mit Adminrechten IM Backup Verzeichnis aufgerufen, läuft das Script jetzt durch!

    zusätzlich habe ich nach einiger Suche folgende Anleitung für die Rechtevergabe unter Win10 Build 1903/1909 gefunden und Adminrechte für snapshot64.exe (im Backuppfad) erteilt. Dazu ist erforderlich, die aktuelle Windows ADK zu installieren und dem Tipp zu folgen – läuft soweit…

    https://www.deskmodder.de/wiki/index.php/UAC_Benutzerkontensteuerung_deaktivieren_einstellen_Windows_10

    ABER, dann kommt das nächste Problem:
    um meiner Frau es so einfach wie möglich zu machen, hatte ich auf die backup.cmd eine Verküpfung angelegt. Der einfache Aufruf bringt denselben Fehler der Bestätigungsaufforderung nach jedem Befehl, funktioniert also nicht trotz Rechtevergabe, Mist.

    Die Ausführung der Verknüpfung mit Adminrechten hat dann aber das nächste Problem:
    Die cmd wird nicht im Backup-Pfad (obwohl mit cd.. innerhalb angegeben!) ausgeführt, sondern in Windowssystem32 !! und damit stimmen die Pfade nicht mehr…

    Nun, jetzt mache ich´s doch über den Aufgabenplaner mit Adminrechten, und ja, es MUSS und kann der Ausführungsordner angegeben werden – jetzt läuft das Script tatsächlich durch.

    Aufgabe für meine Frau ist halt, montags für´s Vollbackup vor Rechnerstart ERST die Backup-Platte in Betrieb zu nehmen und dann auf die Ausführung warten.

    Vermutlich hätte ich jetzt gar nicht die ADK installieren müssen und mich gleich mit der Aufgabenplanung beschäftigen sollen…

    Warum muss das nur soooo kompliziert sein

    Erstmal vielen Dank für Eure Unterstützung und bleibt gesund!

    Gruß Reinhard

  • Hallo Andy,
    hier ist ein Problem, das ich nicht verstehe und extrem nervt.
    Bei mir läuft wochentags um 22:30 ein differentielles und sonntags ein volles Backup, jeweils von drei Festplatten C, D, E auf ein Netzlaufwerk von QNAP . Während unter der Woche alles glatt läuft, bricht das sonntägliche öfters mal mit der Fehlermeldung „Netzwerk überlastet“ ab. Dabei läuft nichts ab, was nicht auch unter der Woche mal abläuft: Ein TV-Film wird aufgenommen under angeschaut. Das dürfte nicht zu solch einem Abbruch führen.
    Das Nervige daran ist, dass der PC dann die ganze Nacht durchläuft, ohne die Sicherung zu machen.

    Meine Vermutung ist, dass Windows irgendwas tut, was ich nicht sehen und kontrollieren kann. Mit den Tools procmon und procexp64 könnte jemand, der sich besser auskennt, nachvollziehen, was los ist – ich nicht.

    Hier die Kommandozeilen, die ich für die Sicherung verwende, je nach Tag (%DOF% – Tag des Full Backup, %DOW% – Tag des Diff. Backup)

    Full backup:
    C:\Snapshot\snapshot64.exe HDWIN:* %Snap_destination%\Full-%DOF%-$disk.sna -RW -Go –AllWriters -L0 –LogFile:%LogDir%\Current.log –CreateDir –exclude:%exclude%

    Diff backup:
    C:\Snapshot\snapshot64.exe HDWIN:* %Snap_destination%\Diff-%DOW%-$disk.sna -h%Snap_destination%\Full-%DOF%-$disk.hsh -RW -Go –AllWriters -L0 –LogFile:%LogDir%\Current.log –CreateDir –exclude:%exclude% –FullIfHashIsMissing

    Windows 10 Pro 1909, 2x3TB QNAP NAS, Cat6 Ethernet Kabel.

    Netzwerk ausgelastet? Bullshit!!!

    Danke für Ideen,
    Andrei

  • Hallo Andrei,

    kann an Windows, Virenscanner, etc. hätte da aber vielleicht noch ein-zwei weitere Ideen:

    Wenn die Datensicherung schon recht früh abbricht, dann könnte das evtl. daran liegen, das die Festplatten im NAs noch nicht wieder angelaufen sind und es daher zu einem Fehler kommt.
    Helfen kann zunächst irgendwie die Festplatten im NAS durch eine Aktivität auufzuwecken und erst dann die eigentliche Datensicherung durchzuführen:

    Siehe dazu auch: Probleme beim ersten Zugriff auf USB- oder NAS-Laufwerke nach StandBy

    Statt timeout kann man auch ping oder ein (externes) sleep verwenden.

    Was auch sein kann: Die Datensicherung ist zu schnell für das Netzwerk oder das Ziel oder es kommt irgendwo zu einem Puffer-Überlauf und ähnliches. Abhilfe kann bringen, die Datensicherung etwas zu bremsen:

    Siehe Drive Snapshot: Der angegebene Netzwerkname ist nicht mehr verfügbar

    Immer eine gute Idee ist Drive Snapshot als Ausnahme im Virenschutz zu hinterlegen.
    Ansonsten mal das das Log posten, damit man evtl. weitere Rückschlüsse ziehen kann.

  • Hallo Andy,
    danke für die Anregungen insoweit.
    Die Sache liegt wohl doch etwas tiefer:
    – ich habe keinen Virenscanner installiert, sondern nur die Bordmittel von Windows
    – der Fehler kommt meistens nach mehreren Dutzend bis Hundert GB Datentransfer vor, z. B. erst bei Laufwerk E:, manchmal schon bei 50-60 GB von C:, aber nie gleich zu Beginn
    – ich stelle mit folgender Sequenz sicher, dass die Verbindung zur NAS vorhanden ist; einmal wurde der counter bis 2 erhöht:
    set cnt=1
    :check_net
    if exist „\\qnas\backup“ (goto do_backup
    ) else (
    START /wait NET USE \\QNAS\Backup [password] /user:andrei /PERSISTENT:YES
    if %cnt% EQU 5 (goto err)
    set /a cnt=%cnt%+1
    goto check_net
    )

    Ich werde aber die Option –LimitIORate:XX ausprobieren, mit XX==50.
    Damit weiß ich aber immer noch nicht, woran das wirklich liegt. Die Differential-Sicherungen laufen immer zuverlässig durch. Ich würde soo gerne eines der tools verwenden können, um zu sehen, was zum Zeitpunkt des Fehler noch alles los ist…

    Zu guter Letzt ein Auszug aus dem Log, Snapshot Exit nach 35960047 milliseconds am nächsten Morgen!!!

    ———————
    22:31:48 Start VSS backup of C: -> \\QNAS\Backup\Full-0-C.sna
    Backup on ANDREI-MIFCOM started at Sun Aug 02 22:31:49 2020

    22:31:49 free space info: total 1.228GB, 1.011GB free, 196.757MB must be saved
    22:39:19 ***********************************************************
    22:39:19 Snapshot error NTCOPY, line 822
    22:39:20 could not write 1048576 of 1048576 bytes at filepos 34.886.656K
    22:39:20 last Windows Error: 36-Das Netzwerk ist ausgelastet.
    08:38:20 ***********************************************************
    08:38:20 last write operation needs 35960047 milliseconds
    08:38:21 operation aborted
    08:38:22 Backup of C: aborted
    08:38:22 Deleting previously generated shadow copy
    08:38:22 Unregister shadow copy {d8652d52-bdb2-4121-85a5-097e8d6f712b}
    08:38:24 Unregister shadow copy {1bdc3d72-c413-4113-827b-4f90a07b98a9}
    08:38:24 Unregister shadow copy {b6047f47-0491-454e-85ba-e0454ee007de}

    Some error occurred – exitcode 1
    08:39:16 Error occurred – exitcode 1
    08:39:16 End of Snapshot 1.45 [Mar 17 2017] at 03.08.2020
    ________________________

  • Ob das deinen Fehler behebt weis ich nicht. Aber ich verwende für eine Sicherung immer den ftp Pad. Das geht reibungslos und vor allem sicher da Passwörter im script stecken und Viren zu keinen Zeitpunkt über Samba Zugriff bekommen.

  • Wenn man nach dem Fehler 36 sucht findet sich leider nicht allzuviel, aber interessanterweise meist im Zusammenhang mit NAS und Samba-Servern. Könnte also irgendwie mit Samba zu tun haben. Evtl. mal schauen ob man beim NAS die SMB-Version ändern kann, damit man das Ganze vielleicht eingrenzen kann.

    Was steht denn im Log des NAS zum Fehlerzeitpunkt?

    Da Fehler 36 auf ein I/O-Problem hinweist hat man mit -–LimitIORate:XX gute Chancen das in den Griff zu bekommen.

  • Hallo Andy,
    die Idee mit -–LimitIORate:XX hat das Problem offensichtlich gelöst, vielen Dank!

    Jetzt habe ich ein ganz anderes Problem entdeckt.
    Nach der Installation von Windows 2004 habe ich eine weitere Partition auf C: gefunden. Ich habe nachgelesen und es heißt, die Reihenfolge der Partitionen entspricht nun den Regeln von Microsoft.
    Bei mir ist das nun so angeordnet:
    (alte)Wiederherstellung-EFI-Systempartition-Startpartition(C:)-(neue)WIEDERHERSTELLUNG-D:-E:
    Es soll aber so sein:
    Microsoft empfiehlt hingegen folgende Reihenfolge: EFI, MSR, Betriebssystem und Wiederherstellung.

    Die zweite Wiederherstellungs-P. ist bei mir hinzugekommen.

    Das hat mit der Snapshot-Sicherung nun dieses zu tun: Bei einem Restore müssen die Partitionen exakt übereinstimmen, sonst klappt es nicht.

    Was würdes Du empfehlen:
    a) eine Full-Sicherung mit der jetzigen Konfiguration zu machen und sonst nichts anfassen, das wäre wirklich ein Schnappschuss des Ist-Zustandes mit einer überzähligen Wiederherstellungs-P., die bleibt dann als Leiche liegen
    b) versuchen, die alte Wiederstellungs-P. zu entfernen (WIE?) und dann erst wieder eine Full-Sicherung zu machen
    oder c) ????

    Was soll ich tun?

  • > Nach der Installation von Windows 2004 habe ich eine weitere Partition auf C: gefunden.

    Eine weitere Partition auf C: ?
    Gemeint ist wohl eine weitere Partition auf der Festplatte oder SSD.

    Bei bestehenden Installationen oder durch den Computerhersteller irgendwie abgepasste Geschichten entspricht die Reihenfolge, Größe, etc. oft nicht den Wünschen aus Redmond.
    Solange alles funktioniert ist das (imho) auch erstmal kein Problem.

    > Das hat mit der Snapshot-Sicherung nun dieses zu tun: Bei einem Restore müssen die Partitionen exakt übereinstimmen, sonst klappt es nicht.

    Nicht unbedingt.
    Man kann genauso gut Windows neu installieren und dann nur C: restoren und das läuft dennoch (ist hier im Blog mehrfach beschrieben).

    Genau genommen braucht man nicht alle Partitionen zu sichern, mindestens sollte es C: sein und, sofern vorhanden, noch Daten-Partitionen.

    Der Einfachheit halber und damit der Restore ohne Umwege klappt sichere ich i.d.R. alle Partitionen.

    Laut Tom Ehlert Software macht das nicht unbedingt Sinn, da es auch leere (RAW) Partitionen gibt, Schaden tut’s allerdings auch nicht.

    Wenn man genau Wissen möchte, welche Partitionen es gibt und wie diese richtig für Drive Snapshot (im Skript oder CLI) benannt sein müssen ruft man am einfachsten Drive Snapshot wie folgt auf:

    snapshot.exe --showlist
    bzw.
    snapshot64.exe --showlist

    Die Ausgabe sieht dann beispielsweise so aus:

    C:\Users\test\Downloads>snapshot64.exe --showlist
    22:55:19 Timelimited TrialWare - use possible up to 10.09.2020
    C: FIXED primary 3 NTFS 254746292224 240123904 Windows
    HD1:1 FIXED primary 1 FAT32 100663296 1048576 SYSTEM
    HD1:2 FIXED primary 2 RAW 0 105906176
    HD1:4 FIXED primary 4 NTFS 1073737728 254986420224 Recovery

Schreibe einen Kommentar

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