Platte bootfähig klonen?

[Gerhard Torges]

Hallo!

(Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes auf
eine externe FW-Platte klonen?
Die externe Platte soll zwischenzeitlich als Ersatz f�r die interne
dienen, sprich, es soll davon gebootet und damit gearbeitet werden.
Rechner ist ein iMac C2D (late 2006, 24") mit 10.6.8.


Gerhard

--
Signaturen werden �berbewertet.

[Iwan]

Am 03.01.2014, 11:22 Uhr, schrieb Gerhard Torges <deaf...@hotmail.com>:

> Hallo!
>
> (Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes auf
> eine externe FW-Platte klonen?

> Die externe Platte soll zwischenzeitlich als Ersatz für die interne

> dienen, sprich, es soll davon gebootet und damit gearbeitet werden.
> Rechner ist ein iMac C2D (late 2006, 24") mit 10.6.8.

Hier mache ich das seit Jahren mit

Carbon Copy Cloner

funktioniert bestens hin und zurueck.

Gruesse

Peter

[Thomas Kaiser]

Gerhard Torges schrieb in <news:1lewa5w.1t5s7xuk1qa9sN%deaf...@hotmail.com>

> (Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes auf
> eine externe FW-Platte klonen?

Rechner von Installationsmedium booten (ab 10.7 von der Recovery
Partition), Festplatten-Dienstprogramm aufrufen, externe Platte
partitionieren und im Anschluß über "Wiederherstellen" die einzelnen
Partitionen (Volumes) im block-copy-Modus klonen (sollte schneller gehen
als per rsync, wie es aktuelle CCC-Versionen machen, zumal kann weder
CCC noch rsync eine Platte partitionieren, und Systeme im laufenden
Betrieb zu klonen ist eh doof)

Gruss,

Thomas

[Heiner Veelken]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> Rechner von Installationsmedium booten (ab 10.7 von der Recovery
> Partition), Festplatten-Dienstprogramm aufrufen, externe Platte

> partitionieren und im Anschlu� �ber "Wiederherstellen" die einzelnen

> Partitionen (Volumes) im block-copy-Modus klonen (sollte schneller gehen
> als per rsync, wie es aktuelle CCC-Versionen machen, zumal kann weder
> CCC noch rsync eine Platte partitionieren, und Systeme im laufenden
> Betrieb zu klonen ist eh doof)

Was muss ich dem Festplattendienstprogramm denn "sagen", damit es im
block-copy-Modus klont. (Ich google das parallel mal :-) )

--
Gruss Heiner

[Heiner Veelken]

Okay; Kommando zur�ck: Quellvolumen darf nicht startvolume sein und
"Zielmedium l�schen" muss aktiviert sein.

--
Gruss Heiner

[Gerhard Torges]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> Gerhard Torges schrieb in <news:1lewa5w.1t5s7xuk1qa9sN%deaf...@hotmail.com>
>
> > (Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes auf
> > eine externe FW-Platte klonen?
>
> Rechner von Installationsmedium booten (ab 10.7 von der Recovery
> Partition), Festplatten-Dienstprogramm aufrufen, externe Platte

> partitionieren …

… wie die zu klonende Platte, vermute ich?
Ebenso sollten sich die Partitionierungsparameter gleichen, richtig?

> … und im Anschluß über "Wiederherstellen" die einzelnen
> Partitionen (Volumes) im block-copy-Modus klonen …

Ich hatte gehofft, daß es da eine systemmmanente Vorgehensweise gibt.

Danke.


Gerhard


--
Signaturen werden überbewertet.

[Thomas Kaiser]

Heiner Veelken schrieb in <news:1lewiuj.1u8cq788z3c4mN%vi...@gmx.net>

> Heiner Veelken <vi...@gmx.net> wrote:
>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>
>> > Rechner von Installationsmedium booten (ab 10.7 von der Recovery
>> > Partition), Festplatten-Dienstprogramm aufrufen, externe Platte

>> > partitionieren und im Anschluß über "Wiederherstellen" die

>> > einzelnen Partitionen (Volumes) im block-copy-Modus klonen (sollte
>> > schneller gehen als per rsync, wie es aktuelle CCC-Versionen
>> > machen, zumal kann weder CCC noch rsync eine Platte partitionieren,
>> > und Systeme im laufenden Betrieb zu klonen ist eh doof)
>>
>> Was muss ich dem Festplattendienstprogramm denn "sagen", damit es im
>> block-copy-Modus klont. (Ich google das parallel mal :-) )
>

> Okay; Kommando zurück: Quellvolumen darf nicht startvolume sein und
> "Zielmedium löschen" muss aktiviert sein.

"Quellvolume nicht Startvolume" ist nebenbei gesagt immer eine gute
Idee, denn wie soll eine Klonsoftware unfallfrei von einem gerade
laufenden System eine *konsistente* Kopie anfertigen, wenn das
Dateisystem keine Snapshots unterstützt, mit dem ein ebensolcher
konsistenter Zustand zumindest der Dateien hergestellt werden könnte
(Dateiinhalte ist nochmal ein komplett anderes Thema -- 'zig Frameworks
in OS X bedienen sich Datenbank-Dateien, die ab und an geschrieben
werden und die zum Teil aufeinander aufbauen. Weder kann beim Klonen
eines gerade aktiven Systems sichergestellt werden, dass eine solche
Datei gerade in sich konsistent ist, noch, dass zwei DB-Dateien, deren
Inhalte aufeinander aufbauen zueinander konsistent geklont werden, wenn
der Vorgang eine gewisse Zeit braucht [1])

Reiß mal 'ne Shell auf und gib "lsof" ein, um zu sehen, wieviel Dateien
gerade _offen_ sind (das sind alles potentielle Kandidaten, die den Klon
eines laufenden Systems nicht bzw. ggf. nur inkonsistent überstehen)

Ergo: Wenn man sichergehen will, klont man ein ruhendes, vorher sauber
heruntergefahrenes System. Und das klappt auf dem Weg eben a) am
Simpelsten und b) dann auch am Schnellsten, denn block-copy gewinnt bei
kompletten Klons _immer_ gegenüber dateibasiertem Kloning -- was anderes
ist's, wenn man meint, sein System inkrementell klonen zu müssen, da ist
dann bei nur wenigen Änderungen zwischen den Läufen die dateibasierte
Methode immer schneller.

Und natürlich könnte man dann so einen block-level-Klon auch mit bspw.
dd (oder asr [2]) anfertigen. Aber wozu an der Stelle in den Shell-
Keller hinabsteigen, wenn die ganze Funktionalität eh nur ein bisserl
Mausgeschubse entfernt im Festplatten-Dienstprogramm selbst zur
Verfügung steht und kein bisschen schlechter funktioniert?

Gruss,

Thomas

[1] Und wie ging Apple damit um, dass viele User angefeuert bspw. durch
die SuperDuper!-Macher ihre Systeme im laufenden Betrieb kaputt-
geklont haben und dachten, sie hätten einen sauberen 1:1-Klon am
Ziel (was nicht gehen kann und was immer wieder zu Problemem führt):
Sie bauen halt heute an allen möglichen Stellen Indikatoren ein, die
auf sowas Rückschlüsse zulassen, bspw. neben irgendwelchen SQLite-
Index-Dateien noch eine ".state"-Datei, die beim nächsten Start mit
der eigentlichen Datenbank-Datei verglichen wird. Und falls die
Indizien dafür sprechen, dass der User so doof war und den Klon
falsch erstellt hat, dann schmeißt OS X den Index halt einfach weg
und baut ihn neu auf (das kostet dann inzwischen Zeit, erspart dem
User aber phantastische Phänomene wie ein instabiles System)

[2] Auch der CCC kann natürlich einen block-level-Klon anfertigen und
benutzt dazu die identische Funktionalität des Festplatten-Dienst-
programms: asr. Aber natürlich geht das auch mit dem CCC nicht, wenn
das Quellvolume "aktiv" ist, d.h. nicht ausgeworfen werden kann,
siehe

http://www.bombich.com/software/docs/CCC/en.lproj/explore/the-block-level-copy.html

[Thomas Kaiser]

Gerhard Torges schrieb in <news:1lewjhb.rleq5710fmousN%deaf...@hotmail.com>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Gerhard Torges schrieb in <news:1lewa5w.1t5s7xuk1qa9sN%deaf...@hotmail.com>
>>
>> > (Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes
>> > auf eine externe FW-Platte klonen?
>>
>> Rechner von Installationsmedium booten (ab 10.7 von der Recovery
>> Partition), Festplatten-Dienstprogramm aufrufen, externe Platte
>> partitionieren …
>
> … wie die zu klonende Platte, vermute ich?
> Ebenso sollten sich die Partitionierungsparameter gleichen, richtig?

Naja, so, dass das Ganze halt paßt ;-)

In ca. 101% der Fälle ist doch die neue Platte [viel] größer als die
alte? Da identische Partitionen anzulegen, bedeutet, am Ende noch 'ne
Partition mehr zu haben.

Ich würd die Partitionierung halt sinnvoll anpassen (was das bedeutet,
kannst nur Du selbst bestimmen, denn _ich_ find Partitionierung auf
einem Desktop-System anno 2014 sowieso nur kontraproduktiv)

Wenn Du auf block-level-Kloning aus bist, dann mußt Du eben gucken, dass
die Zielvolumes exakt identisch (bzw. 2 Blöcke == 8 KByte größer) sind.
Welches Partitionierungsschema Du verwendest, ist dabei wurscht (also
GPT vs. APT -- MBR verbietet sich ja hoffentlich eh von selbst?)

>> … und im Anschluß über "Wiederherstellen" die einzelnen Partitionen
>> (Volumes) im block-copy-Modus klonen …
>
> Ich hatte gehofft, daß es da eine systemmmanente Vorgehensweise gibt.

Ist das doch? In der Variante sinnvoll (es gäbe auch noch die Option,
einfach das Device mitsamt Partition Table zu klonen. Aber das ist in
jeder Situation, in der Quell- und Zieldevice nicht absolut gleich groß
sind -- vulgo identische Platten -- einfach nur bescheuert, wenn Ziel
größer, oder defekt, wenn Ziel kleiner).

Gruss,

Thomas

[Gerhard Torges]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> Gerhard Torges schrieb in <news:1lewjhb.rleq5710fmousN%deaf...@hotmail.com>
>
> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
> >
> > > Gerhard Torges schrieb in
> > > <news:1lewa5w.1t5s7xuk1qa9sN%deaf...@hotmail.com>
> > >
> > > > (Wie) kann ich eine komplette Platte (intern) mit mehreren Volumes
> > > > auf eine externe FW-Platte klonen?
> > >
> > > Rechner von Installationsmedium booten (ab 10.7 von der Recovery
> > > Partition), Festplatten-Dienstprogramm aufrufen, externe Platte
> > > partitionieren …
> >
> > … wie die zu klonende Platte, vermute ich?
> > Ebenso sollten sich die Partitionierungsparameter gleichen, richtig?
>
> Naja, so, dass das Ganze halt paßt ;-)

Na dann. ;-)

> In ca. 101% der Fälle ist doch die neue Platte [viel] größer als die

> alte …

Hier nicht. Sie ist bis auf wenige MB gleich groß. ;-)

> Ich würd die Partitionierung halt sinnvoll anpassen (was das bedeutet,
> kannst nur Du selbst bestimmen, denn _ich_ find Partitionierung auf
> einem Desktop-System anno 2014 sowieso nur kontraproduktiv)

Ich lasse das erstmal so, auf eine Reorganisation habe ich gerade keine
Lust. ;-)

> Wenn Du auf block-level-Kloning aus bist, dann mußt Du eben gucken, dass
> die Zielvolumes exakt identisch (bzw. 2 Blöcke == 8 KByte größer) sind.

OK.

> Welches Partitionierungsschema Du verwendest, ist dabei wurscht (also
> GPT vs. APT -- MBR verbietet sich ja hoffentlich eh von selbst?)

Ich habe keine Ahnung, aber das Festplatten-Dienstpogamm wird sicher die
nötigen Informationen liefern.

> >> … und im Anschluß über "Wiederherstellen" die einzelnen Partitionen
> >> (Volumes) im block-copy-Modus klonen …
> >
> > Ich hatte gehofft, daß es da eine systemmmanente Vorgehensweise gibt.
>
> Ist das doch?

Ja, klar.
Der Satz sollte ja auch meine Erleichterung über diesen Umstand zum
Ausdruck bringen. Jetzt sehe ich allerdings, daß er auch anders
verstanden werden kann. ;-)

Gruß,

[Patrick Kormann]

Am 03.01.14 15:05, schrieb Thomas Kaiser:

> Und natürlich könnte man dann so einen block-level-Klon auch mit bspw.
> dd (oder asr [2]) anfertigen. Aber wozu an der Stelle in den Shell-
> Keller hinabsteigen, wenn die ganze Funktionalität eh nur ein bisserl
> Mausgeschubse entfernt im Festplatten-Dienstprogramm selbst zur
> Verfügung steht und kein bisschen schlechter funktioniert?

Nur, sowohl mit asr wie auch mit dem Festplattendienstprogramm habe ich
immer mal wieder Ärger, will sagen aus irgendwelchen unerfindlichen
Gründen schlägt die Kopie fehl, resp. wird gar nicht erst gestartet.
Oder das clonen in eine Datei klappt, das Restoren dann aber nicht.

Mit dd hab ich solche Sorgen nie ;)

[Juergen P. Meier]

Gerhard Torges <deaf...@hotmail.com>:
> Hier nicht. Sie ist bis auf wenige MB gleich groￜ. ;-)

Die Zielplatte darf dann auf keinen Fall kleiner sein.

> Ich habe keine Ahnung, aber das Festplatten-Dienstpogamm wird sicher die

> nï¿œtigen Informationen liefern.

Leider nicht. Das Festplatten-Dienstprogramm ist - anders als viele
andere Apple-Programme - nicht dafuer ausgelegt von jemandem Benutzt
zu werden, der nicht genau weis was er tut.

Dafuer ist das mit diesem Wissen aber nicht all zu schwer und schnell
und einfach zu lernen.

Wichtig zu wissen ist vor allem anderen: Ein laufendes OS X kann man
nicht ohne Defekte klonen (OS X fehlen ein paar fuer sowas noetige
Mechanismen). Deswegen ist es dringenst anzuraten nicht von der zu
kloneneden Platte zu booten (also von einer DVD oder rescue-partition).

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Martin Schwarz]

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> (Dateiinhalte ist nochmal ein komplett anderes Thema -- 'zig Frameworks
> in OS X bedienen sich Datenbank-Dateien, die ab und an geschrieben
> werden und die zum Teil aufeinander aufbauen. Weder kann beim Klonen
> eines gerade aktiven Systems sichergestellt werden, dass eine solche
> Datei gerade in sich konsistent ist, noch, dass zwei DB-Dateien, deren
> Inhalte aufeinander aufbauen zueinander konsistent geklont werden, wenn
> der Vorgang eine gewisse Zeit braucht [1])

Vielleicht eine dumme Frage, die ich mir bisher auch gar nicht gestellt
habe:

Wie geht Time Machine mit dieser Problematik um? Fordert es den
jeweiligen Prozess noch schnell auf, seine Caches zu flushen, bevor es
die DB-Datei von Platte liest? Die Alternative "nicht aus dem laufenden
System heraus kopieren" steht ja hier nicht zur Verf�gung.

Gru�
Martin
--
Martin Schwarz * Karlsruhe, Germany * http://kuroi.de/

[Juergen P. Meier]

Martin Schwarz <usene...@kuroi.inka.de>:

> Wie geht Time Machine mit dieser Problematik um? Fordert es den
> jeweiligen Prozess noch schnell auf, seine Caches zu flushen, bevor es

Wenn das jeweilige Programm die entsprechende API nutzt (die Apple um
entsprechende Methoden erweitert hat), dann stellt der jeweilige
Prozess ganz speziell fuer TM einen Snapshot seiner Dateien zur
Verfuegung. Das ist insbesondere fuer alle Programme Pflicht, die eine
Datenbank offenhalten (z.B. iTunes, iPhoto u.v.m). Alle Apple-eigenen
Programme sind voll TM-Tauglich, teilweise bieten sie sogar ueber die
Dateiweise Backup-funktion hinausgehende Funktionen (z.B. Mail.app).

Die grosse Mehrzahl aller anderen Programme haelt idR. keine
kritschen Dateien offen um darin live herumzuschreiben, da ist
das genau gar kein Problem.

Programme, die Dateien (z.B. Datenbanken) offen halten um darin
staendig herumzuschreiben, aber Apple's API Erweiterungen fuer TM
nicht nutzen (z.B. weil die Programmierer zu faul waren, oder das
Programm fuer 10.4 gemacht wurde und lediglich auf neuerem OSX
benutzt wird), haben halt verloren. Das ist aber bei *ALLEN*
Backup-Mechanismen so. Sektorweises Cloning eingeschlossen.
Da hilft nicht mal eine Snap-Shot funktion im Dateisystem (was es bei
HFS sowieso nicht gibt.)
Bei solchen Programmen hast du auch auf anderen Plattformen wie z.B.
Windows oder Linux verloren. Ganz grundsaetzlich.

> die DB-Datei von Platte liest? Die Alternative "nicht aus dem laufenden

> System heraus kopieren" steht ja hier nicht zur Verfï¿œgung.

Es gibt eine spezielle API dafuer.

[Thomas Kaiser]

Martin Schwarz schrieb am 04.01.2014 in <news:1leylcq.c64fsw1r1gg78N%usene...@kuroi.inka.de>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> (Dateiinhalte ist nochmal ein komplett anderes Thema -- 'zig
>> Frameworks in OS X bedienen sich Datenbank-Dateien, die ab und an
>> geschrieben werden und die zum Teil aufeinander aufbauen. Weder kann
>> beim Klonen eines gerade aktiven Systems sichergestellt werden, dass
>> eine solche Datei gerade in sich konsistent ist, noch, dass zwei
>> DB-Dateien, deren Inhalte aufeinander aufbauen zueinander konsistent
>> geklont werden, wenn der Vorgang eine gewisse Zeit braucht [1])
>
> Vielleicht eine dumme Frage, die ich mir bisher auch gar nicht
> gestellt habe:
>
> Wie geht Time Machine mit dieser Problematik um? Fordert es den
> jeweiligen Prozess noch schnell auf, seine Caches zu flushen, bevor es
> die DB-Datei von Platte liest?

Nein, die einzige "API" auf Backup-Seite existiert in der Möglichkeit,
Dateien von TimeMachine-Backups auszuschließen:

The Backup Core API includes a function you can use to exclude from
Backup temporary or otherwise unimportant folders and files your
application creates. In addition, you can use this function to allow
your users to make backup decisions from within the context of your
application.

> Die Alternative "nicht aus dem laufenden System heraus kopieren" steht

> ja hier nicht zur Verfügung.

Das ist ja unter anderem _der_ fundamentale Unterschied zwischen einem
blöden Klon und einem Backup: Ein Klon will eine 1:1-Kopie eines
bootbaren Systems sein, ein Backup ist genau das aber nie. Ein Backup
enthält wichtige System- und User-Daten sowie Software in konsistenter
Fassung und dient der Datenwiederherstellung.

Du kannst ein TimeMachine-Backup nicht direkt booten (nein, auch ab
10.7.2 nicht [1]) und das aus gutem Grund. Würdest Du einen Klon im
Notfall booten, so ist das auf einmal das Original und ohne weitere
Sicherungsschicht wäre dann Dein Pseudo-Backup (AKA Klon) ggf. aus dem
gleichen Grund futsch, der die eigentliche Installation oder die Daten
gehimmelt hat (Software läuft Amok, Schadsoftware, etc.)

Das Gute daran: Da bei einem Backup gar kein bootbarer Klon entstehen
muß, braucht man wahnsinnig viel gar nicht erst mitsichern. Und genau
das geschieht bei TimeMachine. Schon per default sind ganz viele Sachen,
bei denen solche kritischen Situationen auftreten könnten, exkludiert.
Nachschauen in der Shell per

defaults read /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions

(das sind die Standard-Ausnahmen, die anhand Pfad-Kriterien nie
gesichert werden) und

sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'"

(das sind alles Pfade, die per Extended Attribut von $irgendwem --
Apple, Softwarehersteller oder auch aufgeklärter User -- willentlich
vom Backup ausgeschlossen wurden. Gibt noch weitere Ausschlüsse, siehe
bspw. <http://pondini.org/TM/Works4.html>)

TimeMachine versucht ja bei jedem Lauf anhand des FSEvents-API zu
erkennen, in welchen Verzeichnissen sich was seit dem letzten Lauf
geändert hat (schlägt das fehl, dann muß es das komplette Quellvolume
untersuchen, was dann immer ziemlich lange dauert). Exakt der selbe
Mechanismus läuft aber auch während eines Backups weiter und am Ende
guckt TM nochmal nach, ob a) Dateien, die vorher nicht gesichert werden
konnten, weil sie offen/locked waren oder b) sich während des Backups
geänderte Dateien nochmal erneut zu sichern versucht werden sollen.
Schlägt auch dieser zweite Versuch fehl, dann war's das, die Datei wird
nicht gesichert und im Log wird das entsprechend vermerkt (auf die Tour
kann man auch Dateien im System haben, die nie gesichert werden können
und dann auch nicht werden).

Auf Programm(ierer)-Seite ist das bzgl. der Backup-Seite von TM ganz
simpel:

- Datenablage TM-kompatibel machen, d.h. eben keine großen DB-Dateien
pflegen sondern alles in kleine Dateibrocken im Dateisystem ablegen

- evtl. existente Datenbank-Dateien, die das Programm intern braucht, um
schneller auf Inhalte zuzugreifen, konzeptionell obsolet machen, d.h.
für Backup-Exklusion markieren und im Restore-Fall aus den kleinen per
TM gesicherten Dateibröckchen -- bspw. der Inhalt einzelner Mails --
die Datenbank wieder rekonstruieren (und genau das geschieht dann
auch, wenn man aus einem TM-Restore sein System neu aufsetzt, da kann
das Wiederanlegen diverser Indizes im Hintergrund den Rechner gerne
für paar Stunden unter Last halten)

- in Situationen, wo temporär Dateien entstehen, die eines Backups nicht
würdig sind, diese schon bei der Anlage passend per Extended Attribut
oder Pfad-Exklusion (siehe oben) markieren, d.h. abermals vom Backup
_ausschließen_.

Mehr an Backup-"API" gibt's bei TimeMachine nicht. Der ganze "Trick"
besteht darin, die Sachen so zu speichern, dass kleine Entitäten
(Dateibröckchen) draus werden und dass große Datenbanken gar nicht
mitgesichert werden müssen. Was völlig anderes ist die Restore-Seite: Da
bietet Apple entsprechende APIs an, um Programm_intern_ auf frühere per
TM gespeicherte _Objekte_ zuzugreifen (die allerdings physisch dann auch
nur wieder irgendwelche per TM gesicherten Dateien sind -- ein Beispiel
wären Kontakte im Adreßbuch, die auf Platte in Form irgendwelcher
Property Lists mit kryptischem Namen herumliegen, aber im Adreßbuch
selbst dann sinnvoll als Visitenkarten in früherer Version wieder
hergestellt werden können ohne dass man überhaupt wissen müsste, wo das
System solcherlei Kontakte-Property-List-Dateien überhaupt hinlegt).

Also nochmal in kurz: Es gibt kein Backup-API, weil's das nicht braucht,
da ein Backup per Definition keinen bootbaren Klon erstellt sondern
etwas, das per Restore erst wieder in ein lauffähiges System eingespielt
respektive verwandelt wird (und an der Stelle stellt sich das Problem
dieser offenen Datenbanken gar nicht, weil die erst gar nicht mitgesichert
werden [müssen]).

Gruss,

Thomas

[1] Ab 10.7.2 landet der bootbare Inhalt der "Recovery Partition" auf
direkt angeschlossenen TimeMachine-Backup-Disks, so dass man vom
TimeMachine-Medium in ein Notsystem booten kann, aus dem heraus man
dann ein Basis-System installieren oder aus der TM-Sicherung
wiederherstellen kann.