macOS Catalina Bootfähige 1:1 Kopie einer bestehenden macOS 10.15.6 Installation erstellen

also heißt der Befehl im Terminal 'diskutil apfs unlock /dev/Macintosh HD' ?
 
Fast, du musst mittels diskutil list zunächst das Volume identifizieren (diskXsY) und das dann angeben. Alternativ müsste es aber auch direkt über das Disk Utility gehen, ohne dass du ins Terminal wechselst. Einfach die "Macintosh HD" mounten, dann kommt eine Passwortabfrage und das war's.
 
mj schrieb:
Fast, du musst mittels diskutil list zunächst das Volume identifizieren (diskXsY) und das dann angeben. Alternativ müsste es aber auch direkt über das Disk Utility gehen, ohne dass du ins Terminal wechselst. Einfach die "Macintosh HD" mounten, dann kommt eine Passwortabfrage und das war's.
Zum Vergrößern anklicken....
Leider funktioniert das mit dem FPDP nicht, dann würde die Macintosh HD mit dieser (leeren) 'ASRDataVolume_686' gelöscht. Irgendwas mache ich falsch.
Und mittels 'diskutil list' usw., das sagt mir nichts. Da müsste man mich Schritt für Schritt bei der Hand nehmen, wie die Befehle gehen.
Zum Glück gibt es ja die Paragon-software.
 
it just Works ...war einmal.
Wenn ich das alles so lese hier.

Ich bleibe bei Mojave.:crack: Solange es eben geht.
Von Catalina hab ich schnell wieder abstand genommen.
Big sur entfällt dann sowieso.

OffTopic:
CCC ist ein Segen für "non-Terminal-Profis" wie mich.
Habe 2 MacMinis 2012 und diverse Externe Platten und USB 3 SSDs.
Da klone und boote ich eigentlich alles was ich will. It just Works.
ML, El Capitan und Mojave meistens.
Man hat ja noch Altgeräte wie MB 4.1 Black , iPhone 3 GS, iPad mini 1 mit iOS 6 JB uvm.
 
  • Gefällt mir
Reaktionen: mausfang
lisanet schrieb:
ja. Ich habe es aber auch noch nicht probiert, gleich zu Beginn, die neue Platte als APFS verschlüsselt zu formatieren. Wäre einen Test wert. Mal sehen ob ich Zeit finde.

Die Frage ist viel eher, wie hoch ist dieses Risiko und was muss alles passieren, dass dieses Risiko eintritt. Dazu musst du auch wissen, wie das Risiko genau aussieht. Fakt ist, dass wenn du das als Risiko siehst, dass nicht zu tragen ist für dich, dann kannst du_nie_ eine SSD nachträglich verschlüsseln.

Aber wie hoch ist das Risiko bzw, was genau ist denn da "Risiko"? Alles resultiert aus der Tatsache, dass die genau physische Lage der Bytes einer Datei auf einer SSD nicht vom Betriebssystem vorhergesagt werden kann und beim Löschen durch das Betriebssystem, die Daten nicht an dieser Stelle gelöscht werden, sondern als frei markiert werden. Das Löschen der Speicherstelle erfolgt dann erst bei einem irgendwann folgenden Schreibvorgang (der auf einer SSD aus erst Löschen, dann Schreiben besteht)

Um die Lebensdauer einer SSD zu erhöhen, werden Schreibvorgänge möglichst gleichmäßig verteilt. Es kann also eine ganze Zeit lang dauern, bis die Speicherstelle gelöscht/geschrieben wird. Während dieser Zeit ist sie theoretisch auslesbar. Allerdings sind natürlich alle anderen Bits und Bytes der Dazugehörenden Datei damit immer noch nicht erreichbar. Klar könnte man nun alle solchen noch vorhandenen Infos auszulesen versuchen und dann im Puzzlespiel versuchen, die Datei zu rekonstruieren. Wenn du dir nun überlegst, dass du mit einem nachträglichen Verschlüsseln der SSD eine ganze Menge Schreibvorgänge auslöst (wobei ich glaube APFS geht da einen anderen Weg, das müsste ich erst suchen) Und jede weitere Nutzung dieser SSD ebenso Schreibvorgänge erzeugt, dann kannst du dir nun sicher vorstellen, dass die Wahrscheinlichkeit, dass alle Speicherstellen der schützenswerten Dateien vollständig vorhanden sind, gegen Null geht. Selbst sinnvolle Teile lassen sich nach einiger Zeit wohl kaum mehr sinnvoll rekonstruieren.

Entscheide du, ob du dieses Riskio eingehen kannst. Hilfreich ist da auch, wie hoch andere Risiken sind um das mal in Relation zu setzen, z.B. Das Eindringen in Systeme durch Social engineering. Das unverschlüsselte Versenden von Mails, Nutzung von offenen Hotspots ohne VPN, etc.
Zum Vergrößern anklicken....
Danke, dass du dir die Mühe gemacht hast, so ausführlich zu antworten.
Da ich i.M. auch nicht weiss, wie sich mit dem FDP ein Klon mit einer Verschlüsselung von Anfang an erstellen lässt, versuchs ichs mal mit CCC. Ich kann auf dem Mac einen Dummy Benutzer anlegen, in CCC beim ersten Klonvorgang alle anderen Benutzerverzeichnisse abwählen, dann von der externen SSD booten, FV aktivieren und nach erfolgreicher Verschlüsselung beim nächsten Klonvorgang ein vollständiges CCC-Backup machen.

Nur aus Interesse: Könnte man nicht bei einer nachträglich verschlüsselten SSD (wie bei einer HDD), die extern als normales Volume gemountet ist, einfach den freien Speicher komplett überschreiben mit Nullen oder Zufallszeichen? Oder würden selbst dann nicht alle Speicherstellen überschrieben? Ich meine, wenn der eine Teil verschlüsselt ist und der (freie) Rest mit Müll überschrieben wird...
 
werk schrieb:
Nur aus Interesse: Könnte man nicht bei einer nachträglich verschlüsselten SSD (wie bei einer HDD), die extern als normales Volume gemountet ist, einfach den freien Speicher komplett überschreiben mit Nullen oder Zufallszeichen? Oder würden selbst dann nicht alle Speicherstellen überschrieben? Ich meine, wenn der eine Teil verschlüsselt ist und der (freie) Rest mit Müll überschrieben wird...
Zum Vergrößern anklicken....
Eine 100%-ige Sicherheit ergibt das bei alleinigem Überschriebn auch nicht, da alle SSD mehr Speicherzellen haben, als die angegebene Kapazität, wegen des wear-leveling. Klar kannst du die Rest-Kapazität mit irgendwas überschrieben. Oder du jetzt einfach die SSD eine Zeitl ang. Dann passiert das von ganz alleine.

Aber nochmal, das Risko, dass da irgendjemand eine Datei rekonstruieren kann, bewertest du absolut über. Da liegen keine vollständigen Dateien hintereinander weg, die irgendein Tool wieder kombinieren könnte. Die Speicherstellen einer Datei liegen wahlfrei verteilt auf der SSD. wenn die Datei gelöscht wird, weiß nicht mal mehr der SSD-Kontroller, wo welche Speicherstelle in welcher Reihenfolge zu einer Datei gehörten. Viel Spaß beim puzzeln.
 
lisanet schrieb:
Viel Spaß beim puzzeln
Zum Vergrößern anklicken....
:)
Danke. Dann werd ich mal einen Klon erstellen.
Ich trau mich mal kurz off-topic zu gehen: Weisst du vielleicht, welche Beziehung zwischen Kernel Flags, die z.B. in der Datei /Library/Preferences/SystemConfiguration/com.apple.Boot.plist gesetzt werden, und NVRAM boot arguments (mit nvram gesetzt) besteht? Sind die nvram boot arguments einfach eine andere Möglichkeit (=weniger dauerhaft, weil weg nach Löschen des NVRAMs), Kernel Flags (wie darkwake=0) zu setzen?
 
lisanet schrieb:
Da liegen keine vollständigen Dateien hintereinander weg, die irgendein Tool wieder kombinieren könnte. Die Speicherstellen einer Datei liegen wahlfrei verteilt auf der SSD. wenn die Datei gelöscht wird, weiß nicht mal mehr der SSD-Kontroller, wo welche Speicherstelle in welcher Reihenfolge zu einer Datei gehörten. Viel Spaß beim puzzeln.
Zum Vergrößern anklicken....
Ich vermute, diese Vorstellung, man könne da einzelne Blöcke/Bereich wieder so ohne weiteres zusammenpuzzeln, stammen aus Zeiten, in denen Speichermedien noch überschaubare Größen hatten, so 20 bis bestenfalls 500 Megabytes. Der Mythos wird natürlich gerne in Krimis am Leben erhalten, vor allem in solchen der CSI-Variante (wo sie auch aus unterbelichteten grobpixeligen Überwachungskamerasvideos, aufgenommen aus weiter Entfernung, gestochen scharfe Bilder von Autokennzeichen herausarbeiten können - ich warte immer darauf, daß sie da auch noch Fingerabdrücke entnehmen können).
 
lisanet schrieb:
Für was brauchst du Kernelflags? Und besonders "darkwake"? Hast du einen Hackintosh? Dann bin ich raus.
Zum Vergrößern anklicken....
Ganz normaler Mac mini headless. Ich hatte irgendwann mal rausgefunden, dass mein Mini, nachdem ihn andere Geräte (Audiplayer) aufgeweckt hatten, nicht vollständig aufwachte, sondern nur darkwake machte und sich dann sehr schnell wieder in den Ruhezustand verabschiedete. Mit "darkwake=0" in com.apple.Boot.plist lief aber alles problemlos - bis zum Update auf 10.15.
Mir ist nicht klar, warum das mit der com.apple.Boot.plist seit 10.15 bei mir nicht mehr funktioniert.
Als Workaround half nur sudo nvram boot-args="darkwake=0". Funktioniert jetzt wieder.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich habe noch nie ein Anwendungsszenario gehabt, dass auf Kernelflags zwingend angewiesen war, außer bei Hackintoshs.

Und wenn deine Audioplayer es zwar schaffen den Mac aufzuwecken aber nicht am leben halten, dann solltest du eher mal die Audioplayer und das sonstige System prüfen. Du weist was "darkwake" ist? Ein Audioplayer kann den Mac nicht in den darkwake hinein aufwecken. Der darkwake-Zustand löst der Mac selbst aus, um diverse Aufgaben zu erfüllen, besonders z.B. einen Sleep-Proxy-Server weiter mitzuteilen, dass er noch da ist, oder die WLAN-Verbindung aufrechterhält, so das wake-over-WLAN funktioniert, usw.

Für mich sieht es eher so aus, als ob deine Audioplayer oder deine sonstige Systemkonfiguration nicht dafür ausgelegt ist, dass die Audioplayer durchgehend den Zugriff auf Mediadateien haben. Hast du was mit dem Ruhezustand und Energiesettings rum gebastelt? Wie greifen deine Audioplayer auf den Mac zu?
 
lisanet schrieb:
Ich habe noch nie ein Anwendungsszenario gehabt, dass auf Kernelflags zwingend angewiesen war, außer bei Hackintoshs.

Und wenn deine Audioplayer es zwar schaffen den Mac aufzuwecken aber nicht am leben halten, dann solltest du eher mal die Audioplayer und das sonstige System prüfen. Du weist was "darkwake" ist? Ein Audioplayer kann den Mac nicht in den darkwake hinein aufwecken. Der darkwake-Zustand löst der Mac selbst aus, um diverse Aufgaben zu erfüllen, besonders z.B. einen Sleep-Proxy-Server weiter mitzuteilen, dass er noch da ist, oder die WLAN-Verbindung aufrechterhält, so das wake-over-WLAN funktioniert, usw.

Für mich sieht es eher so aus, als ob deine Audioplayer oder deine sonstige Systemkonfiguration nicht dafür ausgelegt ist, dass die Audioplayer durchgehend den Zugriff auf Mediadateien haben. Hast du was mit dem Ruhezustand und Energiesettings rum gebastelt? Wie greifen deine Audioplayer auf den Mac zu?
Zum Vergrößern anklicken....
Die Audioplayer wecken den Mini mit einem ganz gewöhnlichem WOL und erhalten ihren Audistream von einem Serverprogramm, das auf dem Mini läuft, also kein direkter Zugriff auf die Musikdateien via SMB o.ä.
Als ich den Mini vor vielen Jahren eingerichtet habe, habe ich zuerst versucht, die OS Ruhezustandsregeln zu nutzen. Ich wollte einfach, dass der headless Mini mit der externen HDD in den Ruhezustand geht, wenn ich keine Musik mehr streame. Hat alleine mit den OS Einstellungen nicht funktioniert, entweder ging er gar nicht oder zu früh in den Ruhezustand (ob nun von Playern ode einem anderen Mac per WOL geweckt). Ich war auch nicht der einzige Nutzer mit diesem Anwendungsfall und diesem Problem.
Letztendlich habe ich dann den Ruhezustand in den OS Einstellungen komplett deaktiviert und im Hintergrund ein Appleskript (als App) laufen, dass den Ruhezustand mit pmset sleepnow aktiviert, wenn kein Player mehr aktiv/on ist. Hat, wie gesagt, zusammen mit darkwake=0 immer gut funktioniert.
Ich wollte auch nicht sagen, dass die Player den Mini in den darkwake Zustand aufwecken. Nur dass darkwake=0 Teil der Lösung war und dass der Mini ohne diese Einstellung nach einigen Sekunden wieder in den Ruhezustand zurückkehrte.

Aber zurück zu meiner Ausgangsfrage: In welchem Verhältnis stehen denn Kernelflags und nvram boot arguments? Und warum ignoriert der Mini deiner Meinung nach die darkwake=0 Einstellung in der Datei com.apple.Boot.plist?
 
Zur Frage mit den Kernelflags kann ich nichts sagen.

Und wenn der Server, was für Server ja eigentlich korrekt ist, den Ruhezustand bei aktiver Verbindung nicht unterbindet, ist das echt nicht gut, für deinen Einsatzwunsch.

Ich persönlich würde mir da eher überlegen, ob sich die Serverdienste nicht auf ein always-on-Gerät verfrachten ließen, z.B. auf einen Raspberry Pi 4. Sofern das geht natürlich. Ich habe mit dem Raspi 4 mehrere Serverdienste realisiert: Plex-Server, TimeMachine, npm Proxy-Server und lokalen git repos. Vielleicht ist das ja auch was für dich.
 
  • Gefällt mir
Reaktionen: dg2rbf
Kaufe CCC, es ist nicht billig, aber es ist es wert.
 
  • Gefällt mir
Reaktionen: Faraway
Kibitz schrieb:
Kaufe CCC, es ist nicht billig, aber es ist es wert.
Zum Vergrößern anklicken....
Nein, lass das mit CCC und mache es mit Bordmitteln, sprich dem Festplattendienstprogramm. Das unterstützt alle Features von APFS, es kostet nichts zusätzlich und der Vorgang ist sogar schneller.
 
  • Gefällt mir
Reaktionen: dg2rbf
Wenn es um einen einmaligen Vorgang geht, sicher, auch wenn Apple da anscheinend seit einigen Versionen - was man so liest - die Bedienung erschwert oder Funktionen kappt oder versteckt.
CCC erlaubt aber halt zusätzlich, diese Kopie per inkrementellem "Klonen" immer zu synchronisieren, auf dem neuesten Stand zu halten - das FPDP wird dann jedesmal alles neu kopieren.
 
  • Gefällt mir
Reaktionen: RealRusty und dg2rbf
Schiffversenker schrieb:
CCC erlaubt aber halt zusätzlich, diese Kopie per inkrementellem "Klonen" immer zu synchronisieren, auf dem neuesten Stand zu halten - das FPDP wird dann jedesmal alles neu kopieren.
Zum Vergrößern anklicken....
Klar, wenn das dein Einsatzzweck ist und du für dieses faktische rsync-Feature mit hübschem UI relativ viel Geld zahlen willst und du bereit bist, beim ersten "Klonen" ein wesentliches APFS- Feature zunichte zu machen und dir dafür gerne zusätzliche snapshots mit entsprechendem Platzbedarfs vorhalten willst, ja dann ist CCC das richtige Programm.
 
Nach meinem angelesenen Kenntnisstand ist CCC mittlerweile voll an APFS angepasst.
Ich finde die GUI insofern praktisch, als ich verschiedene Sets anlegen kann, um von verschiedenen Quell-Platten/Verzeichnissen unterschiedliche Zielplatten erreichen kann, und das auf eine auch für mich als Laien bequeme Art.
 
Schiffversenker schrieb:
Nach meinem angelesenen Kenntnisstand ist CCC mittlerweile voll an APFS angepasst.
Zum Vergrößern anklicken....
Also dann lies mal das hier zum von mir erwähnten APFS-Feature -> https://bombich.com/de/kb/ccc5/everything-you-need-know-about-carbon-copy-cloner-and-apfs#math

Im Abschnitt "Warum entspricht der belegte Festplattenspeicher auf meiner Backup-Festplatte nicht dem belegten Festplattenspeicher auf dem Quellvolume?" wird geschrieben: "Die APFS-Klonfunktion spart zwar Speicherplatz auf dem Quellvolume ein, diese Einsparungen können beim Kopieren der Dateien auf ein anderes Volume jedoch nicht konsequent beibehalten werden". Das ist exakt das was ich sage, nur formuliert er es ja nur vorsichtig und nennt die Konsequenz nicht konkret: APFS- cloning / deduplication wird von CCC nicht unterstützt und auf dem Zielvolume unwiederbringlich beseitigt und vergrößert also definitiv den Speicherplatz.

Zum Thema snapshots -> https://bombich.com/de/kb/ccc5/leveraging-snapshots-on-apfs-volumes wird beschrieben "Wenn Sie für ein CCC-Backup ein APFS-Volume auf einem SSD-Laufwerk als Quelle† oder Ziel auswählen, unterstützt CCC auf diesem Volume automatisch Schnappschüsse und richtet eine standardmäßige Schnappschuss-Erstellung und -Aufbewahrung darauf ein." was nichts anderes bedeutet, als dass eben diese snapshots zunehmend mehr Speicher auf der Quelle einnehmen, solange sie CCC vorhält und nicht löscht.

Und für das Aktuell-halten mittels rsync gibs ebenso schöne wie funktionale GUI-Programme, die noch nicht mal was kosten, wie z.B. SyncTwoFolders.

Aber wie gesagt, wenn du für dich entschieden hast, für diese Dinge CCC zu kaufen, auf Funktionalität zu verzichten und Speicherplatz vorhalten, ist das doch okay. Du musst ja keine Bordmitteln nutzen, die noch einkleinwenig mehr können.

Ach ja ich vergaß: Das erste Wiederherstellen mit dem FPDP ist nicht nur ein 1:1 Kon, sondern geht auch schneller als als der erste "Klon" mittels CCC.
 
  • Gefällt mir
Reaktionen: dg2rbf
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten