Referenzen:
Apparently, in Windows 10 doing a SHUTDOWN from the Windows Start Menu, in reality performs a hybrid shutdown instead of a full shutdown! This sometimes seems to create problems when running Window...
superuser.com
Zitat von Microsoft selbst:
"The Fast Startup feature in Windows 10 allows your computer start up faster after a shutdown. When you shut down your computer, Fast Startup will put your computer into a hibernation state instead of a full shutdown. Fast Startup is enabled by default if your computer is capable of hibernation."
(Was mir nicht bewusst war, man kann es sogar direkt in der Systemsteuerung einstellen:
Systemsteuerung\Alle Systemsteuerungselemente\Energieoptionen\Systemeinstellungen -> Schnellstart aktivieren -> deaktivieren)
Alternativ in der Registry:
"You can also disable the fast startup through the Registry: in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power key set HiberbootEnabled value to 0 (type REG_DWORD)."
Das ist eine relevante Änderung der Einstellungen, weil es in bestimmten Fällen zu Problemen führen kann (z.B. bei Installationen, die einen Neustart verlangen), wenn "nur" "herunterfahren" geklickt wird und anschließend der computer / die vm wieder gestartet wird, und "Schnellstart" aktiviert ist. Es wäre in diesen Fällen entweder "Neu starten" oder ein Herunterfahren mit deaktivierter Schnellstartoption nötig gewesen.
Der Schnellstart hat m.E. nur Nachteile: Herunterfahren+Hochfahren ist nicht genauso effektik wie Neustart, und wenn man schnell wieder weiterarbeiten möchte, nutzt man dazu ja Ruhezustand oder ggf. hybriden Standby (Ruhezustand + Standby parallel ausgeführt; verhindert Datenverlust wenn Unterbrechung der Stromversorgung).
Relevant ist das insofern, als der Ratschlag, die VM müsse vor einer Sicherung "heruntergefahren werden", somit bei der Default-Einstellung von Windows (Schnellstart aktiv) nicht wirklich "heruntergefahren" ist (siehe Microsoft-Zitat), und sich dann die Frage anschließt, warum dieses hybride Herunterfahren notwendig ist anstelle von "Ruhezustand (RAM-to-Disk), um die Integrität der PVM-Datei innerhalb eines APFS-Snapshots sicherzustellen.
Es schließen sich dann für mich dann eben Fragen an, welche "Zustände" einer VM akzeptabel sind für eine Sicherung.
Die verschiedenen Möglichkeiten, mit denen eine VM in "stabile" Zustände diverser Art versetzt werden kann, die sich potentiell zu Sicherung eignen, habe ich im Eingangsposting in der Liste (Sternchen) aufgezählt.
(1) Der hybride Standby (innerhalb Windows) ist in Windowsinstallationen in Parallels nicht als Einstellung verfügbar.
(2) Das Ausführen von Standby (innerhalb Windows) führt bei der VM nur zur Anzeige des Anmeldescreens (damit erklärt sich auch, warum der hybride gar nicht erst verfügbar ist).
(3) Der Ruhezustand (innerhalb Windows) IST verfügbar und funktioniert. (also RAM-to-Disk, was ja mit relevant ist für eine Sicherung)
(4) Der Hypervisor kann zudem die VM in einen VM-Ruhezustand versetzen (deutsche Paralells-Version: verwirrenderweise "Standby" genannt, in der Englischen "Suspend") über das Mac-Menu der Parallels-App.
(5) Ebenfalls kann Parallels die VM in einen "Pause" - Zustand versetzen ("Pause").
(6) Und dann eben noch komplettes Herunterfahren von Windows (schnellstart hierzu deaktiviert).
Wenn CCC ein Backup ausführt, wird zeitgleich ein APFS-Schnappschuss ausgeführt, und zwar sowohl auf der Quelle als auch im Ziel, sofern beide APFS-formatiert sind.
Smartguard-Snapshots, die der Hypervisor ausführt, sofern konfiguriert, werden hingegen natürlich innerhalb der VM-Datei (genauer: Container; nicht zu verwechseln mit APFS-Container) gespeichert. Ich halte einen APFS-Snapshot der gesamten PVM-Datei für im Vergleich sicherer als einen Smartguard-Snapshot, da letzterer immer noch die Integrität der gesamten PVM-Datei erfordert, was aber nicht gegen zusätzlcihe Smartguard (oder manuell ausgeführte) Snapshots via die Parallelssoftware spricht. Ein APFS-Snapshot kann zum gewünschten Zeitpunkt (VM ist in statischem Zustand) manuell getriggert werden durch einen Backuptask in CCC, der sich auf einen leeren Ordner bezieht (siehe Dokumentation). Timemachine-bezogene APFS-Snapshots auf dem internen Datenträger eines Macs lassen sich deakvieren (ich glaube nur über Terminal ging das), um nicht zwei Snapshotgruppen parallel laufen zu haben (Speicherplatz, unabgestimmte Redundanz), und vor allem, weil Time Machine die Backups automatisch und damit zu unerwünschten Zeitpunkten ausführt (Integrität der VM nicht gewährleistet).
Das Problem besteht grundsätzlich darin, dass es nicht möglich ist, ein System-Image von Windows zu erstellend (und darauf basierend schnelle inkrementelle Images im laufenden Betrieb), das bootfähig ist als VM. Ob es auf deinem ARM-PC via deploy-to-dissimilar-hardware (so heißt die Option bei Macrium) lauffähig werde, weiß ich nicht, ich könnte mir vorstellen, dass Parallels in einer Weise Windows verändert, dass dieses Macrium-Feature nicht ganz reibungslos funktonieren wird. Die Fragestellung ist insofern relevant, als es durchaus interessant sein könnte, in 3 Jahren von der VM auf ein (lüfterloses) ARM-Notebok zu migrieren. In jedem Fall kann man also die Macrium-Images nur als hochfrequentes inkrementelles Daten-Backup nutzen, nicht zur VM-Systemwiederherstellung.
Es stellt sich also die Frage, wie man für die VM eine Annäherung an die eigentlich empfohlene Vorgehensweise hinbekommt, die auf einem Full-Image-Backup und darauf aufbauenden Diffs und Incrementals. Das Problem ist nämlich das Folgende: Die VM-Datei ist ja sehr groß ggf. hunderte GB, ggf. zusätzlich "aufgebläht" durch darin befindliche Snapshots. Ändert sich die PVM im laufenden Betrieb, so wächst ein zuvor erstellter APFS-Snapshot im Umfang der Differenz dieser Änderungen. Bei gut eingestelltem Snapshot-Retainment kann erreicht werden, dass keine Speicherplatz-Probleme auf der internen SSD enstehen. Generell gilt, je älter der Snapshot, je größer, und je häufiger einer erstellt wird, desto eher werden alte "rechtzeitig" gelöscht (denn erst mit jedem Backup-Task erfolgt ja jewewils eine Evalulierung der derzeit existierten APFS-Snapshots).
Das schützt aber natürlich nicht vor dem Fall, dass die SSD den Geist aufgibt. Da es aber wie oben beschrieben nicht möglich ist, eine bootfähige Image-Datei (mit darauf basierenden Incrementals) auf einem externen (permanent verbundenen) Datenträger zu sichern (z.B. SDXC oder handliche SSD), muss die PVM in Gänze auf extern kopiert werden -- als eine sehr große Datei, und dies regelmäßig. Daher ist eine HDD als unmittelbarer Backupdatenträger ungeeignet (zu langsam), obwohl man dazu neigen könnte, weil sie günstiger ist / hohe Kapazitäten bietet. Sinnvoll ist daher m.E. eigentlich nur, auf eine SSD zu sichern. Wenn nun aber eine aktuellerer Zustand einer VM auf die externe SSD gesichert wird, und der vorherige Zustand in einem Snapshot landet, passiert NICHT dasselbe wie auf der internen SSD. Es wandert nicht nur die Differenz in den Snapshot, sondern die GESAMTE alte PVM-version landet dort. CCC ist interessanterweise durchaus bei manchen Dateien in der Lage, nur das Delta zu sichern, aber für diesen Fall funktioniert es nicht. Außerdem dauert die Deltasicherung länger, obwohl weniger Daten übertragen werden (wegen der Analyse).
Ich halte es auch für sinnvoll, die PVM-Datei auf einem eigenensVolume auf der internen SSD zu speichern, um die Snapshots von DATA und dem VM-volume getrennt halten zu können, was diverse Vorteile hat bei der Konfiguration der Retention der Snapshots und bzgl Speicherplatz-Management (denn der ist ja immer knapp, intern).
Backups sind bekanntlich maßgeblich davon abhängig, dass sie überhaupt gemacht werden, und je umständlicher das Prozedere, desto eher ist dann kein (aktuelles) Backup da, wenn es gekracht hat.
Während also ein Windows-Laptop einfach innerhalb von 80 Sekunden eine 1. inkrementelle System-Image-Sicherung im 2. laufenden Betrieb auf Extern machen kann, geht das bei Parallels nicht: 1. Die GESAMTE PVM-Datei muss kopiert werden UND es geht 2. nicht im laufenden Betrieb.
Nachteil 1 kann durch eine schnelle SSD abgemildert werden und durch eine Ergänzung mithilfe von Snapshots auf dem Quelldatenträger (interne SSD). (Zusätzlich Macrium auf externe SDXC permament (15-minütig) zu verwenden ist empfehlenswert, weil Dokumente usw. wesentlich häufiger gesichert werden können.)
Meine Frage bezog sich auf Nachteil 2. Sowohl beim Erstellen eines APFS-Snapshots der PVM (interner Datenträger), als auch beim regelmäßigen Backup (Kopieren) der PVM auf extern sollte die VM also in einen Zustand gebracht werden, der zuverlässig booten wird und alle Daten beinhaltet -- auch die ggf. im RAM befindlichen Daten laufender Programme. Jedes Mal alle Dokumente / Browser / .... zu schließen und die ganze VM herunterzufahren, nur um ein Backup auf exteren zu machen, das bei einem Windows-Notebook unbemerkt im Hintergrund läuft, führt im Alltag dazu, dass man seltener sichert, und es nervt natürlich jedes Mal und kostet Zeit. Daher stellt sich die Frage, welches Vorgehen geeigent ist, bei dem die VM NICHT heruntergefahren werden muss:
Meine Fragen wären also:
1. Wenn man die VM nur "pausiert", dann enthält wohl eine Sicherung den RAM nicht, und alles nicht Gespeicherte ist wohl verloren. Ein Vorteil gegenüber einem APFS-Snapshot (auf dem ja das Backup basieren wird) im laufenden Betrieb ist wohl kaum vorhanden.
2. Es bleiben dann also diese Fragen: Kann die VM statt sie herunterzufahren auch (via Windows-Startmenü) in den Ruhezustand versetzen, BZW. via Parallels-Menü in den Suspend (deutsch "Standby") - Ruhezustand versetzen - und wenn ja, welche der beiden Methoden wäre zu bevorzugen und warum?
"Glaubst du ernsthaft, das irgendein OS nur bei "Neustart" komplett herunter fährt? (...) Du solltest basierend auf den Kompetenzen, die aus deinem Post sprechen die Finger aus der Registry lassen."
Likes: trexx
Irgendein OS namens Windows, meinst du?
Es steht außer Frage, dass ich von Computertechnik nur so ne Halbahnung habe, aber ich bemühe mich wirklich sehr, die ganzen Dokumentationen bei CCC und Parallels zu lesen oder bei
https://eclecticlight.co/ , bevor ich hier etwas poste. Insofern finde ich den Tonfall unfair. Zum Inhalt, es gibt Leute, die haben irgendwelche zigfach redundanten RAID-Setups und remote Backups usw, weil sie quasi kein Byte und keine Minute Arbeit verlieren wollen. Es gibt immer wieder Leute, die schweren Datenverlust erleiden mit ihren VMs aus diversen Gründen, und der ausführliche Text oben ist einfach ein Versuch sich genauer anzuschauen was getan werden könnte/muss, damit VM-Nutzer (Windows auf Mac mit Parallels) wenigstens halbwegs gut abgesichert sind.
Nachtrag:
Also es ist so: (Fragestellung: Welche Voraussetzungen müssen gegeben sein für ein Backup der PVM-Datei?)
1. Windows-Startbutton -> Ruhezustand -> Parallels App lässt sich komplett beenden -> Integrität der PVM-Datei sollte also sichergestellt sein und ein Backup oder APFS-Snapshot sollte eine funktionsfähige VM beinhalten. Starten der VM führt dazu, dass zunächst der Anmeldescreen angezeigt wird beim Resumen. (Ich habe auch geprüft: Die PVM-Datei wird beim Beenden von Parallels nicht nochmal modifziert - d.h. sie kann auch ohne vorheriges Beenden der gesamten Parallels-App gesichert werden.)
2. Parallels-Menü -> Standby (engl Suspend) -> Parallels App lässt sich ebenfalsl komplett beenden -> dito (s.o). Starten der VM führt unmittelbar zum letzten Zustand.
Ob 1 oder 2 vorteilhafter ist, werde ich mal versuchen herauszufinden. Ein Aspekt ist sicherlich, wie gut USB-Geräte nach dem Resumen wieder verfügbar sind. Generell führen USB-Sticks manchmal dazu, dass die VM beim Herunterfahren oder "Standby/Suspend" "hängt", weil es Probleme beim Auswerfen gibt.
3. Parallels-Menü -> Pause -> Wenn man versucht, Parallels zu beenden, scheint Parallels vorm Beenden eine Suspend-Aktion bei der sich im Pause-Zustand befindlichen VM automatisch durchzuführen, sodass es auf's selbe rausläuft wie bei 2.
Aufgefallen ist mir, dass sich Vorgehensweise 1 "flüssiger" anfühlt im Gegensatz zu 2 (keine "Artefakte" / graphischen Auffälligkeiten / Stottern)
Zu "2" schreibt Parallels in der Hilfe: "Warning: If you edit the configuration of a suspended virtual machine, you will not be able to resume this virtual machine." Hier stellt sich also die Frage, ob sich die PVM nach einem defekt der internen SSD tatsächlich resumen lässt. Man hat natürlich im Regelfall auch ein Backup von DATA, und kann somit die PVM nach dem Restoren von DATA auf einem neuen Mac auch die PVM direkt wieder einbinden in dieselbe Konfiguration, in der sie vorher war. Ob es da aber irgendeine Hürde gibt, die doch zu Problemen führt (vTPM?), sodass ein Neustart erfolderlich wird, kann ich nicht abschätzen. Ich vermute aber, dass (vorausgesetzt Dokumente etc waren abgespeichert gewesen) selbst im Fall, dass der Ruhezustand nicht wiederhergestellt werden kann und ein Neustart erzwungen wird, das System als solches bootbar sein wird / Integrität in Ordnung sein wird, und "nur" die Ruhezustandsdaten verloren gehen (also wie bei einem BSOD, der ansonsten keine weiteren Probleme verursacht und das System anschließend normal startet.
Vielleicht ist dieses Posting hier ja doch noch für irgendwen von Nutzen.
