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_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, 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
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.
Artikel (RSS)
XING
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:Snapshotsnapshot64.exe HDWIN:* %Snap_destination%Full-%DOF%-$disk.sna -RW -Go –AllWriters -L0 –LogFile:%LogDir%Current.log –CreateDir –exclude:%exclude%
Diff backup:
C:Snapshotsnapshot64.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 “\qnasbackup” (goto do_backup
) else (
START /wait NET USE \QNASBackup [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: -> \QNASBackupFull-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 --showlistbzw.
snapshot64.exe --showlistDie Ausgabe sieht dann beispielsweise so aus:
C:UserstestDownloads>snapshot64.exe --showlist22: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
Hallöchen,
ich würde mich freuen, falls jemand mir mal Denkanstöße geben könnte.
Geplant ist, mithilfe dieses Skript (Danke an Andy, für dieses tolle Stück Skript) eine Kalenderwoche auf ein externes Medium (RDX) zu sichern. Von den externen Medien soll es vier Stück geben, um theoretisch jeden einzelnen Tag des Montags wiederherstellen zu können.
Müsste “NumberOfWeeksToKeep” dann 1 sein und spielt es in diesem Fall eine Rolle, was in der Week.txt steht?
Wäre bei diesem Konstrukt auch eine Fehlertoleranz gegeben, falls die externen Medien mal “falsch” eingelegt würden?
Falls sich jemand die Mühe machen sollte, sich in dieser Sache reinzudenken und zu antworten, dann möchte ich mich vorab dafür bedanken.
Beste Grüße.