In den Kommentaren zu Windows 8.1: Wiederherstellungslaufwerk inkl. Drive Snapshot erstellen kam von Andrei das Thema auf, in wie weit die hier genannte Lösung mit Windows 10 funktioniert.
Eigentlich hat sich nichts geändert …
… und das trifft auch so zu. Die Skripte der Windows 8.1-Variante laufen 1:1 unter Windows 10. Einzig ein paar “Kleinigkeiten” sind aufgefallen, die in die nachfolgende aktualisierte Anleitung eingeflossen sind:
Eines vorab: Im Beitrag wird von der Standard-Partitionierung seitens Microsoft ausgegangen. Je nach Computerhersteller oder Vorlieben des Anwenders kann sich diese unterscheiden.
Vorbereitung
- Nur notwendig, wenn man nicht die Dism-Variante verwendet: Installiertes 7-Zip (min. 9.38 beta oder neuer, Hintergrund siehe Mit 7-Zip WIM-Abbilder bearbeiten).
- Das Archiv ds-rescue_w81_winre_10 herunterladen und den Inhalt in einen Ordner, z.B. „C:\Temp“, entpacken.
- Eine Eingabeaufforderung mit erhöhten Rechten starten.
- Mit folgenden Befehlen die Wiederherstellungspartition ermitteln und einen Laufwerksbuchstaben zuweisen:
diskpart select disk 0 (vorausgesetzt Windows ist auf der ersten Festplatte installiert, andernfalls mittels "list disk" die Festplatte ermitteln) list volumes select volume 2 (die Nummer angeben, die der 500 MB großen Wiederherstellungs- bzw. "System-reserviert"-Partition entspricht) assign (es wird der nächste freie Laufwerksbuchstabe zugewiesen) exit
Da sowohl das Verzeichnis als auch die Datei „Winre.wim“ mit dem Attribut „Versteckt“ versehen sind, wird im Explorer per Standard nichts angezeigt. Im Skript muss normalerweise nur der Laufwerksbuchstabe zu dieser Datei angepasst werden (siehe nächster Punkt).
- Das Skript „create_winre_7-Zip.cmd“ oder „create_winre_dism.cmd“ editieren und im Abschnitt „Konfiguration“ ggf. folgende Zeilen anpassen:
rem Konfiguration rem WorkingDir set WorkingDir=C:\Temp cd %WorkingDir% rem Pfad zur "Winre.wim" set Winre-Path=F:\Recovery\WindowsRE rem Pfad zu 7-Zip und verwendete Exe-Datei set SevenZip=%ProgramFiles%\7-Zip\7z.exe
Wenn man im Besitz einer Drive Snapshot-Lizenz ist, so kann man die Lizenzdatei in den Ordner „Rescue\Drive Snapshot“ einfügen (Windows: Drive Snapshot aktivieren ohne Einfügen der Lizenzdaten).
Angepasstes Wiederherstellungslaufwerk erstellen
Das Skript „create_winre_7-Zip.cmd“ oder „create_winre_dism.cmd“ mit erhöhten Rechten (Rechtsklick – „Als Administrator ausführen“) starten. Es öffnet sich ein Fenster der Eingabeaufforderung in dem das Skript abläuft, relativ kurze Zeit nach dem Start öffnet sich der Assistent zur Erstellung des Wiederherstellungslaufwerks:
Wichtig: Den Haken bei “Sichert die Systemdateien auf dem Wiederherstellungslaufwerk.” entfernen.
ACHTUNG: Das USB-Laufwerk wird vom Assistenten formatiert! Es sollten sich folglich keine (wichtigen) Daten darauf befinden.
Wurde der Stick erfolgreich erstellt, so kann man von diesem Booten und gelangt in folgendes Menü. Die Original-Rettungsumgebung (RE) von Microsoft erreicht man über den Menüpunkt 13. Um wieder ins “Rescue Menu” zu wechseln kann man entweder aus dem RE heraus eine (weitere) Eingabeaufforderung öffnen oder “Alt+Tab” drücken und die bereits geöffnete Eingabeaufforderung (diese beinhaltet das “Rescue Menu”) auswählen.
Bemerkung
Ungetestet ist MergeIDE, ferner kann ich außer einem kurzen Test nicht genau sagen, in wie weit Drive Snapshot mit Windows 10 kompatibel ist.
Seit Windows 8.x habe ich den Eindruck, das sich Windows meist ohne MergeIDE auf andere Hardware umziehen lässt. Das kann aber evtl. auch nur Zufall oder Glück sein.
Im Gegensatz zu früheren Versionen hatte ich diesmal keinen Erfolg, den Assistenten “auszutricksen”, es wird zwingend ein USB-Stick benötigt. Unter VirtualBox und VMware kann man USB-Geräte durchreichen. Mit erstgenannten hatte ich allerdings auf einem Lenovo ThinkPad T410 keinen Erfolg, erst auf unserem älteren Fujitsu Notebook in der Werkstatt war das kein Problem.
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
Hilfe!!! Thema ein wenig off-topic, aber bitte um Nachsicht…
ich habe diese Methode per USB-Stick vor gut einem halben Jahr erfolgreich !! eingesetzt, jetzt habe ich wieder einen Notfall – kann aber mein NAS-Laufwerk mit Menupunkt 3 nicht einbinden. Das Netzwerk wird initialisiert, die IP-Adresse ist definitiv korrekt, habe sie von einem anderen PC aus verifiziert. Bei “Mapping a network drive” heißt es nach Server (IP-Address or Computername” – mit und ohne Benutzer/Kennwort, egal! immer “Der Netzwerkname wurde nicht gefunden”. Komme an die Sicherung nicht heran 🙁
Anbei ein paar Fragen:
– 7-Zip- oder dism-Variante?
– Welche Windows 10-Version und -Edition dient als Basis?
– Funktioniert ein Ping zum Router oder NAS?
Evtl. mal per “net use” in der Eingabeaufforderung das Ganze per Hand testen
Plan B wäre, die Sicherung von einem anderen PC aus vom NAS auf eine USB-Festplatte zu kopieren und von dort die Wiederherstellung starten.
Dankeschön. Ich habe Windows 10 pro vom Sommer 16. Die Sicherung ist 600+ GB groß, also ist Plan B keine Option, leider. Ich werde Windows neu aufsetzen, einfach um wieder Zugriff auf die NAS zu bekommen, und Snapshot dann ausführen, damit alles überschreiben. Warum die IP nicht angenomen wird verstehe ich nicht, die NAS ist von zwei anderen PCs aus sichtbar.
Jedenfalls danke!
Mit net use hat’s geklappt! Uff. Jetzt läuft der restore. Herzlichen Dank!
Seltsam, sollte eigentlich keinen Unterschied machen und bislang gab es bei mir zumindest keine Probleme, aber gut das es auf Umwegen funktioniert.
ich wollte gerade das File ds-rescue_w81_winre_10.zip downloaden, leider funktioniert der download nicht mehr, könnten sie mir evtl. helfen?
Jetzt funktioniert es wieder 😉
super, vielen herzlichen Dank 🙂
Hallo Andy!
Ich habe versucht mit einer frisch installierten 1809 von Win 10. Einen BootStick mit Drive Snapshot zu erzeugen.
Leider immer mit dem Ergebnis,dass recoverywindowsre
nicht gefunden wird.
Ich habe mehrfach überprüft ob der LW Buchstabe korrekt zugewiesen ist. ME ist das so. Leider immer wieder der gleiche Fehler.
Ich habe es dann nochmals auf einem anderen Rechner probiert, leider mit dem gleichen Ergebnis! Was mache ich falsch?
Danke für die Hilfe im voraus!
Hallo Ralf,
auf meiner Testmaschine habe ich das dism-Skript gerade erfolgreich durchlaufen lassen.
Anbei ein paar Fragen:
Welches Skript wurde verwendet (dism/7-Zip)?
Möglicherweise die falsche Partition benutzt?
Wann kommt die Meldung, das “recoverywindowsre” nicht gefunden wurde?
Bitte mal die Ausgabe vom Skript posten.
Bitte mal die Ausgabe von “diskpart – lis vol” posten.
Auf meiner Testmaschine sieht das so aus:
DISKPART> lis volVolume ### Bst Bezeichnung DS Typ Größe Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D CD 0 B Kein Medi
Volume 1 System-rese NTFS Partition 549 MB Fehlerfre System
Volume 2 C NTFS Partition 79 GB Fehlerfre Startpar
Mit “sel vol 1” die Partition markieren und mit “assign” einen Laufwerksbuchstaben zuweisen.
Es erscheint kurz ein Popup das ein Laufwerk verbunden wurde. In meinem Fall ist das dann “E:”.
Mit “dir e: /ah” bekommt man den versteckten Inhalt dieses Laufwerks angezeigt. Die Ausgabe sollte in etwa so aussehen:
C:Windowssystem32>dir e: /ahDatenträger in Laufwerk E: ist System-reserviert
Volumeseriennummer:
Verzeichnis von E:
07.11.2018 19:10 Boot
20.09.2018 05:29 407.254 bootmgr
12.04.2018 00:34 1 BOOTNXT
07.11.2018 14:49 8.192 BOOTSECT.BAK
07.11.2018 14:51 Recovery
26.02.2019 08:59 System Volume Information
3 Datei(en), 415.447 Bytes
3 Verzeichnis(se), 150.114.304 Bytes frei
Sieh man diesen Inhalt, vorallem den Ordner “Recovery” ist soweit alles gut, wenn nicht, dann ist’s die falsche Partition.
Bei manchen OEMs fehlt allerdings die “System-reserviert”-Partition, meist gibt es dann nur ein Laufwerk “C:”.
Wiederum bei anderen kann die Partition größer oder kleiner sein, am Anfang oder Ende der HDD/SSD liegen.
Im Zweifelsfall muss man erstmal suchen.
Nun passt man den Laufwerksbuchstaben im Skript “create_winre_.cmd” an und führt dieses mit erhöhten Rechten aus.
Die Ausgabe von der dism-Variante sollte in etwa so aussehen:
C:Temp>create_winre_dism.cmdDownloading...
Download complete.
1 Datei(en) verschoben.
1 Datei(en) kopiert.
1 Datei(en) verschoben.
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.17134.1
Abbild wird bereitgestellt
[==========================100.0%==========================]
Der Vorgang wurde erfolgreich beendet.
1 Datei(en) kopiert.
Rescuerescuemenu.cmd
RescueDrive Snapshotds-update_amd64.au3
RescueDrive Snapshotds-update_amd64.exe
RescueDrive Snapshotds-update_x86.au3
RescueDrive Snapshotds-update_x86.exe
RescueDrive Snapshotdsmenu.cmd
RescueDrive Snapshotsnapshot64.exe
RescueMergeIDEMergeIDE-AHCI-001.reg
RescueMergeIDEMergeIDE-AHCI-002.reg
RescueMergeIDEMergeIDE-AHCI-003.reg
RescueMergeIDEMergeIDE_v30.cmd
11 Datei(en) kopiert
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.17134.1
Abbild wird gespeichert
[==========================100.0%==========================]
Bereitstellung des Abbilds wird aufgehoben
[==========================100.0%==========================]
Der Vorgang wurde erfolgreich beendet.
1 Datei(en) verschoben.
1 Datei(en) verschoben.
Vor dem letzten “Datei verschoben” öffnet sich der Assi zum Erstellen des Sticks.
Hallo Andy!
Danke für die superschnelle Antwort!
Bei mir lag die winre.wim unter windowssystem32recovery. Damit lief das Script dann fehlerfrei durch. (Kaum macht man es richtig funktionierts).
Jetzt hab ich aber ein anderes Problem.
Der Stick bootet und versucht das Rescuesystem zu starten. Dann erscheint für eine Sekunde das Menü und anschließend ein blauer Screen vom Windows Rescue System wo ich eine Sprache auswählen könnte. Dann geht nichts mehr. 🙁
Kannst du mir nochmal helfen?
Danke wieder im voraus!
Unter “windowssystem32recovery” liegt bei mir keine WinRe rum, ist wohl Computer- bzw. OEM-abhängig sein.
Unter 1803 klappte das Ganze noch, unter 1809 fehlt in der Tat unter “E:Recovery” die “Winre.wim”.
Auf meiner Testbüchse finde ich nirgends eine “Winre.wim”, mit Ausnahme im “Backup” der 1803-Installation:
Verzeichnis von C:Windows.old$WINDOWS.~BTSourcesSafeOS26.02.2019 10:56 485.137.643 winre.wim
1 Datei(en), 485.137.643 Bytes
Ich frage mich gerade, auf was denn nun der Recovery-Assi basiert oder ob dieser überhaupt noch erfolgreich einen Stick erstellen kann.
Da meine Testbüchse eine VM ist, kann ich das gerade nicht prüfen.
So, die VM hat dann doch endlich einen USB-Stick “angenommen”, daraufhin habe ich mal “recoverydrive.exe” laufen lassen und mittels Ressourcenmonitor beobachtet.
Ich spekuliere darauf, das der Assi sich eine eigene Wim baut und dann auf den Stick schreibt.
Während des Durchlaufs sieht man bei der Datenträgeraktivität das da einiges passiert, da tauchen dann auch gleich mehrere Wim-Dateien auf (winre.wim, recontruct.wim, boot.wim).
Da ich diese zuvor und auch danach nicht auf dem System finden konnte, sind diese entweder gut versteckt, werden nur während der Assi läuft erzeugt oder ich hab’ sie schlichtweg übersehen.
Auf jeden Fall scheint der aus dem Assi resultierende Boot-Stick im Gegensatz zu früher stärker vom Quell-PC personalisiert zu sein.
Wenn der Stick irgendwann mal fertig ist, das schneckt hier gerade rum, dann schaue ich mal, ob man als Plan B diesen dann für Drive Snapshot anpassen kann.
Es hat Stunden gedauert, aber der Stick ist fertig. Nach erster Durchsicht, ohne davon zu booten, lässt sich sagen das es im Gegensatz zur WinRE.wim ganz anders ist. Eine informative Grundlage bietet folgender Link:
Dr. Windows – Windows 10 – System und Sicherheit/Wiederherstellung
Ich muss zugeben, ich hatte die Entwicklung des Assi’s nicht verfolgt.
Unter Windows Server 2019 gibt’s die WinRE noch, da klappt das Ganze nach wie vor.
Hallo Andy! Danke für deine Mühe!
Heisst das man muß den Stick für Drive Snapshot jetzt auf dem Server erstellen weil die neueren Win10 Builds inkompatibel für die DriveSnapshot-Stick erstellung sind?
Ich kriege nach wie vor keinen funktionierenden Stick zustande. Das Menü erscheint ganz kurz, dann kommt ein blauer Bildschirm wo ich eine Sprache auswählen kann und das war’s! 🙁
Hallo Ralf,
> Heisst das man muß den Stick für Drive Snapshot jetzt auf dem Server erstellen weil die neueren Win10 Builds inkompatibel für die DriveSnapshot-Stick erstellung sind?
Nein, aber ist eine Option.
Ganz klassisch wäre der Weg über WinPE, das es mittlerweile einzeln (außerhalb des ADK) gibt.
Ich habe vor dazu einen Beitrag zu machen und die Skripte entsprechend zu aktualisieren.
Aus zeitlichen Gründen bin ich dazu noch nicht gekommen, in Vorbereitung ist es aber schon.
Hallo Andy,
habe gerade Deine Antwort auf
https://www.andysblog.de/windows-8-1-und-10-wiederherstellungslaufwerk-um-drive-snapshot-erweitern
gelesen, wahrlich eine schlechte Nachricht. Gibt es denn gar keine Möglichkeit, Snapshot64 und die Lizenzdatei auf einen Recoverystick zu bringen und von dort aus zu starten? Der alte, verlorene Stick hat mir schon zweimal aus der Not geholfen! Wenn das nicht geht, nützt mir das schönste Backup auf dem Netzlaufwerk nichts mehr :-((
Die Hoffnung stirbt zuletzt… hier ist sie angebracht…
Grüße,
Andrei
Leider weiß ich nicht, ob man das mit dem Recovery-Stick nochmal irgendwie zum Laufen bekommt.
Wenn ich mal wieder mehr Zeit habe, schaue ich mir das gerne nochmal an.
Der klassische Weg via WinPE oder Setup-Stick funktioniert nach wie vor, soweit mir bekannt ist.
Wenn das Menü nicht so relevant ist, dann kann man Drive Snapshot auch vom Setup-Stick direkt starten.
Setzt halt voraus das man sich via CMD “durchhangelt”.
Ansonsten gibt es ja noch das Notfalls-/Rettungs-Windows von heise-ct:
c’t-Notfall-Windows 2019
und/oder diverse andere Tools um seine eigene Variante bauen zu können:
Win10PE SE, Win10XPE, WinBuilder, etc.
Win10PE SE
So, mal in einer Werbepause mit Win10XPE was gebaut:
Mit Win10XPE auf die Schnelle ein Drive Snapshot-Rettungsmedium erstellen
Seit Jahren verwenden wir Drive Snapshot für die tägliche Sicherung und auf Win 7 lief es immer einwandfrei. Nun haben wir vor 6 Monaten auf neue Hardware mit Win 10 Pro 64-Bit migriert (alles neu aufgesetzt) und auch die snapshot.exe in der aktuellen Version installiert.
Die ersten 2-3 Wochen lief die Sicherung auch problemlos.
Dann gingen die Probleme los: urplötzlich kamm es zwischen Sicherung und Validate zum Bluescreen. Das Ereignisprotokoll von Windows hat nichts protokoliert.
Da wir die identische Hardware als Backup nochmal vorrätig hatten, habe ich das System auf der Ersatzhardware komplett neu aufgesetzt.
6 Monate lief die Sicherung dann ohne Probleme. Jetzt taucht das gleiche Problem wieder auf. Mit dem Support von Drive Snapshot habe ich Kontakt aufgenommen. Sie können sich aber auch keinen Reim drauf machen.
Ich habe alles ausprobiert: unterschiedliche USB-Festplatten an unterschiedlichen Ports, aufruf manuel statt über die Aufgabenplanung, vor der Sicherung einen Reboot; nichts hilft.
Manchmal läuft die Sicherung 1-2 Tage und dann steigt sie wieder aus.
Aufrufparameter: “c:snapshotsnapshot HD1:* e:image-$disk.sna –novss –LOGFILE:C:snapshotsnapshot.log -w -t”
Gesichert wird eine SSD. Und die Daten werden auch gesichert. Das Wiederherstellen eines Systems klappt anstandslos, auch wenn der Programmabbruch erfolgt ist!
Das einzige was auffällt, sind die Hinweise auf Leseverzögerungen beim Sichern in dem snapshot.log –>
14:36:04 12 sectors need more than 200ms to read
14:36:04 1065 sectors need more than 100ms to read
Das ganze System läuft aber sonst einwandfrei. SSD-Testprogramme liefern allerdings keine Hinweise auf Probleme mit der SSD und auch die Ereignisanzeige von Windows liefert keine diesbezüglichen Hinweise.
Hat jemand noch eine Idee?
Danke.
Hallo Dirk,
BSOD mit Drive Snapshot hatte ich bislang nicht oder es ist so lange her, das ich mich nicht mehr daran erinnern kann.
Die Leseverzögerungen sind imho allerdings seltsam. Das kenne ich bislang eher von fehlerhaften Festplatten, die zwar laut SMART und chkdsk/HD Tune/etc. fehlerfrei sind, aber dennoch in Sachen Performance einbrechen oder gar hängen bleiben, dann ist das Risiko für einen Bluescreen recht hoch.
Ich gehe mal davon aus, das vom Support auch mal der Parameter “–LimitIORate:XX” ins Spiel gebracht wurde + evtl. weitere Undokumentierte (Hr. Pawletta hat da einiges auf Lager).
Ist denn Drive Snapshot im Virenschutz als Ausnahme definiert?
Vor Jahren gab es da mal Schwierigkeiten, kommt aber auch ganz auf den Virenschutz darauf an.
Was sind denn das für Systeme (Hersteller, Modell) und welcher Virenschutz wird verwendet?
Wurde zumindest testweise mal via LAN gesichert?
Vor einer Weile hatte ich mit so mancher USB3.0-Controller/-Festplatten-Kombination Schwierigkeiten, abhilfe schaffte dann die Sicherung auf ein NAS.
Danke Andy, ich werde deinen Tips mal nachgehen und berichten.
Virenschutz ist AVAST Freeware
System ist AMD A8-9600 Radeon R7, 10 Compute Cores 4c +6G (4CPUs), 3,1 GHz, 8GB Ram
HD Apacer AS350 240GB
Mit Avast und AMD habe ich generell viele schräge Dinge erlebt.
Auf jeden Fall die “snapshot.exe” bzw. “snapshot64.exe” als Ausnahme festlegen.
Zudem prüfen, ob alle Treiber aktuell sind.
Hallo Andy,
hier berichte ich von einem sonderbaren Verhalten von Snapshot und meinem Netzlaufwerk.
Ich sichere alle Partitionen einer 4TB-Platte mit HDWIN:*
Das Laufwerk C: wird mit ca 1,5-1,7 Mbit/s gesichert, die anderen D: und E: mit ca 9-10 Mbit/s.
C: ist 73% frei, D: ca 97%, E: ca 87%. lt. Datenträgerverwaltung. Alle haben die gleiche Kapazität von 1241,81 GB.
Wie ist der Unterschied in der Geschwindigkeit zu erklären??
Es wirkt sich sehr auf die Dauer des Backups aus.
Danke für einen Tipp,
Andrei
Hallo Andrei,
es kann verschiedene Gründe hierfür geben, wie z.B. Fragmentierung, Weg zum Ziel (LAN/WLAN), Sicherung mit/ohne Schattenkopie, Voll- oder Differenzsicherung, usw.
Nach Möglichkeit mal ein Log und das zugehörige Backup-Skript oder die Einstellungen posten.
Hallo Andy,
klar, einige Infos fehlten, hole sie hier nach.
– Fragmentierung: eingebaut ist ein Intel Optane-Chip, daher ist Fragmeniterung meines Wissens kein Thema
– Weg zum Ziel ist LAN
– VSS: s. Log einer Diff-Sicherung. Erfolgt jeden Tag und ist nummeriert je nach Wochentag.
– Voll/Diff macht keinen Unterschied. Im Log sieht man ein Problem mit Unmount. C: hat über eine Stunde gebraucht, D: und E. nur Minuten
===========Log-File=============
21:00:54 Start of Snapshot 1.50.1093 [Feb 21 2023] at 21.02.2024
21:00:54 Running on Windows 8 Professional 64-bit (9200)
21:00:54 Memory Info: Total: 8038Mb, Free: 4586Mb, Pagefile total: 16230Mb, Pagefile free: 13124Mb
21:00:54 Command line: C:DownloadsBackup_SoftwareSnapshotExe-Cmdsnapshot64.exe HDWIN:* \QNASBackupDiff-3-$disk.sna -h\QNASBackupFull-0-$disk.hsh -RW -Gx –AllWriters -L0 –LogFile:C:DownloadsBackup_SoftwareSnapshotExe-CmdLogsCurrent-3.log –CreateDir –FullIfHashIsMissing –Printtotals
21:01:20 clearing Recycle Bin on drive C: – 0 Files, 0 Bytes
21:01:20 clearing Recycle Bin on drive D: – 0 Files, 0 Bytes
21:01:20 clearing Recycle Bin on drive E: – 0 Files, 0 Bytes
21:01:21 Disks in backup:
21:01:21 C: -> \QNASBackupDiff-3-C.sna
21:01:21 D: -> \QNASBackupDiff-3-D.sna
21:01:21 E: -> \QNASBackupDiff-3-E.sna
21:01:21 HD1:1 -> \QNASBackupDiff-3-HD1-1.sna
21:01:21 HD1:2 -> \QNASBackupDiff-3-HD1-2.sna
21:01:21 HD1:3 -> \QNASBackupDiff-3-HD1-3.sna
21:01:21 Preparing for backup
21:01:21 Drive HD1:1 is not supported by the Volume Shadow copy service
21:01:21 Drive HD1:2 is not supported by the Volume Shadow copy service
21:01:21 Drive HD1:3 is not supported by the Volume Shadow copy service
21:01:39 Starting Snapshot creation
21:01:39 Creating shadow set {50897fbd-590e-412a-b3cc-50ec93c10bda}
21:01:47 Register shadow copy {a46e8a7c-fc12-4e6c-a6b6-abad2688583a}
21:01:47 Register shadow copy {1e9bcdbf-d271-4b67-ae0f-f91694a5a60c}
21:01:47 Register shadow copy {efb79d81-4424-487a-ac48-2d58144f65cf}
21:01:47 The Volume Snapshot was created successfully
21:02:01 Start differential VSS backup of C: -> \QNASBackupDiff-3-C.sna
21:02:02 free space info: total 1.241GB, 925.275MB free, 331.601MB must be saved
22:05:40 Waiting for unmount: 1
22:05:41 Waiting for unmount: 2
22:05:42 Waiting for unmount: 3
22:05:43 Waiting for unmount: 4
22:05:43 C: 346.334MB in use – stored in 831.488KB – 63:43 minutes
22:05:43 Success
22:05:45 Start differential VSS backup of D: -> \QNASBackupDiff-3-D.sna
22:05:46 free space info: total 1.241GB, 1.203GB free, 38.625MB must be saved
22:11:26 D: 39.137MB in use – stored in 19.192KB – 5:41 minutes
22:11:26 Success
22:11:32 Start differential VSS backup of E: -> \QNASBackupDiff-3-E.sna
22:11:33 free space info: total 1.241GB, 1.081GB free, 163.688MB must be saved
22:31:23 E: 164.200MB in use – stored in 24.576KB – 19:51 minutes
22:31:23 Success
22:31:24 Start differential backup of HD1:1 -> \QNASBackupDiff-3-HD1-1.sna
22:31:24 free space info: total 510.972KB, 30.892KB free, 480.080KB must be saved
22:31:30 HD1:1 480.080KB in use – stored in 36.864B – 0:06 minutes
22:31:30 Success
22:31:31 Start differential backup of HD1:2 -> \QNASBackupDiff-3-HD1-2.sna
22:31:31 free space info: total 101.376KB, 70.015KB free, 31.361KB must be saved
22:31:34 HD1:2 31.361KB in use – stored in 53.248B – 0:03 minutes
22:31:35 Success
22:31:35 Start differential backup of HD1:3 -> \QNASBackupDiff-3-HD1-3.sna
22:31:36 HD1:3 16.384KB in use – stored in 20.480B – 0:00 minutes
22:31:36 Success
22:31:36 Deleting previously generated shadow copy
22:31:37 Unregister shadow copy {a46e8a7c-fc12-4e6c-a6b6-abad2688583a}
22:31:38 Unregister shadow copy {1e9bcdbf-d271-4b67-ae0f-f91694a5a60c}
22:31:39 Unregister shadow copy {efb79d81-4424-487a-ac48-2d58144f65cf}
22:31:39 Total size of all disks: 3.815.444 MB
22:31:39 Total used size of all disks: 550.188 MB
22:31:39 Total size of all images: 854 MB
22:31:39 Total time used: 89:25 minutes
22:31:39 Average throughput: 102 MB/s
22:31:39 Snapshot finished successfully
22:31:39 End of Snapshot 1.50 [Feb 21 2023] at 21.02.2024
Na wenigstens ist die Sicherung erfolgreich.
Hast du mal getestet, wie es sich ohne VSS verhält?
Ist im Ereignisprotokoll von Windows zum Zeitpunkt der Sicherung irgendwas negatives (Warnung, Fehler) vermerkt?
Hallo Andy,
nun habe ich –noVSS eingesetzt. Geschwindigkeit der Sicherung von C: jetzt
etwas höher bei ca 4,7-5,00 MB/min (vorhin Fehler von mir mit MB/s statt MB/min).
Immer noch deutlich langsamer als die Sicherung von D: und E:. Windows-Fehler gibt es keine.
Verstehe nicht, wieso der Unterschied.
Hatte damit zwar schon sehr lange keine Probleme mehr, aber vielleicht mal mit deaktiviertem AV testen.
Ansonsten mal direkt an Tom Ehlert Software wenden.
Der Support ist echt gut, ich konnte da die vergangenen > 15 Jahre so gut wie alles klären.