Windows 10: Wiederherstellungslaufwerk inkl. Drive Snapshot erstellen

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:

Windows 10 - Rettungsmedium mit Drive SnapshotWichtig: 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.

Windows 10 - Rettungsmedium mit Drive SnapshotBemerkung

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.

29 Kommentare

  1. Andrei

    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 🙁

  2. andy

    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.

  3. Andrei

    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!

  4. andrei

    Mit net use hat’s geklappt! Uff. Jetzt läuft der restore. Herzlichen Dank!

  5. andy

    Seltsam, sollte eigentlich keinen Unterschied machen und bislang gab es bei mir zumindest keine Probleme, aber gut das es auf Umwegen funktioniert.

  6. Herbert Motzel

    ich wollte gerade das File ds-rescue_w81_winre_10.zip downloaden, leider funktioniert der download nicht mehr, könnten sie mir evtl. helfen?

  7. andy

    Jetzt funktioniert es wieder 😉

  8. Herbert Motzel

    super, vielen herzlichen Dank 🙂

  9. Ralf Oertner

    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!

  10. andy

    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 vol

    Volume ### 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: /ah
    Datenträ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.cmd
    Downloading...
    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.

  11. Ralf Oertner

    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!

  12. andy

    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.~BTSourcesSafeOS

    26.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.

  13. andy

    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.

  14. andy

    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.

  15. Ralf Oertner

    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! 🙁

  16. andy

    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.

  17. Andrei

    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

  18. Andy

    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

  19. Andy

    So, mal in einer Werbepause mit Win10XPE was gebaut:

    Mit Win10XPE auf die Schnelle ein Drive Snapshot-Rettungsmedium erstellen

  20. Dirk

    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.

  21. Andy

    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.

  22. Dirk

    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

  23. Andy

    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.

  24. Andrei

    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

  25. Andy

    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.

  26. Andrei

    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:\Downloads\Backup_Software\Snapshot\Exe-Cmd\snapshot64.exe HDWIN:* \\QNAS\Backup\Diff-3-$disk.sna -h\\QNAS\Backup\Full-0-$disk.hsh -RW -Gx –AllWriters -L0 –LogFile:C:\Downloads\Backup_Software\Snapshot\Exe-Cmd\Logs\Current-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: -> \\QNAS\Backup\Diff-3-C.sna
    21:01:21 D: -> \\QNAS\Backup\Diff-3-D.sna
    21:01:21 E: -> \\QNAS\Backup\Diff-3-E.sna
    21:01:21 HD1:1 -> \\QNAS\Backup\Diff-3-HD1-1.sna
    21:01:21 HD1:2 -> \\QNAS\Backup\Diff-3-HD1-2.sna
    21:01:21 HD1:3 -> \\QNAS\Backup\Diff-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: -> \\QNAS\Backup\Diff-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: -> \\QNAS\Backup\Diff-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: -> \\QNAS\Backup\Diff-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 -> \\QNAS\Backup\Diff-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 -> \\QNAS\Backup\Diff-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 -> \\QNAS\Backup\Diff-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

  27. Andy

    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?

  28. Andrei

    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.

  29. Andy

    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.

Schreibe einen Kommentar

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

© 2024 Andy's Blog

Theme von Anders NorénHoch ↑