Update mit Macos X 10.6.3 und Safari 4.0.5
Matthias Peick
schon den zweiten Rechner zerhauen und ich würde gerne den „Schuldigen“
finden, bevor ich an den dritten gehe. Die beiden sind meine
Verdächtigen.
Das Neuaufsetzen geht mir etwas auf den Keks…
Joerg Lorenz
Klappte bei mir bei drei Intel-Macs von 10.6.2 und von 1 PPC von
10.5.8 (Security Update 2-2010).
Jimmy Jiiimz
Hi Matthias,
Ging hier problemlos. Intel iMac (early 2006)...
Jimmy
Juergen P. Meier
> Hat jemand beide Pakete in einem Rutsch aktualisiert? Mir hat es jetzt
> Verdächtigen.
Nicht gleichzeitig, d.h. nicht ohne Reboot dazwischen.
Einzeln ohne Probleme.
> Das Neuaufsetzen geht mir etwas auf den Keks?
Mit einem Timemachine-Backup ist das doch Kinderleicht und du kannst
einfach da weiterarbeiten, wo du das letzte Backup gemacht hast.
Thomas Kaiser
> Mit einem Timemachine-Backup ist das doch Kinderleicht und du kannst
> einfach da weiterarbeiten, wo du das letzte Backup gemacht hast.
Hast Du das schon mal selbst ausprobiert, d.h. kannst das wirklich guten
Gewissens empfehlen?
Gruss,
Thomas
Juergen P. Meier
Ja. Mittlerweile zweimal - den Umzug vom PowerPC-Mac auf den
Intel-Mac gar nicht mitgerechnet (bei dem auch mittels Timemachine
Backup&Restore zumindest der Benutzeraccount umgezogen wurde).
Aber OS X neu installieren, Timemachine Backup einspielen und einfach
Weiterarbeiten funktoinerte hier bisher beide male einfach so <mit den
Fingern schnipp>. Das erste mal noch unter 10.5/ppc, das zweite mal
unter 10.6/Intel.
Juergen
Dirk Wagner
> Hast Du das schon mal selbst ausprobiert, d.h. kannst das wirklich guten
> Gewissens empfehlen?
Ich kann!
So habe ich z.B. meinem MacbookPro eine größere Platte verpasst:
Backup, dann neue Platte rein. Von der Installations CD gebootet und die
entsprechende Option für's wiederherstellen gewählt.
Funktionierte problemlos...
Ciao
dirk
Dirk Wagner
Peter Brunner
> So habe ich z.B. meinem MacbookPro eine größere Platte verpasst:
> Backup, dann neue Platte rein. Von der Installations CD gebootet und die
> entsprechende Option für's wiederherstellen gewählt.
>
> Funktionierte problemlos...
By the way: Kann das Zielmedium ausgewählt werden, d.h. lässt sich das
Backup auch auf ein externes Laufwerk zurückspielen?
Ich hätte nämlich gerne das älteste vorhandene, noch jungfräuliche
System bootbar auf separatem Laufwerk für Experimente.
Gruss
Peter
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de>:
>> Juergen P. Meier schrieb in <news:23626.11684...@news.jors.net>
>>> Mit einem Timemachine-Backup ist das doch Kinderleicht und du kannst
>>> einfach da weiterarbeiten, wo du das letzte Backup gemacht hast.
>>
>> Hast Du das schon mal selbst ausprobiert, d.h. kannst das wirklich
>> guten Gewissens empfehlen?
>
> Ja. Mittlerweile zweimal - den Umzug vom PowerPC-Mac auf den
> Intel-Mac gar nicht mitgerechnet (bei dem auch mittels Timemachine
> Backup&Restore zumindest der Benutzeraccount umgezogen wurde).
Äh, also _nicht_ per Migrations-Assistent (der sich ja auch aus einem
TM-Backup bedienen kann)? Falls ja, warum?
> Aber OS X neu installieren, Timemachine Backup einspielen und einfach
> Weiterarbeiten funktoinerte hier bisher beide male einfach so <mit den
> Fingern schnipp>. Das erste mal noch unter 10.5/ppc, das zweite mal
> unter 10.6/Intel.
Hmm...
Ich hab ja früher auch das Hohelied von TimeMachine gesungen (und finde
den grundsätzlichen Ansatz und die idiotensichere Umsetzung weiterhin
genial). Aber ein riesiges Problem sind IMO die Exclusions, also was
alles eben nicht ins Backup wandert, gerade wenn man einen kompletten
Restore vorhat, denn wo kein komplettes Backup, da kein kompletter
Restore möglich. :-(
Und es fehlt einfach viel zu viel in einem TimeMachine-Backup als das
man einfach so ein Komplett-Restore einspielen könnte und anschließend
so weiterarbeiten könnte, als ob nichts gewesen wäre.
Konkret: Was wird nicht gesichert:
* Alles, was Apple via StdExclusions.plist ausschließt, unter anderem
alle Logs (sehr "schlau", wenn man nach Einspielen des Restores gucken
will, warum das System, das man restaurieren musste, vorher in
Schieflage geriet), Teile des Unix-Unterbaus, bspw. Ordner, die
Postfix oder Apache2 brauchen, um überhaupt zu starten, unter MacOS X
Server "praktischerweise" auch gleich noch *ALLE MAILS ALLER USER*,
die unterhalb /var/spool/imap/user/ liegen, da /var/spool komplett
ausgeschlossen ist, etc. etc.
Außerdem sämtliche Cache-Folder, in denen viele Programme Proxy-
Dateien für Spotlight unterbringen. Was hier fehlt, nach dem kann nach
dem Restore auch nicht gesucht werden. D.h. neben einer allgemeinen
Reindizierungs-Orgie, die Spotlight auf einem frisch aus TM-Backup
restaurierten System anstößt, ist es nötig *jedes* einzelne Programm,
das sich diesen Spotlight-Indizierungs-Mechanismen bedient, einmal
mindestens wieder zu starten, damit das Neuerstellungs-Gerödel für
diese Cache-Dateien beginnt und sich anschl. dann Spotlight erst drauf
stürzen kann (bei meinem kleinen NetBook dauerte das Reindizieren des
ganzen Schrotts ca. die dreifache Zeit, die der Restore an sich
brauchte -- und das NetBook hat nur eine 16 Gbyte SSD + 16 GByte
SD-Card)
Man schaue einfach mal in /Library/Caches/ (nicht sooo spannend) bzw.
vor allem mal in ~/Library/Caches/, v.a. dort der "Metadata"-Ordner",
inwiefern einen das betrifft.
Bzgl. dem, was alles auf dem Weg global ausgeschlossen wird, einfach
nachschauen:
defaults read /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions
* Dann gibt es noch eine globale Preference abseits StdExclusions.plist,
die ebenfalls Ausschlüsse definiert, an die man so per GUI erstmal
nicht drankommt. Abermals: Einfach nachschauen:
defaults read /Library/Preferences/com.apple.TimeMachine ExcludeByPath
* Dann noch alles, was passende EAs drankleben hat (also unter anderem
Covers von iTunes). Wiederum einfach nachgucken:
mdfind com_apple_backup_excludeItem = "com.apple.backupd"
* Und dann erst wird noch das ausgeschlossen, was der _User selbst_ will
und in den System Preferences einstellen kann:
defaults read /Library/Preferences/com.apple.TimeMachine SkipPaths
Dieser letzte Punkt ist wohl der Uninteressanteste (weil willentlich
vom Backup ausgeschlossen). Aber all das andere da oben ergibt in
Summe ein dermaßen unvollständiges Backup, daß das Versprechen, man
könnte nach einem daraus hergestellten _Komplett_-Restore wie zuvor
weiterarbeiten, schlichtweg falsch ist (Systemdienste wie Postfix +
Apache2 starten erst gar nicht, Spotlight ist nicht nutzbar bzw.
rödelt in Extremfällen schon mal einen halben bis ganzen Tag vor sich
hin, es fehlen Nutzerdaten von denen iTunes-Cover noch die harmlosesten
sind -- wie schon geschrieben: Wer unter MacOS X Server auf die
integrierten Mailservices setzt und auf TM vertraut, der sichert
seinen Maildatenbestand *nicht*
Es hängt natürlich alles auch ein bisserl davon ab, was man mit dem
TM-Backup überhaupt anstellt, denn es gibt ja verschiedene Optionen, das
Backup im Restore-Fall zu nutzen:
* Standard-Restore AKA "Desaster Recovery": Von System-DVD booten und
den Menüpunkt "Time Machine Backup einspielen" nutzen (mit der 10.6er
DVD lassen sich auf dem Weg sowohl 10.5- als auch 10.6-Installationen
zurücksichern). Das ist die katastrophalste Variante, weil sich
hierbei die Lücken im Backup am drastischsten auswirken (siehe oben).
Das Versprechen lautet: Du kriegst einen 1:1 Restore Deines vormaligen
Systems ohne jegliche Notwendigkeit, irgendwas neu zu installieren,
herumzufummeln, etc. -- die Umsetzung hakt leider enorm, weil das
Backup weit davon entfernt ist, für diesen Zweck vollständig zu sein.
* Neuinstallieren des Systems und manuelles Drüberstopfen eines
Komplett-Restores. Man hat anschließend einen Mischmasch aus
verschiedenen System-Versionen (Zeugs der Standard-Installation und
Zeugs aus dem Backup), d.h. Einspielen des letzten Combo-Updates ist
Pflicht (aber keineswegs Garantie, daß man nicht doch in irgendwelche
obskuren Probleme anschließend rennt, die aus dem Mischmasch
resultieren). Probleme mit nicht startenden Diensten hat man auf dem
Weg eher nicht aber das Spotlight-Gerödel trifft einen trotzdem.
* Bisserl sinniger (weil eine semi-intelligente aber vollautomatische
Komponente im Spiel): Neuinstallation des Systems, dann gleich den
Migrations-Assistenten aufrufen und aus dem TM-Backup Daten migrieren
lassen. Auch hier sollte man das letzte Combo-Update einspielen. Und
auch das schützt einen nicht vor nicht mehr existenten Cache-Dateien
(also Spotlight-Geröde und teils riesige Latenzen beim ersten Aufruf
mancher Programme)
* Neuaufsetzen des Systems und lediglich Restaurierung von Benutzer-
Accounts: Wenn man sich eh schon für aufwändige Handarbeit anstatt
Einspielen eines möglichst vollständigen Backups (das ja bei TM
systemimmanent nicht geht) entschieden hat, wird einem das ganze
"Caches neu aufbauen" und Spotlight-Gerödel noch nicht mal groß
auffallen. Hier dürfte die "User Experience" am Besten ausfallen
(alleine schon das alberne Gefühl, wieder ein "sauberes System" am
Laufen zu haben...)
Fazit: Wo kein vollständiges Backup, da kein Komplett-Restore möglich.
Ein Restore zieht immer mehr oder weniger manuelle Nacharbeit und
(eigentlich vermeidbares) mit-sich-selbst-Beschäftigung des Systems
(Caches und Indizes wieder aufbauen, etc.) nach sich.
Das ist natürlich kein Argument gegen TimeMachine und für Blöd-Kloning
(wie es viele ja trotz TimeMachine nach wie vor anstelle Backup
betreiben und sich dabei nur vor einer einzigen möglichen Datenverlust-
Quelle, zumal einer höchst seltenen, nämlich Harddisk-Ausfall, schützen)
Es ist eher die Anregung, zusätzlich zu einem überaus sinnvollen
Nutzdaten-Backup (via TimeMachine) ab und zu einen Komplett-Klon des
Systems anzufertigen. So ein Klon, auf den man im Bedarfsfall das
aktuellste Komplett-Restore via TimeMachine klatscht, erscheint mir zur
Zeit als die beste Variante des "Desaster Recovery" -- MacOS X 10.5/10.6
vorausgesetzt natürlich.
Gruss,
Thomas, noch <http://earthlingsoft.net/ssp/blog/2008/03/x5_time_machine>
wärmstens empfehlend, falls einen weitere TM-Fallstricke interessieren...
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Hast Du das schon mal selbst ausprobiert, d.h. kannst das wirklich
>> guten Gewissens empfehlen?
>
> Ich kann!
>
> So habe ich z.B. meinem MacbookPro eine größere Platte verpasst:
> Backup, dann neue Platte rein. Von der Installations CD gebootet und die
> entsprechende Option für's wiederherstellen gewählt.
Aha, die "entsprechende". Gibt ja schließlich nur eine...
> Funktionierte problemlos...
Klar, der Restore funktionierte problemlos. Das Spannendere ist, ob man
danach einfach "so wie vorher" weiterwerkeln kann. Und das ist nicht der
Fall, wenn die Restore-Quelle eine TimeMachine-Backup war (da zu
unvollständig), egal ob Du's bemerkt hast oder nicht. :-)
Details bspw. hier: <news:slrnhrbgjk.2qb...@phg-online.de>
Im Fall eines Laufwerk-Tausches würde ich entweder einfach von altem
Laufwerk auf neues klonen (oder noch die Variante "Sicherheit" ins Spiel
bringen und vor dem Umbau noch einen Komplett-Klon irgendwohin anlegen)
oder aber -- wenn bisserl Tabularasa angesagt ist, d.h. man das System
ein klein wenig entschlacken und aufräumen lassen will im Rahmen des
Plattenumbaus -- dann Neuinstallation und Migration allen Krams per
Migrations-Assistent direkt im Rahmen der Installation (der IMO beste
Kompromiß bzgl. "so wenig wie nötig manuell anpassen" und "so frisch wie
möglich")
Gruss,
Thomas
Klaus Behrends
> Dirk Wagner <usenet...@diwasoft.de> wrote:
> ...
> By the way: Kann das Zielmedium ausgewählt werden, d.h. lässt sich das
> Backup auch auf ein externes Laufwerk zurückspielen?
Ja. Mehrfach ausprobiert, statt Klon per Superduper!
Gruß Klaus
Reindl Wolfgang
> On 1 Apr., 15:01, Matthias Peick<matth...@peick.de> wrote:
>> Hat jemand beide Pakete in einem Rutsch aktualisiert? Mir hat es jetzt
>> schon den zweiten Rechner zerhauen
Was meinst Du konkret mit "zerhauen"?
> Klappte bei mir bei drei Intel-Macs von 10.6.2 und von 1 PPC von
> 10.5.8 (Security Update 2-2010).
Bei meinem G5 10.5.8: Security Update 2-2010 und Safari 4.0.5 "in einem
Rutsch" (und noch ein paar andere Updates gleichzeitig):
Es erschienen Programme im Doc, die ich normalerweise nicht dort liegen
hab', und die Zugangsdaten zum ISP waren irgendwie zerschossen, mußte
ich aus den Daten vom Wohnzimmer-(Intel-)Mini wiederherstellen, war
etwas nervig.
Ansonsten hab' ich in den vergangenen 2 Tagen noch keine weiteren
Probleme feststellen müssen.
Wolfgang, den Mini werd' ich dann vermutlich zizerlweise renovieren.
Peter Brunner
> > By the way: Kann das Zielmedium ausgewählt werden, d.h. lässt sich das
> > Backup auch auf ein externes Laufwerk zurückspielen?
>
> Ja. Mehrfach ausprobiert, statt Klon per Superduper!
Prima - danke für die Info!
> Gruß
Peter
Thomas Kaiser
War der 1. April nicht bereits gestern?
Gruss,
Thomas
Peter Brunner
Tja, das hilft mir jetzt nicht wirklich weiter - Du meinst also, ein
TM-Backup sei nicht auf einem externen Laufwerk wiederherstellbar?
Jetzt bin ich wirklich etwas verunsichert, ob Du allenfalls nur auf das
Reizwort "Klon" anspielst, wegen der von Dir weiter oben im Thread
monierten Fragwürdigkeit des TM-Komplettbackups.
Denn: ich habe die Installer-DVD ausgegraben und es mal versucht, mit
dem TM-Laufwerk und einer weiteren FireWire-Platte am MacBook Pro; bei
dem Schritt, wo man das wiederzubelebende Backup aus der TimeMachine
selektiert, war oben zwar auch ein Auswahlfeld fürs Zielmedium, aber
angegraut und ohne weitere Möglichkeiten ausser "MacintoshHD auf MacBook
Pro"; ich habe mich allerdings nicht getraut, auf "Weiter" zu klicken,
denn meinen Mac will ich ja nicht plattmachen, und da ich noch nie einen
Komplett-Restore gemacht habe, kenne ich den Ablauf des Prozedere nicht.
Wäre mir die leere, angehängte Disk noch präsentiert worden?
Gruss
Peter
Hannes Gnad
Hallo.
> >> Hat jemand beide Pakete in einem Rutsch aktualisiert? Mir hat es jetzt
> >> schon den zweiten Rechner zerhauen
> Was meinst Du konkret mit "zerhauen"?
Schließe mich dieser Frage an.
> > Klappte bei mir bei drei Intel-Macs von 10.6.2 und von 1 PPC von
> > 10.5.8 (Security Update 2-2010).
> Bei meinem G5 10.5.8: Security Update 2-2010 und Safari 4.0.5 "in einem
> Rutsch" (und noch ein paar andere Updates gleichzeitig):
Wie immer die Softwareaktualisierung fahren, was die halt
anbietet...
> Es erschienen Programme im Doc, die ich normalerweise nicht dort liegen
> hab', und die Zugangsdaten zum ISP waren irgendwie zerschossen, mußte
> ich aus den Daten vom Wohnzimmer-(Intel-)Mini wiederherstellen, war
> etwas nervig.
Schon das ist alles recht komisch - bei unseren Kunden unter
der Woche ein paar Dutzend Maschinen aktualisiert, und keine
solchen Effekte gesehen. Was macht Ihr bloß?
--
Beste Gruesse, Hannes Gnad h.g...@apfelwerk.de
Apple Distinguished Professional http://www.apfelwerk.de
Der Apfelwerk-Blog, live aus dem Alltag --- http://www.apfelwerk.de/blog
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Peter Brunner schrieb in <news:1jgbygd.hn2smr4xc8aN%bitsh...@gmx.ch>
>> > Klaus Behrends <bk.be...@t-online.de> wrote:
>> >> > By the way: Kann das Zielmedium ausgewählt werden, d.h. lässt
>> >> > sich das Backup auch auf ein externes Laufwerk zurückspielen?
>> >>
>> >> Ja. Mehrfach ausprobiert, statt Klon per Superduper!
>> >
>> > Prima - danke für die Info!
>>
>> War der 1. April nicht bereits gestern?
>
> Tja, das hilft mir jetzt nicht wirklich weiter - Du meinst also, ein
> TM-Backup sei nicht auf einem externen Laufwerk wiederherstellbar?
Keine Ahnung, noch nie ausprobiert. Mir kam Euer Dialog nur etwas ...
äh, "wirr" vor:
Peter Brunner: "Kann man Suppe auch in flachen oder nur in tiefen
Tellern servieren?"
Klaus Behrends: "Flache Teller hab ich mehrfach ausprobiert, aber mit
Frikadellen (keine Buletten!) statt Suppe"
Peter Brunner: "Prima - danke für die Info!"
Ich hätte viel eher ein "<Loriot>Ach?!</Loriot>" erwartet, drum ging ich
erstmal von einer mir noch unbekannten Form von Humor aus. Inzwischen
drängt sich aber der Verdacht auf, daß Ihr das beide völlig ernstgemeint
habt? :-)
> Jetzt bin ich wirklich etwas verunsichert, ob Du allenfalls nur auf das
> Reizwort "Klon" anspielst, wegen der von Dir weiter oben im Thread
> monierten Fragwürdigkeit des TM-Komplettbackups.
Das eine hat mit dem anderen nix zu tun. Wenn Dir jemand eine Frage nach
Time Machine mit "SuperDuper!" beantwortet (das halt nur Klons
beherrscht und sonst gar nix), dann weiß ich nicht so wirklich,
inwiefern Dir so eine Antwort was bringt. Geht mich aber letztlich auch
nix an :-)
Wie in <news:slrnhrbgjk.2qb...@phg-online.de> schon
dargelegt, halte ich aktuell einen periodisch aktualisierten Klon (der
bspw. per SuperDuper! erzeugt wird) für eine ideale Ergänzung zu
TimeMachine, da bedingt durch TMs Auslassungen ein Restore aus einem
TM-Backup einfach nicht vollständig sein kann.
Was weder was dran ändert, daß mit SuperDuper! nur Klone angefertigt
werden können (zwar auch inkrementell aber eben ohne jede Versionierung,
etc. -- das Ergebnis ist immer nur ein stumpfer Klon) noch daß Time
Machine schon mit default-Settings eine nahezu perfekte Einzelplatz-
Backup-Lösung darstellt.
Gruss,
Thomas
Peter Brunner
Erstmal pardon fürs gestapelte Quote oben, bin grad zu bequem, es
einzudampfen...
Also, bei allem Respekt vor sophistischer Differenziertheit: Ich habe
Klaus Behrends Antwort schlicht so verstanden, dass er mit TimeMachine
erfolgreich ein Backup auf ein externes Laufwerk zurückspielen konnte
und dieses auch als bootbares Volume verwendbar ist. Mehr wollte ich
eigentlich nicht wissen. Von Super Duper habe ich zugegebenermassen
bloss angehauchte Ahnung, insofern ist die von dir vermutete unbekannte
Form von Humor möglicherweise ein unfreiwilliges Artefakt ;-)
Um's kurz und konkret zu machen: Ich möchte eine alte Version aus meiner
TimeMachine-Mottenkiste auf einem externen Laufwerk auferstehen lassen,
um darauf eine zeitlimitierte Trialversion eines Programms nochmals neu
zu installieren.
Kann ich denn nun?
Gruss
Peter
Matthias Peick
>> Das Neuaufsetzen geht mir etwas auf den Keks?
>
> Mit einem Timemachine-Backup ist das doch Kinderleicht und du kannst
> einfach da weiterarbeiten, wo du das letzte Backup gemacht hast.
Nein. Time-Machine hat versagt. Das Betriebssystem lief zwar, aber
praktisch alle Anwendungen st�rzten ab.
Matthias Peick
> Es ist eher die Anregung, zus�tzlich zu einem �beraus sinnvollen
> Nutzdaten-Backup (via TimeMachine) ab und zu einen Komplett-Klon des
> Systems anzufertigen. So ein Klon, auf den man im Bedarfsfall das
> aktuellste Komplett-Restore via TimeMachine klatscht, erscheint mir zur
> Zeit als die beste Variante des "Desaster Recovery" -- MacOS X 10.5/10.6
> vorausgesetzt nat�rlich.
Ja, sowas wird es das n�chste Mal wohl werden.
Matthias Peick
> Aber OS X neu installieren, Timemachine Backup einspielen und einfach
> Weiterarbeiten funktoinerte hier bisher beide male einfach so <mit den
Sowohl meine Finder-Konfiguration als auch iTunes waren nicht sauber.
Mal sehen, was ich noch finden werde.
Matthias Peick
> Am 01.04.10 15:43, schrieb Joerg Lorenz:
>> On 1 Apr., 15:01, Matthias Peick<matth...@peick.de> wrote:
>>> Hat jemand beide Pakete in einem Rutsch aktualisiert? Mir hat es jetzt
>>> schon den zweiten Rechner zerhauen
>
> Was meinst Du konkret mit "zerhauen"?
Nicht startfähig. Wobei ich die Aussage für den zweiten Rechner
zurückziehe, er hat „nur“ zwei Stunden gebraucht.
Klaus Behrends
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
> > Peter Brunner schrieb in <news:1jgc1uu.cwgeup16vflbbN%bitsh...@gmx.ch>
> ---
> Um's kurz und konkret zu machen: Ich möchte eine alte Version aus meiner
> TimeMachine-Mottenkiste auf einem externen Laufwerk auferstehen lassen,
> um darauf eine zeitlimitierte Trialversion eines Programms nochmals neu
> zu installieren.
>
> Kann ich denn nun?
>
> Gruss
> Peter
Was für eine blöde Diskussion.
Ja, Du kannst.
Ich habe mehrfach aus einem TM-Backup ein komplettes Restore auf eine
externe Festplatte vorgenommen, indem ich von der MacOS-X-DVD gestartet
und als Zielmedium eine externe Festplatte angegeben habe.
Basta.
Ich habe das getan, um auszuprobieren, ob das Restore funktioniert.
Dabei habe ich eine externe Festplatte gewählt, auf die ich
nirmalerweise per Superduper! von Zeit zu Zeit einen Klon herstelle, von
dem ich im Notfall starten kann.
Von dem per TM hergestellten Restore konnte ich genau so gut starten.
Das wollte ich wissen.
Gruß Klaus
Juergen P. Meier
> Juergen P. Meier schrieb in <news:23628.13248...@news.jors.net>
>> Thomas Kaiser <Thomas...@phg-online.de>:
>>> Juergen P. Meier schrieb in <news:23626.11684...@news.jors.net>
>>>> Mit einem Timemachine-Backup ist das doch Kinderleicht und du kannst
>>>> einfach da weiterarbeiten, wo du das letzte Backup gemacht hast.
>>>
>>> Hast Du das schon mal selbst ausprobiert, d.h. kannst das wirklich
>>> guten Gewissens empfehlen?
>>
>> Ja. Mittlerweile zweimal - den Umzug vom PowerPC-Mac auf den
>> Intel-Mac gar nicht mitgerechnet (bei dem auch mittels Timemachine
>> Backup&Restore zumindest der Benutzeraccount umgezogen wurde).
>
> Äh, also _nicht_ per Migrations-Assistent (der sich ja auch aus einem
> TM-Backup bedienen kann)? Falls ja, warum?
Weil ich dem Teil anfangs nicht traute. Schlechte Erfahrungen mit
anderen Betruebsystemen. Aber ich habe jetzt bei einem Kollegen und
zwei Bekannten schon gesehen, dass das Teil problemarm recht genau das
macht, was man erwaret.
>> Aber OS X neu installieren, Timemachine Backup einspielen und einfach
>> Weiterarbeiten funktoinerte hier bisher beide male einfach so <mit den
>> Fingern schnipp>. Das erste mal noch unter 10.5/ppc, das zweite mal
>> unter 10.6/Intel.
>
> Hmm...
>
> Ich hab ja früher auch das Hohelied von TimeMachine gesungen (und finde
> den grundsätzlichen Ansatz und die idiotensichere Umsetzung weiterhin
> genial). Aber ein riesiges Problem sind IMO die Exclusions, also was
> alles eben nicht ins Backup wandert, gerade wenn man einen kompletten
> Restore vorhat, denn wo kein komplettes Backup, da kein kompletter
> Restore möglich. :-(
Man benoetigt halt immer die Originalinstallationsmedien von
Software. ABer da ist es halt auch gegeben, dass die Neuinstallation
der Software gefolgt vom Ruecksichern der Einstellungen vom Backup
idR. mindestens genauso schnell gehen wie das Ruecksichern eines
Vollbackups.
Ich kenne es eigentlich nur so, dass man aus Effizienzgruenden keine
unnoetigen (weil eh auf Datentraegern vorhandenen) Dateien sichert.
Von daher passt TM pefekt zu meiner Arbeitsweise bei Backups:
Die Orginalmedien im Schrank auf Datentraegern die lange halten, ggf.
mit Backups auf Datentraegerkopien, und auf dem Backup nur die
Dateien, die nicht auf den Originalmedien zu finden sind bzw.
veraenderlich sind.
> Und es fehlt einfach viel zu viel in einem TimeMachine-Backup als das
> man einfach so ein Komplett-Restore einspielen könnte und anschließend
> so weiterarbeiten könnte, als ob nichts gewesen wäre.
>
> Konkret: Was wird nicht gesichert:
>
> * Alles, was Apple via StdExclusions.plist ausschließt, unter anderem
> alle Logs (sehr "schlau", wenn man nach Einspielen des Restores gucken
> will, warum das System, das man restaurieren musste, vorher in
> Schieflage geriet), Teile des Unix-Unterbaus, bspw. Ordner, die
Hmm, Logfiles von einem Backup halte ich fuer unspannend. Dort steht
bestimmt nicht, warum das Restore noetig war, denn zum Zeitpunkt des
Backups war ja noch alles in Ordnung.
> Postfix oder Apache2 brauchen, um überhaupt zu starten, unter MacOS X
Welche waeren das?
In meiner StdExclusions.plist kann ich kein Verzeichnis erkennen, dass
Postfix oder Apache zum Arbeiten benoetigen.
> Server "praktischerweise" auch gleich noch *ALLE MAILS ALLER USER*,
> die unterhalb /var/spool/imap/user/ liegen, da /var/spool komplett
> ausgeschlossen ist, etc. etc.
Hmm, das wuerde ich auch als Defekt bzw. Mangel bezeichnen und Apple
zur Abstellung auffordern.
Allerdings ist /var/spool bei meiner (10.6.3) Datei nicht in der Liste.
(lediglich var/spool/cups, var/spool/fax und var/spool/uucp)
Aber das ist kein Server-OSX, von daher kann ich nicht beurteilen ob
das dort den selben Inhalt haben muesste.
> Außerdem sämtliche Cache-Folder, in denen viele Programme Proxy-
> Dateien für Spotlight unterbringen. Was hier fehlt, nach dem kann nach
Programme, die notwendige persistente Dateien in Cache-Verzeichnissen
unterbringen sind DEFEKT.
Da hat Timemachine nichts weiter mit zu tun. Beschwer dich bei den
Idioten, die diese Programme verbrochen haben oder verwende
Alternativen die nicht derart kaputt sind.
> dem Restore auch nicht gesucht werden. D.h. neben einer allgemeinen
Also wirklich, nach dinem Restore kannst auch du es ertragen, einmal
neu Indizieren zu lassen.
> Reindizierungs-Orgie, die Spotlight auf einem frisch aus TM-Backup
> restaurierten System anstößt, ist es nötig *jedes* einzelne Programm,
> das sich diesen Spotlight-Indizierungs-Mechanismen bedient, einmal
> mindestens wieder zu starten, damit das Neuerstellungs-Gerödel für
Das ist fuer diesen einen speziellen Anwendungsfall IMO ertragbar.
Schlimmer waere es, wenn fuer alle anderen Anwendungsfaelle von TM
(partielle Restores) inkonsistente Spotlight-Indizes dich bei der
Suche in die Irre fuehren wuerden.
Nein, diesen Kritikpunkt akzeptiere ich so nicht. ICh bin vielmehr der
Meinung, dass das ein wohldefiniertes Verhalten von TM ist, und kein Fehler.
> diese Cache-Dateien beginnt und sich anschl. dann Spotlight erst drauf
> stürzen kann (bei meinem kleinen NetBook dauerte das Reindizieren des
> ganzen Schrotts ca. die dreifache Zeit, die der Restore an sich
> brauchte -- und das NetBook hat nur eine 16 Gbyte SSD + 16 GByte
> SD-Card)
>
> * Dann gibt es noch eine globale Preference abseits StdExclusions.plist,
> die ebenfalls Ausschlüsse definiert, an die man so per GUI erstmal
> nicht drankommt. Abermals: Einfach nachschauen:
>
> defaults read /Library/Preferences/com.apple.TimeMachine ExcludeByPath
Und, wieder ausschliesslich Caches mit transienten Dateien bei denen
Backup und vorallem ein Restore keinerlei Sinn machen, weil sie nur
den aktuellen Anwendungsstatus reflektieren (z.B. Safari
Webicons-Cache, Calendar Cache etc.)
> * Dann noch alles, was passende EAs drankleben hat (also unter anderem
> Covers von iTunes). Wiederum einfach nachgucken:
>
> mdfind com_apple_backup_excludeItem = "com.apple.backupd"
Hmm, einzig "Music/iTunes/iTunes Music Library.xml" faellt auf.
Das sollte man doch explizit sichern.
Der Rest sind wieder nur Caches die keinerlei Datenverlust beinhalten.
> * Und dann erst wird noch das ausgeschlossen, was der _User selbst_ will
> und in den System Preferences einstellen kann:
>
> defaults read /Library/Preferences/com.apple.TimeMachine SkipPaths
> Dieser letzte Punkt ist wohl der Uninteressanteste (weil willentlich
Ja. Wowereit.
> vom Backup ausgeschlossen). Aber all das andere da oben ergibt in
> Summe ein dermaßen unvollständiges Backup, daß das Versprechen, man
> könnte nach einem daraus hergestellten _Komplett_-Restore wie zuvor
> weiterarbeiten, schlichtweg falsch ist (Systemdienste wie Postfix +
> Apache2 starten erst gar nicht, Spotlight ist nicht nutzbar bzw.
Welchen Unterschied macht hier der OS X server gegenueber dem Client?
Auf OS X Client kann ich keinen Ausschluss finden, der postfix oder
apache in irgendeiner Weise stoeren koennte.
> rödelt in Extremfällen schon mal einen halben bis ganzen Tag vor sich
Spotlight roedelt *immer*. Das allerdings nur im Hintergrund und mit
niedrigster Prioritaet und nur dann wenn sonst nix anderes Ressourcen
belegt.
Works as Designed.
Und selbst du willst nach einem partieillen Restore keine Spotlight
Indizes haben, die deinen Anwendern irgendwelche nicht laenger (oder
nicht restaurierte) Dateien enthalten...
> hin, es fehlen Nutzerdaten von denen iTunes-Cover noch die harmlosesten
> sind -- wie schon geschrieben: Wer unter MacOS X Server auf die
> integrierten Mailservices setzt und auf TM vertraut, der sichert
> seinen Maildatenbestand *nicht*
Mangels OSX server kann ich das nicht nachvollziehen. Beim Client wird
/private/var/spool/mail durchaus mitgesichert.
> Es ist eher die Anregung, zusätzlich zu einem überaus sinnvollen
> Nutzdaten-Backup (via TimeMachine) ab und zu einen Komplett-Klon des
> Systems anzufertigen. So ein Klon, auf den man im Bedarfsfall das
> aktuellste Komplett-Restore via TimeMachine klatscht, erscheint mir zur
> Zeit als die beste Variante des "Desaster Recovery" -- MacOS X 10.5/10.6
> vorausgesetzt natürlich.
Natuerlich. Ein Klon ist fuer DR die einfachste, effizienteste,
schnellste und bequemste Variante. Zudem ist das mit Bordmitteln anlegbar.
Fuer den Anwender (fuer den ist TM konzpiert) ist TM hingegen eine
brauchbares Backupsystem. Bei einem Server benoetigt man sowieso ein
angepasstes Backupsystem, dass dem Backupkonzept entspricht. Hierfuer
kann TM geeignet sein, aber eher nicht in der Defaultkonfiguration
(die Voreinstellungen und Excludes kann man ja modifizieren).
Juergen
Juergen P. Meier
Failsafe Vorgehensweise:
1) OS installieren. (beim User Anlegen darauf achten, dass dieser
genau so heist wie der erste User beim originalen System)
2) Patches (bis mind. auf den Stand des Backups) einspielen
3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
saubere Treiber die sich nicht in /System einnisten sind kein Problem)
4) TM Restore machen.
5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
halten) nachinstallieren.
6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
Danach sollte selbst ein von obskuren Anwendungen sprotzendes System
wieder so laufen wie vorher.
Ansonsten: Finger weg von all zu unsauberen Apps/Hacks die das System
manipulieren, denn natuerlich steoert sich das mit einem
Systemkonformen Backupkonzept.
Peter Brunner
> Ich habe mehrfach aus einem TM-Backup ein komplettes Restore auf eine
> externe Festplatte vorgenommen, indem ich von der MacOS-X-DVD gestartet
> und als Zielmedium eine externe Festplatte angegeben habe.
Das war meine Kernfrage, und so habe ich Deine erste Antwort auch
verstanden. Dann kommt die Auswahlmöglichkeit also im nächsten Schritt
(siehe mein vorheriges Posting; mich machte bloss etwas unsicher, dass
die externe Platte - noch? - nicht aufgeführt war). Es wird ja
hoffentlich wohl so sein, dass vor dem definitven Begin des
Überschreibens eine Rückversicherung kommt ("wird gelöscht, wollen Sie
wirklich" oder irgend etwas in der Art).
> Basta.
Grazie.
Peter
Peter Brunner
> Peter Brunner <bitsh...@gmx.ch> wrote:
>
> > Kann ich denn nun?
>
> Das Tolle an einem Backup ist, dass es erst dann etwas wert ist, wenn
> man ein Restore erfolgreich getestet hat.
> Niemand, der professioniell arbeitet, würde sich hier auf ein posting
> aus dem usenet verlassen. Er muss es schon selbst testen.
> Und wenn er drauf verzichten will, setzt er sich dem Verdacht aus, dass
> seine Daten nicht ernst nimmt.
> Oder willst Du Dich absichtlich zum Kasper machen?
Hallo Daniel
Wie aus meiner Anfrage zu ersehen ist, geht es mir hier nicht um ein
existenzielles Backup meiner Daten, sondern darum, für mehr spielerische
Zwecke eine alte Systemversion auf einer externen Platte wiedererstehen
zu lassen. Wenn's klappt - prima. Wenn nicht - so what, neuer Versuch.
Nix Kasper.
Dass der Ernstfall, also ein volles Restore aus TimeMachine auf dem
MacBook, auch wirklich so funktionieren würde, wie Apple das verspricht,
nehme ich allerdings einfach mal an - ich hab denen schliesslich auch
schon diverse Computer abgekauft in der blinden Annahmen, dass die
Dinger auch funktionieren und nicht bloss britzeln und flackern...
Peter
Goetz Hoffart
> Man benoetigt halt immer die Originalinstallationsmedien von
> Software.
Nicht zwingend: Ich mach mir immer einen Klon des
Installationsmediumsinhaltes auf eine zweite, kleine 20 GB-Partition des
TM-Laufwerks. Dann kann ich direkt von dem booten.
> Auf OS X Client kann ich keinen Ausschluss finden, der postfix oder
> apache in irgendeiner Weise stoeren koennte.
Auf MOSX Server 10.5.8 sichert TimeMachine jedenfalls /var/spool nicht.
Und das ist ziemlich schade, denn da sind blöderweise die
Mail-Postfächer drin:
---------------------------------------
bash-3.2$ sw_vers
ProductName: Mac OS X Server
ProductVersion: 10.5.8
BuildVersion: 9L30
bash-3.2$ pwd
/Volumes/Serverplatte/var/spool
bash-3.2$ sudo du -sh *
[...]
3.4M cups
0B fax
16G imap
0B mqueue
16K postfix
[...]
bash-3.2$ ls -la
total 0
drwxr-xr-x 11 root wheel 374 Jan 21 2009 .
drwxr-xr-x 32 root wheel 1088 Jun 1 2008 ..
drwxrwxrwx 2 nobody nobody 68 Jan 21 2009 PDFMaker
drwxrwx--- 2 _jabber _jabber 68 Sep 10 2008 conference.localhost
drwxrwx--- 3 _jabber _jabber 102 Jan 20 11:20
conference.HOSTNAME.de
drwx--x--- 274 root _lp 9316 Mar 31 11:22 cups
drwxr-x--- 2 root wheel 68 Sep 24 2007 fax
drwxr-xr-x 5 _cyrus mail 170 Jun 2 2008 imap
drwxr-x--- 2 root wheel 68 Sep 23 2007 mqueue
drwxr-xr-x 16 root wheel 544 Sep 25 2007 postfix
drwxr-xr-x 2 _uucp wheel 68 Sep 24 2007 uucp
---------------------------------------
---------------------------------------
bash-3.2$ pwd
/Volumes/TM/Backups.backupdb/HOSTNAME/Latest/Serverplatte/var/spool
bash-3.2$ ls -la
total 0
drwxr-xr-x@ 2 root wheel 68 Jan 21 2009 .
drwxr-xr-x@ 32 root wheel 1088 Jun 1 2008 ..
---------------------------------------
Grüße
Götz
--
http://www.knubbelmac.de/
Thomas Kaiser
> Failsafe Vorgehensweise:
>
> 1) OS installieren. (beim User Anlegen darauf achten, dass dieser
> genau so heist wie der erste User beim originalen System)
> 2) Patches (bis mind. auf den Stand des Backups) einspielen
> 3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
> saubere Treiber die sich nicht in /System einnisten sind kein Problem)
> 4) TM Restore machen.
Wie konkret? Also "Booten von Installations-Medium" und dann im Menü
"System von Datensicherung wiederherstellen"? Oder aus dem laufenden neu
installierten System heraus das "Time Machine"-Icon klicksen und sich
dann ordnerweise durchwuseln?
> 5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
> halten) nachinstallieren.
> 6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
> sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
>
> Danach sollte selbst ein von obskuren Anwendungen sprotzendes System
> wieder so laufen wie vorher.
Wenn ich nach der Anleitung vorgehen würde, müsste ich für ein auf diese
Weise propagiertes Desaster Recovery wohl 2-3 Manntage einplanen und
hätte danach garantiert nicht das System am Start, das ich vorher hatte.
> Ansonsten: Finger weg von all zu unsauberen Apps/Hacks die das System
> manipulieren, denn natuerlich steoert sich das mit einem
> Systemkonformen Backupkonzept.
Aha. Naja, mein Verständnis von Desaster Recovery scheint Deinem
ziemlich zu widersprechen :-)
Gruss,
Thomas
Dr Eberhard W Lisse
On 2010-04-02 23:43 , Klaus Behrends wrote:
[...]
>
> Was für eine blöde Diskussion.
[...]
mfg, el
Mike Nolte
> Auf MOSX Server 10.5.8 sichert TimeMachine jedenfalls /var/spool nicht.
> Und das ist ziemlich schade, denn da sind blöderweise die
> Mail-Postfächer drin:
Aber das betrifft doch nur den Betrieb des Mail-Servers und nicht die
Benutzerdaten eines einzelnen Benutzers, oder?
Gibt es eine Möglichkeit gefahrlos /var/spool aus der Liste der
ungesicherten Verzeichnisse zu entfernen? Bei Tante Gugl war ich
diesbezüglich leider erfolglos.
Mit besten Grüßen,
Mike Nolte
--
E-Mail an news...@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anführungszeichen lautet.
<mailto:news...@mikenolte.de?subject=Usenetartikel>
Thomas Kaiser
> Goetz Hoffart <use...@hoffart.de> wrote:
>
>> Auf MOSX Server 10.5.8 sichert TimeMachine jedenfalls /var/spool
>> nicht. Und das ist ziemlich schade, denn da sind blöderweise die
>> Mail-Postfächer drin:
>
> Aber das betrifft doch nur den Betrieb des Mail-Servers
LOL, "nur"?! Als ob das nicht schon schlimm genug wäre. Postfix wird
jedenfalls unter 10.5 nach einem Time Machine Restore gar nicht erst
starten, weil /var/spool/postfix fehlt (der Inhalt des Verzeichnisses
wäre ja wurscht -- aber wenn es gar nicht existiert, dann weigert sich
postfix zu starten)
> und nicht die Benutzerdaten eines einzelnen Benutzers, oder?
Nein, nicht eines einzelnen Benutzers sondern *aller Benutzer*. Liegt
alles unterhalb /var/spool/imap. Und nichts davon ist im Backup.
> Gibt es eine Möglichkeit gefahrlos /var/spool aus der Liste der
> ungesicherten Verzeichnisse zu entfernen?
Mei, ich hab doch erklärt, in welchen Property Lists was gespeichert
ist. Da mußt Du also was ändern. Und Apple erwartet nicht, daß da ein
User Änderungen vornimmt. Insofern kann das mit jedem Software Update,
das Du in Zukunft einspielst, wieder egalisiert werden.
D.h. Du müsstest bei Änderungen an sowohl StdExclusions.plist als auch
der globalen com.apple.TimeMachine.plist anschließend peinlich darauf
achten, daß die Änderungen auch immer präsent sind. Sobald Apple die
defaults restauriert, war's das wieder mit den Mails der User. Gesichert
werden die dann erstmal nicht mehr.
Gruss,
Thomas
Goetz Hoffart
> Aber das betrifft doch nur den Betrieb des Mail-Servers und nicht die
> Benutzerdaten eines einzelnen Benutzers, oder?
Bei dem Kunden, von dem ich zitierte, _sind_ die Maildaten die
Benutzerdaten :-) Die Dateiablage findet nicht in Homes statt, dafür
gibt's Gruppen-Freigaben.
Kurz: Da liegen wirklich Mails drin. Nur im "Backup" nicht ... (und drum
lasse ich launchd ein Skriptchen antreten, das die Dinger als Diskimage
nächtlich zusammenpackt).
Volker Birk
[TimeMachine]
>> Aber das betrifft doch nur den Betrieb des Mail-Servers
> LOL, "nur"?! Als ob das nicht schon schlimm genug wäre. Postfix wird
> jedenfalls unter 10.5 nach einem Time Machine Restore gar nicht erst
> starten, weil /var/spool/postfix fehlt (der Inhalt des Verzeichnisses
> wäre ja wurscht -- aber wenn es gar nicht existiert, dann weigert sich
> postfix zu starten)
Ich benutze TimeMachine zum Sichern von iMac & MacBook. Dort hat es mir
schon gute Dienste geleistet, insbesondere, wenn ich Daten aus meinem
FileVault-geschützten Home wieder haben wollte (Sparse-Bundle mounten,
rauskopieren, fertig).
Ich würde nicht auf die Idee kommen, damit meinen Server zu sichern. Ich
kann mir nicht vorstellen, dass man beim Sichern eines Servers nicht
auch eine passende Backup-Strategie zu wählen hat, die sich aus einem
Recovery-Plan ergibt. Jenen testet man ausserdem vorab.
Bei einer Servermaschine will man ja seltenst ein identisches System
wieder haben (ausser man hat die komplette Hardware identisch nochmals
auf Lager, solche Fälle gibt's auch). Man will eine entsprechende
Maschine ASAP wieder oben haben, die Recovery-Time kurz.
Was Du aber beschrieben hast, ist, dass man TimeMachine durchaus auch
mit entsprechenden Config-Files der eigenen Anforderung anpassen kann.
Meine Frage an Dich:
Warum jammerst Du dann hier rum, statt das Ding entweder so anzupassen,
wie Du es brauchst, oder was anderes zu nehmen?
Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!
Volker Birk
> Kurz: Da liegen wirklich Mails drin. Nur im "Backup" nicht ... (und drum
> lasse ich launchd ein Skriptchen antreten, das die Dinger als Diskimage
> nächtlich zusammenpackt).
Was passiert denn, wenn Du TimeMachine entsprechend konfiguierst? Thomas
hatte hier ja die entsprechenden Config-Files aufgezeigt, vermutlich
sind die auch dokumentiert?
Goetz Hoffart
> Ich würde nicht auf die Idee kommen, damit meinen Server zu sichern. Ich
> kann mir nicht vorstellen, dass man beim Sichern eines Servers nicht
> auch eine passende Backup-Strategie zu wählen hat, die sich aus einem
> Recovery-Plan ergibt. Jenen testet man ausserdem vorab.
Das ist alles richtig. Trotzdem sollte Time Machine auf einem MOSXS
nicht _wirklich_ relevantes einfach auslassen. Das ist einfach ein
Fehler.
> Bei einer Servermaschine will man ja seltenst ein identisches System
> wieder haben (ausser man hat die komplette Hardware identisch nochmals
> auf Lager, solche Fälle gibt's auch).
Bitte? Natürlich will ich ein identisches System wiederhaben. Das schöne
an Mac OS X Server ist ja, dass man es auf beinahe beliebiger Hardware
wieder booten kann. Ich habe ein System schon 1:1 von einem XServe
Dual-Dual-Core auf einen aktuellen Mac mini umgezogen und das läuft bis
heute prima. Umgekehrt genauso: MOSXS von einem Mini auf einen XServe
umgezogen: Lüftererkennung, Hardwareerkennung, alles da.
> Man will eine entsprechende schine ASAP wieder oben haben, die
> Recovery-Time kurz.
Jo.
Goetz Hoffart
> Was passiert denn, wenn Du TimeMachine entsprechend konfiguierst?
Ich hab grad keinen »Spiel«-Server zur Hand.
Ben Gurion
> D.h. Du müsstest bei Änderungen an sowohl StdExclusions.plist als auch
> der globalen com.apple.TimeMachine.plist anschließend peinlich darauf
> achten, daß die Änderungen auch immer präsent sind. Sobald Apple die
> defaults restauriert, war's das wieder mit den Mails der User. Gesichert
Wie wärs mit nem kleinen (login?) script, welches die "persönlichen"
defaults wiederherstellt? Evtl. gleich mit nem Pashua GUI.. ;->
--
ben
Thomas Kaiser
> Klaus Behrends <bk.be...@t-online.de> wrote:
>
>> Ich habe mehrfach aus einem TM-Backup ein komplettes Restore auf eine
>> externe Festplatte vorgenommen, indem ich von der MacOS-X-DVD
>> gestartet und als Zielmedium eine externe Festplatte angegeben habe.
>
> Das war meine Kernfrage, und so habe ich Deine erste Antwort auch
> verstanden.
So hätte ich das "Ja" in
"Ja. Mehrfach ausprobiert, statt Klon per Superduper!"
auch interpretiert, wenn danach nicht noch das (ver)wirre(nde) "statt
Klon per Superduper!" gekommen wäre. Zum einen macht "SuperDuper!"
ausschließlich Klone. Zum anderen ist es völlig egal, ob Klaus vorher
mit SuperDuper! die Zielfestplatte befummelt hat oder mit irgendwas
anderem, denn:
> Es wird ja hoffentlich wohl so sein, dass vor dem definitven Begin des
> Überschreibens eine Rückversicherung kommt ("wird gelöscht, wollen Sie
> wirklich" oder irgend etwas in der Art).
Genau das erfolgt natürlich. Eine fette Warnmeldung, daß das Volume, auf
das man ein Komplettrestore bügeln will, vorher gelöscht wird. Insofern
völlig irrelevant, was vorher drauf war, es wird überschrieben. Der
Punkt "System von Backup wiederherstellen" auf den OS X Installations-
medien eignet sich halt leider _nicht_ dazu, einen Restore _über_ einen
Klon zu sichern. Nach dem Restore wird meist weniger auf der Platte sein
als vor dem Restore (bedingt durch das unvollständige Vollbackup, das TM
durchführt)
>> Basta.
Ich rätsel ja, wie der Satz gelautet hätte, wenn das Restore-Ziel ein
Volume gewesen wäre, auf dem vorher mit iPhoto Urlaubsfotos gelandet
wären...
"Ja. Mehrfach ausprobiert, statt Urlaubsfotos per iPhoto"
Naja, egal...
Gruss,
Thomas
Mike Nolte
> >> Auf MOSX Server 10.5.8 sichert TimeMachine jedenfalls /var/spool
> >> nicht. Und das ist ziemlich schade, denn da sind blöderweise die
> >> Mail-Postfächer drin:
> >
> > Aber das betrifft doch nur den Betrieb des Mail-Servers
>
> LOL, "nur"?!
Ja, genau. "Nur" (sic!). Quantitativ, Kurzform für "keinen anderen". Was
du da hineininterpretieren möchtest ist deine Sache und mir egal. Ich
wollte nur wissen, ob mich das jucken muss. Muss es nicht. Ich kenne
keinen Mac OS X Server, der als Mail-Server arbeitet. Damit ist die
Frage für mich hinreichend erledigt.
Vielen Dank.
Klaus Behrends
> Peter Brunner schrieb am 03.04.2010 in
> <news:1jgd76r.11qjrll5sasqiN%bitsh...@gmx.ch>
> > Klaus Behrends <bk.be...@t-online.de> wrote:
> >
> >> Ich habe mehrfach aus einem TM-Backup ein komplettes Restore auf eine
> >> externe Festplatte vorgenommen, indem ich von der MacOS-X-DVD
> >> gestartet und als Zielmedium eine externe Festplatte angegeben habe.
> >
> > Das war meine Kernfrage, und so habe ich Deine erste Antwort auch
> > verstanden.
>
> So hätte ich das "Ja" in
>
> "Ja. Mehrfach ausprobiert, statt Klon per Superduper!"
>
> auch interpretiert, wenn danach nicht noch das (ver)wirre(nde) "statt
> Klon per Superduper!" gekommen wäre.
Ich gebe ja zu, Thomas, daß der Zusatz <statt Klon per Supersuper!>
ziemlich überflüssig war. Aber so verwirrend und aprilscherzig wie Du
ihn hier apostrophiert hast, war er nun auch wieder nicht.
> Zum einen macht "SuperDuper!" ausschließlich Klone.
War immer klar.
> Zum anderen ist es völlig egal, ob Klaus vorher
> mit SuperDuper! die Zielfestplatte befummelt hat oder mit irgendwas
> anderem,
War auch immer klar.
Allerdings war ich bis dato der Meinung, durch ein komplettes Restore
per TM auf eine externe Festplatte - wenigstens im Prinzip - genau so
einen Klon zu erstellen wie mit Superduper!
Das muß ich mir aufgrund Deiner Angaben in diesem thread offenbar
abschminken.
Insbesondere frage ich mich jetzt, was es heißt, wenn Du schreibst:
< ...Anregung, zusätzlich zu einem überaus sinnvollen
Nutzdaten-Backup (via TimeMachine) ab und zu einen Komplett-Klon des
Systems anzufertigen. So ein Klon, auf den man im Bedarfsfall das
aktuellste Komplett-Restore via TimeMachine klatscht, erscheint mir zur
Zeit als die beste Variante des "Desaster Recovery">
Wie funktioniert denn so ein "Draufklatschen"? Ein Komplett-Restore
löscht doch wohl den Klon...
Grüße Klaus
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de>:
>>
>> Ich hab ja früher auch das Hohelied von TimeMachine gesungen (und
>> finde den grundsätzlichen Ansatz und die idiotensichere Umsetzung
>> weiterhin genial). Aber ein riesiges Problem sind IMO die Exclusions,
>> also was alles eben nicht ins Backup wandert, gerade wenn man einen
>> kompletten Restore vorhat, denn wo kein komplettes Backup, da kein
>> kompletter Restore möglich. :-(
>
> Man benoetigt halt immer die Originalinstallationsmedien von
> Software. ABer da ist es halt auch gegeben, dass die Neuinstallation
> der Software gefolgt vom Ruecksichern der Einstellungen vom Backup
> idR. mindestens genauso schnell gehen wie das Ruecksichern eines
> Vollbackups.
Glaub ich so nicht. Wobei ich mich hier auf _Komplett-Restore_ beziehe,
d.h. von Installationsmedium booten, unter "Dienstprogramme" den Punkt
"System aus Backup wiederherstellen" auswählen, passendes Backup (bzw.
"Snapshot") auswählen, Komplett-Restore starten lassen. Das würde in der
Appleschen TM-Implementierung perfekt funktionieren, wenn denn das
vorher erstellte Backup hinreichend vollständig _wäre_, was es aber
nicht ist, wenn man nicht an paar Schrauben dreht (und sich permanent
vergewissert, daß diese Schrauben auch immer noch so angezogen sind, wie
man selbst will)
Wer in dem Fall vorher das System neu installiert, hat was Wesentliches
übersehen: Beim Einspielen des Restores wird das Zielvolume eh komplett
gelöscht, also wozu dort vorher was zeitaufwändig installieren?
> Ich kenne es eigentlich nur so, dass man aus Effizienzgruenden keine
> unnoetigen (weil eh auf Datentraegern vorhandenen) Dateien sichert.
>
> Von daher passt TM pefekt zu meiner Arbeitsweise bei Backups: Die
> Orginalmedien im Schrank auf Datentraegern die lange halten, ggf. mit
> Backups auf Datentraegerkopien, und auf dem Backup nur die Dateien,
> die nicht auf den Originalmedien zu finden sind bzw. veraenderlich
> sind.
Tolle Sache in der Theorie. Praktisch sieht's so aus, daß ein Mac dessen
Platte mit sagen wir mal 200 GByte belegt ist, in x Stunden komplett
gesichert ist und ein Komplett-Restore des Ganzen in ca. x * 1,2 Stunden
wieder eingespielt ist. Bei 200 GByte entfallen auf "das System"
vielleicht 10, 15, evtl. sogar 20 Gbyte. Die nicht mitzusichern und zu
-restoren, bringt also die sagenhafte Einsparung von x * 0,1 Std.,
welche durch manuelles Herumgekaspere für Neuinstallation des Systems,
Installation von Programmen, etc. in der Größenordnung x * 5 wieder
aufgefangen werden.
Zumal die Idee, "das System" nicht mitzusichern, da redundant auf
Installations-DVD vorhanden, ja theoretisch nett ist, praktisch aber
undurchführbar, wenn die Installationsmedien auf dem Stand von 10.5.0
sind, das gesicherte System aber auf bspw. 10.5.7 war.
Wenn ich mir Deine in <news:23634.20491...@news.jors.net>
aufgeführte Vorgehensweise durchlese, verstehe ich nicht, was der
Vorteil des Ganzen sein soll?
1) OS installieren. (beim User Anlegen darauf achten, dass dieser
genau so heist wie der erste User beim originalen System)
2) Patches (bis mind. auf den Stand des Backups) einspielen
3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
saubere Treiber die sich nicht in /System einnisten sind kein Problem)
4) TM Restore machen.
5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
halten) nachinstallieren.
6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
Ein "Komplett-Restore" ist in einem Bruchteil der Zeit eingespielt (TM
sichert ja nicht auf DAT oder sowas sondern Festplatten). Und wenn man
einen Komplett-Restore macht (und vorher dafür sorgt, daß das Backup
ausreichend umfänglich angelegt wird) in Schritt 4, dann sind die Punkte
1) - 3) eh nur verschwendet, weil der Restore das Volume vorher löschen
wird.
Wenn man Time Machine im Einzeldateien-Restore-Modus betreibt (also
System booten, TM-Platte anhängen, auf Time Machine Icon klicksen und
die Sachen auswählen, die man zurückholen möchte), dann mag das klappen,
wenn man nichts vergißt bei der Auswahl der rückzusichernden Dateien.
Nur abermals: Wozu der Aufwand, wenn TM auch einen Komplett-Restore
kennt (und der ja auch prima funktioniert -- das Problem ist ja, daß im
Backup paar Kleinigkeiten fehlen)
Und das ganze Prozedere bzgl. "evtl. fehlende Anwendungen (die sich
nicht an Apple's Konzepte halten) nachinstallieren" und "alle
haesslichen Hacks und unsauberen Toolz nachinstallieren, die sich auch
nicht an Apple's Vorgaben fuer Anwendungen halten"... wozu der Aufwand
(der sich bei einem einigermaßen umfänglichen System schon mal paar
Stunden bis Tage ziehen kann)
Im "Desaster Recovery"-Fall will ich doch eigentlich
a) so schnell wie möglich wieder ein produktives System am Start haben
b) mich nicht mit irgendwelchen Details wie partiellem Neuaufbau meiner
Arbeitsumgebung beschäftigen.
Zumal b) dann auch noch mit so unnötigem Gezeter einhergeht wie
Seriennummern und Installations-Medien suchen, sich erinnern, was man
überhaupt für Softwares hier und da brauchte, etc. etc. -- das kriegt
man doch in genau dem Fall eh nicht mehr auf die Reihe.
Ich hab hier versucht, für die letzte Asien-Reise, mein kleines
Hackintosh-NetBook von der Software her auf einen "ausreichenden" Stand
zu heben (auf externer 2,5er USB-HD), damit ich dort problemlos werkeln
kann aber nicht das MacBook Pro mitschleppen muß. Vor der Abfahrt
wirklich stolz gewesen, daß ich das alles so umfänglich und in so kurzer
Zeit (sporadisch über 2-3 Tage hinweg) hinbekommen habe. Dann vor Ort
festgestellt, was ich alles vergessen hatte (nur Kleinigkeiten, die aber
in Summe die Produktivität in den Keller schraubte).
Genau so stelle ich mir den manuellen "dies&das nach Restore fixen"-
Ansatz vor. Und frag mich parallel, wozu man sich diesen Aufwand machen
wollte?
>> Und es fehlt einfach viel zu viel in einem TimeMachine-Backup als das
>> man einfach so ein Komplett-Restore einspielen könnte und anschließend
>> so weiterarbeiten könnte, als ob nichts gewesen wäre.
>>
>> Konkret: Was wird nicht gesichert:
>>
>> * Alles, was Apple via StdExclusions.plist ausschließt, unter anderem
>> alle Logs (sehr "schlau", wenn man nach Einspielen des Restores gucken
>> will, warum das System, das man restaurieren musste, vorher in
>> Schieflage geriet), Teile des Unix-Unterbaus, bspw. Ordner, die
>
> Hmm, Logfiles von einem Backup halte ich fuer unspannend. Dort steht
> bestimmt nicht, warum das Restore noetig war, denn zum Zeitpunkt des
> Backups war ja noch alles in Ordnung.
Ich schrieb von Logfiles _im_ Backup. Und mich wundert Deine Meinung
wirklich sehr, daß da nix Spannendes drinstehen könnte, grad weil Du
professioneller ITler bist. Also ich habe da schon zuhauf wertvolle
Informationen gefunden (bspw. Einbruchsversuche, bspw. Statusmeldungen
vom smartmond, etc.)
>> Postfix oder Apache2 brauchen, um überhaupt zu starten, unter MacOS X
>
> Welche waeren das?
/var/spool/postfix und /var/log/apache2.
> In meiner StdExclusions.plist kann ich kein Verzeichnis erkennen, dass
> Postfix oder Apache zum Arbeiten benoetigen.
Ist in 10.6 gefixt worden. Es gibt ab 10.6 auch eine neue Kategorie an
Ausschlüssen (neben ContentsExcluded, PathsExcluded, UserPathsExcluded
in 10.5): FileContentsExcluded. Verzeichnisse, die hier gelistet werden,
wandern als leere Ordnerhierarchie uns Backup (d.h. die Struktur bleibt
erhalten, nur die Dateien werden aus dem Backup ausgeschlossen)
>> Server "praktischerweise" auch gleich noch *ALLE MAILS ALLER USER*,
>> die unterhalb /var/spool/imap/user/ liegen, da /var/spool komplett
>> ausgeschlossen ist, etc. etc.
>
> Hmm, das wuerde ich auch als Defekt bzw. Mangel bezeichnen und Apple
> zur Abstellung auffordern.
Haben sie -- allerdings erst mit 10.6 und nicht schnellstmöglich mit
einem 10.5.x-Update. Und auf dem Weg haben ein paar der typisch
blauäugigen "echten Mac-Admins" ziemlich viel Daten verloren.
>> Außerdem sämtliche Cache-Folder, in denen viele Programme Proxy-
>> Dateien für Spotlight unterbringen. Was hier fehlt, nach dem kann
>> nach
>
> Programme, die notwendige persistente Dateien in Cache-Verzeichnissen
> unterbringen sind DEFEKT.
Jaja, blabla. Das ganze ist eine Design-Vorgabe von Apple bzw.
Spotlight-API:
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/SpotlightCoreData/Articles/recordLevel.html>
In this approach, Core Data manages a directory in the
Library/Caches/Metadata/Core Data/ in a user’s home directory (the
structure of this directory is private—don't depend on it). For each
separate program, Core Data creates a subdirectory; within each
subdirectory Core Data creates a further subdirectory for each
persistent store used by the program. Within the directory for a
given store, for each instance of each entity that you choose to
index, Core Data creates a new external record file. The external
record files are used by Spotlight to index the persistent store.
Alles klar? Die Daten haben da zu liegen, damit Spotlight sie indizieren
kann.
> Da hat Timemachine nichts weiter mit zu tun. Beschwer dich bei den
> Idioten, die diese Programme verbrochen haben oder verwende
> Alternativen die nicht derart kaputt sind.
*gähn* Jaja, mach' ich...
>> dem Restore auch nicht gesucht werden. D.h. neben einer allgemeinen
>
> Also wirklich, nach dinem Restore kannst auch du es ertragen, einmal
> neu Indizieren zu lassen.
Hast Du's wenigstens einmal gemacht? Offensichtlich nicht.
>> Reindizierungs-Orgie, die Spotlight auf einem frisch aus TM-Backup
>> restaurierten System anstößt, ist es nötig *jedes* einzelne
>> Programm, das sich diesen Spotlight-Indizierungs-Mechanismen
>> bedient, einmal mindestens wieder zu starten, damit das
>> Neuerstellungs-Gerödel für
>
> Das ist fuer diesen einen speziellen Anwendungsfall IMO ertragbar.
Das kann nur wer sagen, der das noch nicht hinter sich gebracht hat,
denn bei meinen bisherigen Restores hat dieses Gezeter immer locker das
dreifache der Zeit für den eigentlichen Restore verbraten. Zumal es
*völlig unsinnig* ist, wenn man einen Komplett-Restore durchführt.
> Schlimmer waere es, wenn fuer alle anderen Anwendungsfaelle von TM
> (partielle Restores) inkonsistente Spotlight-Indizes dich bei der
> Suche in die Irre fuehren wuerden.
Ach je, jetzt schmeißt Du die beiden Restore-Varianten von Time Machine
auch noch durcheinander.
Es gibt:
- Komplett-Restore: Ein rudimentäres System ist gebootet, TM bietet an,
ein beliebiges Volume mit einer *kompletten Sicherung* zu
*überschreiben*. Wie sollten hierbei bitte sehr inkonsistente
Spotlight-Indizes auftreten? Es geht darum, das komplette System, wie
es zu einem Zeitpunkt X am Laufen war, 1:1 wiederherzustellen. Warum
sollte sowas nicht inkl. Spotlight-Indizes funktionieren?
Der Witz ist ja: Ich beschwer mich ja gar nicht darüber (also nicht
gesicherte Spotlight-Indexe, die bekanntlich in "/.Spotlight-V100"
liegen), sondern über das Auslassen von ~/Library/Caches/(Metadata).
Spotlight erstellt aus den Daten hier ja erst seinen Volltext-Index.
Aber bevor es das kann, muß jedes dämliche Programm, das dieses
Spotlight-API nutzt, nach dem Restore wenigstens einmal gestartet
werden, damit erstmal die Dateien unterhalb ~/Library/Caches/MetaData
erzeugt werden, damit dann in Folge erst der mds das eigentliche
Indizieren beginnen kann. Wohlgemerkt in der Betriebsart "Komplett-
Restore", wo das alles nicht nötig wäre.
Die andere Variante, also "Einzeldateien-/-ordner-Restore" ist doch was
völlig anderes:
- das System ist gebootet, man wählt den Ordner, in dem was fehlt oder
die Datei, auf dessen ältere Fassungen man zugreifen will, auf,
startet das Time Machine GUI und Time Machine bietet einem via
Zeitleiste alte Fassungen der Datei an. Wenn man nun eine Datei aus
dem Backup holt, wird automatisch ein File Event generiert und via
fseventsd und Spotlight leicht zeitverzögert die Neuindizierung der
zurückgeholten Daten angestossen.
Auch hier weit und breit keine inkonsistenten Indexe. Das Time Machine
GUI ist selbstredend auch so "schlau" und läßt gar kein Auswählen von
Elementen zu, die per StdExclusions.plist ausgeschlossen sind. D.h. Du
kannst bspw. gar nicht aus dem Backup einen veralteten und damit ggf.
inkonsistenten Ordner unterhalb ~/Library/Caches ins aktuelle System
ziehen. Wäre ja auch doof...
> Nein, diesen Kritikpunkt akzeptiere ich so nicht. ICh bin vielmehr der
> Meinung, dass das ein wohldefiniertes Verhalten von TM ist, und kein
> Fehler.
Eh klar...
>> diese Cache-Dateien beginnt und sich anschl. dann Spotlight erst drauf
>> stürzen kann (bei meinem kleinen NetBook dauerte das Reindizieren des
>> ganzen Schrotts ca. die dreifache Zeit, die der Restore an sich
>> brauchte -- und das NetBook hat nur eine 16 Gbyte SSD + 16 GByte
>> SD-Card)
>>
>> * Dann gibt es noch eine globale Preference abseits StdExclusions.plist,
>> die ebenfalls Ausschlüsse definiert, an die man so per GUI erstmal
>> nicht drankommt. Abermals: Einfach nachschauen:
>>
>> defaults read /Library/Preferences/com.apple.TimeMachine ExcludeByPath
>
> Und, wieder ausschliesslich Caches mit transienten Dateien bei denen
> Backup und vorallem ein Restore keinerlei Sinn machen, weil sie nur
> den aktuellen Anwendungsstatus reflektieren (z.B. Safari
> Webicons-Cache, Calendar Cache etc.)
Wenn man alles immer nur theoretisch von der Warte der großen IT aus
betrachtet, dann sind das tolle Entscheidungen, die das TM-Team da
getroffen hat. In der Praxis sieht's halt abermals anders aus:
macbookpro-tk:~ tk$ du -sh ~/Library/Caches/
5,5G /Users/tk/Library/Caches/
5,5 Gbyte an Caches. Die liegen da vermutlich nicht ohne Grund, sondern
die haben diverse Programme mühevoll angelegt. Mag sein, daß da Kram
dabei ist, den ich nie wieder brauchen werde (weil von uralten
Programmversionen). Aber: 5,5 GByte an Caches neu generieren zu lassen,
dauert ungefähr tausendmal so lange als das bisserl Daten einfach
mitzusichern und beim Komplett-Restore wieder auf Platte zu klatschen.
Und ja, ich hab's ausprobiert. Und es ist die eine Sache, nach einem
Restore, der 3 Std. dauert, weiterarbeiten zu können (PresStore) oder in
Folge nochmal ca. 1,5 Tage vor einem Rechner zu hocken, bei dem
Spotlight nicht funktioniert, weil die Kiste noch mit sich selbst
beschäftigt ist (das wäre die TM-Variante bei mir, bis all der Schrott
auf dem MBP wieder indiziert ist und _vorher_ mein Mailprogramm seine
Proxy-Dateien für Spotlight wieder erzeugt hat)
Das mag Leute, die kaum Spotlight nutzen, nicht treffen -- bei mir
schlägt sowas voll ein...
>> * Dann noch alles, was passende EAs drankleben hat (also unter anderem
>> Covers von iTunes). Wiederum einfach nachgucken:
>>
>> mdfind com_apple_backup_excludeItem = "com.apple.backupd"
>
> Hmm, einzig "Music/iTunes/iTunes Music Library.xml" faellt auf.
> Das sollte man doch explizit sichern.
Tja daneben, genau das ist eine sinnvolle Ausgrenzung, da redundant:
<http://support.apple.com/kb/HT1660?viewlocale=de_DE>
Die XML-Datei wird automatisch erzeugt, falls fehlend bzw. inkonsistent.
> Der Rest sind wieder nur Caches die keinerlei Datenverlust beinhalten.
Wie kommst Du auf das schmale Brett? Bzw. wie kannst Du von Deiner
Installation auf andere schließen? Bei Dir mag die Suche nach diesem
"Bitte nicht per TM sichern"-Attribut nur derlei Zeugs enthalten. Auf
anderen Systemen sieht's anders aus, bspw. setzt VMWare Fusion diese EA
(sinnvollerweise -- nebenbei bemerkt) für VMWare-Diskimages, die sich
mit Fusion eh nicht sinnig im laufenden Betrieb sichern lassen sondern
nur in Gänze und bei heruntergefahrenem/angehaltenem Gast-System.
Als ich das mal in ner Mac-Entwicklerklitsche durchsickern habe lassen,
gab's lange Gesichter, weil die dort ihre ganzen virtuellen Testsysteme
konsequent eben *nicht* gesichert hatten. Eben aufgrund dieses EA. Ist
natürlich eigene Schuld, so schludrig mit dem Backup von Testumgebungen
umzugehen (weil das Wiederaufsetzen viel Zeit und damit dito viel Geld
verbraten würde). Aber sehr, sehr verbreitet.
Und niemand ist sich dessen überhaupt bewußt...
>> rödelt in Extremfällen schon mal einen halben bis ganzen Tag vor
>> sich
>
> Spotlight roedelt *immer*. Das allerdings nur im Hintergrund und mit
> niedrigster Prioritaet und nur dann wenn sonst nix anderes Ressourcen
> belegt.
Mit anderen Worten: Du theoretisierst schon wieder. Nimm ein System
*ohne* ".Spotlight-V100"-Ordner, starte ein Programm, das massig
Spotlight-Proxy-Dateien generiert und versuch damit, irgendwie normal zu
arbeiten. Dann stellst Du wahrscheinlich recht schnell fest, daß ein
mds-Prozeß mit > 90% CPU und diverse mdworker-Prozesse das nicht
wirklich erlauben werden.
> Works as Designed.
Genau, einfach besch***en.
> Und selbst du willst nach einem partieillen Restore keine Spotlight
> Indizes haben, die deinen Anwendern irgendwelche nicht laenger (oder
> nicht restaurierte) Dateien enthalten...
O mei, siehe oben. Komplett-Restore: Keine Chance für inkonsistente
Indexe. Partieller Restore (AKA *völlig andere Betriebsart* aus
laufendem System heraus): Keine Chance für inkonsistente Indexe.
>> hin, es fehlen Nutzerdaten von denen iTunes-Cover noch die
>> harmlosesten sind -- wie schon geschrieben: Wer unter MacOS X
>> Server auf die integrierten Mailservices setzt und auf TM vertraut,
>> der sichert seinen Maildatenbestand *nicht*
>
> Mangels OSX server kann ich das nicht nachvollziehen. Beim Client wird
> /private/var/spool/mail durchaus mitgesichert.
Nein, ab 10.6 werden ein paar Ordner (bspw. /var/spool/mail, das nichts
mit den Maildaten der User sondern nur mit der Lauffähigkeit von postfix
zu tun hat) und ein paar Dateien (bspw. /var/spool/imap, das wäre jetzt
mal der Mailbestand) mehr gesichert. Aber diese eklatante Schwäche wurde
nicht direkt nach Auftreten mit 10.5.1 behoben sondern ausgesessen bis
10.6.0.
>> Es ist eher die Anregung, zusätzlich zu einem überaus sinnvollen
>> Nutzdaten-Backup (via TimeMachine) ab und zu einen Komplett-Klon des
>> Systems anzufertigen. So ein Klon, auf den man im Bedarfsfall das
>> aktuellste Komplett-Restore via TimeMachine klatscht, erscheint mir
>> zur Zeit als die beste Variante des "Desaster Recovery" -- MacOS X
>> 10.5/10.6 vorausgesetzt natürlich.
>
> Natuerlich. Ein Klon ist fuer DR die einfachste, effizienteste,
> schnellste und bequemste Variante. Zudem ist das mit Bordmitteln
> anlegbar.
Ein TM-Komplettrestore gelingt auch mit Bordmitteln und hat mit einem
Klon gemein, daß Datentransfers zwischen schnellen Harddisks
stattfinden. Wäre der Komplettrestore vollständig (was er nur sein kann,
wenn das Backup auch vollständig ist), dann braucht's auch keinen Klon
parallel.
Ein Klon parallel zu TM bringt ja auch nur was, wenn man weiß, wie man
die aktuellste TM-Sicherung mit dem Klon "mergen" kann. Bei einem
Komplett-Restore mit TM-Bordmitteln wird der Klon ja sowieso erst
gelöscht, bevor der Restore erfolgt.
> Fuer den Anwender (fuer den ist TM konzpiert) ist TM hingegen eine
> brauchbares Backupsystem. Bei einem Server benoetigt man sowieso ein
> angepasstes Backupsystem, dass dem Backupkonzept entspricht.
Sag sowas mal lieber typischen Mac-Admins, an die hier ein paar der
Hinweise gerichtet waren...
> Hierfuer kann TM geeignet sein, aber eher nicht in der
> Defaultkonfiguration (die Voreinstellungen und Excludes kann man ja
> modifizieren).
Es reicht halt nur nicht, die einmal zu modifizieren, denn gemäß
Murphy's Law wird einem zuerst ein Security Update die
/System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist
auf einen unliebsamen Stand bringen, dann die Katastrophe eintreten und
man anschl. feststellen, daß genau die letzte Version, die man bräuchte,
eben nicht im Backup vorhanden ist... Oder so irgendwie ;-)
Im Ernst: Diese Property List liegt ja nicht ohne Grund unterhalb
/System -- da muß man fast damit rechnen, daß Apple an der ungefragt
Änderungen vornimmt. Wenn man an den TM-Exclusions herumschnibbeln
wollte, müsste man schon einen nicht zu unterschätzenden Aufwand
treiben, sicherzustellen, daß diese Änderungen auch stets persistent
bleiben.
Gruss,
Thomas, das EOT-Fähnchen schwenkend, da keinerlei neue Erkenntnisse zu
erwarten sind...
Thomas Kaiser
> Allerdings war ich bis dato der Meinung, durch ein komplettes Restore
> per TM auf eine externe Festplatte - wenigstens im Prinzip - genau so
> einen Klon zu erstellen wie mit Superduper!
>
> Das muß ich mir aufgrund Deiner Angaben in diesem thread offenbar
> abschminken.
Mei, es gibt Berichte von Leuten, die behaupten, sie hätten ihre
StdExclusions.plist gelöscht und anschl. das Äquivalent zu einem Klon
erhalten. Wenn man noch über EAs wie com_apple_backup_excludeItem und
die Existenz der com.apple.TimeMachine.plist weiß, muß man das per se
bezweifeln. Zumal auch noch die Frage ist, ob die TM-Komplett-Restore-
Funktion nicht selbst auch noch irgendein Regelwerk kennt, um dies&das
zu machen (auslassen, erzeugen, triggern, was-weiß-ich)
> Insbesondere frage ich mich jetzt, was es heißt, wenn Du schreibst:
>
> < ...Anregung, zusätzlich zu einem überaus sinnvollen Nutzdaten-Backup
> (via TimeMachine) ab und zu einen Komplett-Klon des Systems
> anzufertigen. So ein Klon, auf den man im Bedarfsfall das aktuellste
> Komplett-Restore via TimeMachine klatscht, erscheint mir zur Zeit als
> die beste Variante des "Desaster Recovery">
>
> Wie funktioniert denn so ein "Draufklatschen"? Ein Komplett-Restore
> löscht doch wohl den Klon...
Ja, das weiß ich _inzwischen_ auch (hatte davor im Gedächtnis, daß mir
bei meinen diesbzgl. Tests immer noch die Variante "drübersichern"
anstatt "ersetzen" angeboten worden wäre).
Meine Motivation, im Usenet bisserl ausführlicher zu werden, war bisher
eigentlich die, bisserl eigene Erkenntnisse einzuwerfen, und dafür von
anderen deren Erkenntnisse zurückzubekommen (bspw. weil die Zeitaufwand
auf sich nehmen und irgendwas austesten, etc.)
Klappt irgendwie alles nicht mehr -- zumindest in dcsm.misc.
Gruss,
Thomas
Juergen P. Meier
> Juergen P. Meier schrieb in <news:23634.20491...@news.jors.net>
>> Failsafe Vorgehensweise:
>>
>> 1) OS installieren. (beim User Anlegen darauf achten, dass dieser
>> genau so heist wie der erste User beim originalen System)
>> 2) Patches (bis mind. auf den Stand des Backups) einspielen
>> 3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
>> saubere Treiber die sich nicht in /System einnisten sind kein Problem)
>> 4) TM Restore machen.
>
> Wie konkret? Also "Booten von Installations-Medium" und dann im Menü
> "System von Datensicherung wiederherstellen"? Oder aus dem laufenden neu
> installierten System heraus das "Time Machine"-Icon klicksen und sich
> dann ordnerweise durchwuseln?
Migrationsassistent -> Mittlere Option in der Auswahl von dreien.
>> 5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
>> halten) nachinstallieren.
>> 6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
>> sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
>>
>> Danach sollte selbst ein von obskuren Anwendungen sprotzendes System
>> wieder so laufen wie vorher.
>
> Wenn ich nach der Anleitung vorgehen würde, müsste ich für ein auf diese
> Weise propagiertes Desaster Recovery wohl 2-3 Manntage einplanen und
> hätte danach garantiert nicht das System am Start, das ich vorher hatte.
Nein. Das dauert bei einem 80GByte-Used-Mac kanpp 4 Stunden. Vom
Einlegen der Boot-DVD bis zum Weiterarbeiten, inkl. der ueblichen "oh,
ist ja schon fertig"-Pausen.
>> Ansonsten: Finger weg von all zu unsauberen Apps/Hacks die das System
>> manipulieren, denn natuerlich steoert sich das mit einem
>> Systemkonformen Backupkonzept.
>
> Aha. Naja, mein Verständnis von Desaster Recovery scheint Deinem
> ziemlich zu widersprechen :-)
TM ist ein hinreichendes Werkzeug fuer Restore eines Mac OS X Clients.
Fuer ein Backupkonzept eines Servers eignet es sich hingegen nicht.
Nichts davon ist besonders ueberraschend.
Marc Stibane
> Warum jammerst Du dann hier rum, statt das Ding entweder so anzupassen,
> wie Du es brauchst, oder was anderes zu nehmen?
Weil es einfach broken-by-design ist, wenn sowas wichtiges wie
User-mails nicht mitgesichert werden. Das kann man gar nicht laut genug
rausschreien, damit es m�glichst viele Leute *rechtzeitig* mitbekommen.
Selbstverst�ndlich gehe ich davon aus, dass Thomas seinen Server richtig
backuppen kann...
--
In a world without walls and fences,
who needs windows and gates?
Marc Stibane
> > Wie funktioniert denn so ein "Draufklatschen"? Ein Komplett-Restore
> > löscht doch wohl den Klon...
>
> Ja, das weiß ich _inzwischen_ auch (hatte davor im Gedächtnis, daß mir
> bei meinen diesbzgl. Tests immer noch die Variante "drübersichern"
> anstatt "ersetzen" angeboten worden wäre).
Backupplatte mounten und von gewünschtem Directory einen rsync-Lauf
starten.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de>:
>> Juergen P. Meier schrieb in <news:23634.20491...@news.jors.net>
>>> Failsafe Vorgehensweise:
>>>
>>> 1) OS installieren. (beim User Anlegen darauf achten, dass dieser
>>> genau so heist wie der erste User beim originalen System)
>>> 2) Patches (bis mind. auf den Stand des Backups) einspielen
>>> 3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
>>> saubere Treiber die sich nicht in /System einnisten sind kein Problem)
>>> 4) TM Restore machen.
>>
>> Wie konkret? Also "Booten von Installations-Medium" und dann im Menü
>> "System von Datensicherung wiederherstellen"? Oder aus dem laufenden
>> neu installierten System heraus das "Time Machine"-Icon klicksen und
>> sich dann ordnerweise durchwuseln?
>
> Migrationsassistent -> Mittlere Option in der Auswahl von dreien.
Sensationell. Die "mittlere Option" also. Um Dein Posting inhaltlich
verstehen zu können, muß ich mir jetzt 'ne dreiviertel Stunde Zeit, die
10.6-Installations-DVD und eine ausreichend große Platte nehmen, 10.6
installieren, den Migrations-Assistent aufrufen und mir anschauen, was
die "mittlere Option" nun genau macht? Sonst noch Wünsche?
>>> 5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
>>> halten) nachinstallieren.
>>> 6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
>>> sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
>>>
>>> Danach sollte selbst ein von obskuren Anwendungen sprotzendes System
>>> wieder so laufen wie vorher.
>>
>> Wenn ich nach der Anleitung vorgehen würde, müsste ich für ein auf
>> diese Weise propagiertes Desaster Recovery wohl 2-3 Manntage
>> einplanen und hätte danach garantiert nicht das System am Start, das
>> ich vorher hatte.
>
> Nein.
Alles klar. Du kennst meine Installation besser als ich selbst. Du
weißt, wo sich überall was an Daten versteckt (mein MBP ist auch
Testumgebung für dies und das), wieviel Programme ich so im Einsatz habe
[1], etc. etc.
> Das dauert bei einem 80GByte-Used-Mac kanpp 4 Stunden. Vom Einlegen
> der Boot-DVD bis zum Weiterarbeiten, inkl. der ueblichen "oh, ist ja
> schon fertig"-Pausen.
Jaja, soso...
>>> Ansonsten: Finger weg von all zu unsauberen Apps/Hacks die das
>>> System manipulieren, denn natuerlich steoert sich das mit einem
>>> Systemkonformen Backupkonzept.
>>
>> Aha. Naja, mein Verständnis von Desaster Recovery scheint Deinem
>> ziemlich zu widersprechen :-)
>
> TM ist ein hinreichendes Werkzeug fuer Restore eines Mac OS X Clients.
>
> Fuer ein Backupkonzept eines Servers eignet es sich hingegen nicht.
Wow, sensationelle Erkenntnis. Nur -- wer behauptete denn bitte sehr das
oder das Gegenteil davon, daß Du jetzt mit solchen Aussagen aufwarten
musst?
Ich weiß halt, daß es genügend planlose Mac-Admins da draußen gibt, die
genau das machen (Backup ohne Restore -- und das auch bei sog. Servern),
drum hab ich ein paar Hinweise für diese Klientel hier in die
Vorpostings eingeflochten, damit denen klar wird, daß sie von Apples
Versäumnissen bei "Time Machine, 1. Versuch" (also die 10.5-Variante)
besonders heftig getroffen werden.
Aber worum's mir eigentlich geht (Desaster Recovery mit Time Machine AKA
Komplett-Restore eines Komplett-Backups ohne lachhaften Zirkus mit
manueller Installation, manuellem Restore, manuellem "Fixen" von dies
und das im Anschluß) willst Du wohl nicht begreifen. Das hat alles nix
mit Server oder Client zu tun sondern nur mit dem Umfang des Backups und
der Funktionsweise des Restore...
Aber das ist alles nur Zeitverschwendung hier...
> Nichts davon ist besonders ueberraschend.
Jaja, genau... Klaus hat -- zwar in anderem Kontext -- den Kern dieses
Teilthreads treffend charakterisiert.
Gut' Nacht,
Thomas
[1] macbookpro-tk:~ tk$ ls /Applications/ | wc -l
330
Thomas Kaiser
> Volker Birk <bum...@dingens.org> wrote:
>
>> Warum jammerst Du dann hier rum, statt das Ding entweder so
>> anzupassen, wie Du es brauchst, oder was anderes zu nehmen?
>
> Weil es einfach broken-by-design ist, wenn sowas wichtiges wie
> User-mails nicht mitgesichert werden. Das kann man gar nicht laut
> mitbekommen.
Darum ging's mir auch... aber nur am Rande. Eigentlich hatte ich
gedacht, daß in dem Thread auch für mich ein paar interessante Aspekte
bzw. Neuigkeiten bei rumkommen... drum 'ne ausführliche Vorlage und
Hoffnung auf Diskussion. Aber die findet abseits Gesülze nicht statt.
> Selbstverständlich gehe ich davon aus, dass Thomas seinen Server
> richtig backuppen kann...
Mein eigener Kram wird mit PresStore gesichert/archiviert -- allerdings
inzwischen zweistufig, d.h. Backup via TM/Netzwerk auf Archiv-Serverchen
und von da die SparseBundle-Bänder inkrementell auf LTO. Beim Gros der
Kunden (hab mit deren Backups zum Glück eh nix zu tun) kommt ebenfalls
PresStore zum Einsatz (wobei dort auch vereinzelt TSM, MediaManager oder
Time Navigator zum Einsatz kommen)
Time Machine für Serverbackup ist in meinem Umfeld eh keine Option, da
das ja nur unter MacOS X (Server) läuft. Die paar Kunden, die überhaupt
xServes haben (primär wegen Collaboration Services und Sachen, die nur
unter MacOS X laufen) haben die in ihre übliche Sicherungsinfrastruktur
eingebunden (once again: PresStore, MediaManager, TMS oder eben Atempo)
Wobei ja grundsätzlich nicht mal was dagegen spricht, einen xServe
mittels TM zu sichern, wenn man weiß, was man tut, d.h. dafür sorgt, daß
das Backup umfänglich genug ausfällt und man den ganzen Zirkus inkl.
Desaster Recovery mal durchgespielt hat. Keine Ahnung, warum sich manche
jetzt hier drauf kaprizieren, TM wäre "natürlich" nix für Server-Backup
aber für Clients durchaus geeignet. Die nötige Differenzierung hat
woanders stattzufinden (beim Sicherstellen des Backup-Umfangs)
Aber egal, _hier_ werden wohl keinerlei neue Erkenntnisse/Aspekte mehr
aufschlagen...
Gruss,
Thomas
Matthias Peick
> 1) OS installieren. (beim User Anlegen darauf achten, dass dieser
> genau so heist wie der erste User beim originalen System)
Nö. Alle Benutzer anlegen und darauf achten, dass die UID stimmt.
> 3) Fremd-HW Treiber installieren, falls nicht im Backup (again:
> saubere Treiber die sich nicht in /System einnisten sind kein Problem)
Wie soll ich das untersuchen?
> 4) TM Restore machen.
Ganz sicher nicht.
> 5) evtl. fehlende Anwendungen (die sich nicht an Apple's Konzepte
> halten) nachinstallieren.
Wo die Hersteller ihre Unsauberkeiten auch öffentlich dokumentieren…
> 6) alle haesslichen Hacks und unsauberen Toolz nachinstallieren, die
> sich auch nicht an Apple's Vorgaben fuer Anwendungen halten.
Nicht mal Apple hält sich an alle Vorgaben.
> Danach sollte selbst ein von obskuren Anwendungen sprotzendes System
> wieder so laufen wie vorher.
Alternativ:
1. OS installieren.
2. Patchen bis zum Endstand
3. Benutzer mit den richtigen Namen und UIDs einrichten
4. Vom Admin-Benutzer alle Home-Verzeichnisse einspielen
5. Gemäß Installationsliste alle Fremdsoftware installieren und
Systemkonfigurationen tätigen
6. Erneut patchen
7. Funktionstest aller Einheiten
8. Glücklich sein
Das Vorgehen hat den Vorteil, dass Altlasten entsorgt wurden.
Gerald Eíscher
> Juergen P. Meier schrieb in <news:23641.30753...@news.jors.net>
>>
>
> Sensationell. Die "mittlere Option" also. Um Dein Posting inhaltlich
> verstehen zu können, muß ich mir jetzt 'ne dreiviertel Stunde Zeit, die
> 10.6-Installations-DVD und eine ausreichend große Platte nehmen, 10.6
> installieren, den Migrations-Assistent aufrufen und mir anschauen, was
> die "mittlere Option" nun genau macht?
Es reicht, wenn du den Migrationsassistenten aus den
Dienstprogramm-Ordner startest. Die Option in der Mitte ist irgendwas
mit TimeMachine-Backup.
--
Gerald
Peter
Hallo Matthias,
das wird wohl an deinen Systemen liegen. Ich habe hier ein MBP welches
in knapp 20 Min fertig war und natürlich ohne Probleme.
Das beantwortet zwar nicht deine Frage aber es scheint kein generelles
Problem zu sein.
Mit freundlichen Grüßen
Peter
Am 01.04.10 15:01, schrieb Matthias Peick:
> Hat jemand beide Pakete in einem Rutsch aktualisiert? Mir hat es jetzt
> schon den zweiten Rechner zerhauen und ich würde gerne den „Schuldigen“
> finden, bevor ich an den dritten gehe. Die beiden sind meine Verdächtigen.
>
> Das Neuaufsetzen geht mir etwas auf den Keks…
>
Juergen P. Meier
>>
>> Migrationsassistent -> Mittlere Option in der Auswahl von dreien.
>
> Sensationell. Die "mittlere Option" also. Um Dein Posting inhaltlich
> verstehen zu können, muß ich mir jetzt 'ne dreiviertel Stunde Zeit, die
> 10.6-Installations-DVD und eine ausreichend große Platte nehmen, 10.6
> installieren, den Migrations-Assistent aufrufen und mir anschauen, was
> die "mittlere Option" nun genau macht? Sonst noch Wünsche?
Es wuerde 7 Sekunden dauern aus irgendeiner Installation heraus den
Migrationsassistenten unter Applications/Utilities/ raus zu starten
und dort zu schauen. Aber ich sags dir auch so: "Migration aus einem
Time Machine Backup"
>>> Wenn ich nach der Anleitung vorgehen würde, müsste ich für ein auf
>>> diese Weise propagiertes Desaster Recovery wohl 2-3 Manntage
>>> einplanen und hätte danach garantiert nicht das System am Start, das
>>> ich vorher hatte.
>>
>> Nein.
>
> Alles klar. Du kennst meine Installation besser als ich selbst. Du
Vermutlich duerfte das sogar richtig sein. Wenn du 2-3 Manntage
brauchst um ein OS X aus einem TM zu restaurieren kannst du deine
eigene Installation nicht wirklich gut kennen.
> weißt, wo sich überall was an Daten versteckt (mein MBP ist auch
> Testumgebung für dies und das), wieviel Programme ich so im Einsatz habe
> [1], etc. etc.
Scheinbar hast du den Fehler begangen dich nicht an die
Designvorgaben zu halten und sonst irgendwelches Zeug an nicht dafuer
vorgesehenen Orten abgelegt.
>> Das dauert bei einem 80GByte-Used-Mac kanpp 4 Stunden. Vom Einlegen
>> der Boot-DVD bis zum Weiterarbeiten, inkl. der ueblichen "oh, ist ja
>> schon fertig"-Pausen.
>
> Jaja, soso...
BTDT.
>>>> Ansonsten: Finger weg von all zu unsauberen Apps/Hacks die das
>>>> System manipulieren, denn natuerlich steoert sich das mit einem
>>>> Systemkonformen Backupkonzept.
>>>
>>> Aha. Naja, mein Verständnis von Desaster Recovery scheint Deinem
>>> ziemlich zu widersprechen :-)
>>
>> TM ist ein hinreichendes Werkzeug fuer Restore eines Mac OS X Clients.
>>
>> Fuer ein Backupkonzept eines Servers eignet es sich hingegen nicht.
>
> Wow, sensationelle Erkenntnis. Nur -- wer behauptete denn bitte sehr das
Ja. So sensationell, dass selbst Apple dir das Vorher gesagt haette,
haettest du nur zugehoert. Ok, Apple sagt es nicht direkt und
deutlich, aber es muesste dir alleine an der Aufmachung der Time
Machine Beschreibung (apple.com) auffallen, dass dieses Feature
prinzipiell fuer den Client konzipiert wurde.
> oder das Gegenteil davon, daß Du jetzt mit solchen Aussagen aufwarten
> musst?
Ernsthaft, wer einen Server betreibt sollte ein ordenltiches
Backupkonzept haben. Und da passt ein Time Machine hoechstens als
zusaetzliches Feature hinein.
> Ich weiß halt, daß es genügend planlose Mac-Admins da draußen gibt, die
> genau das machen (Backup ohne Restore -- und das auch bei sog. Servern),
Wer Planlos einen Server betreibt hat es mit verlaub gesagt mehr als
verdient.
> Aber worum's mir eigentlich geht (Desaster Recovery mit Time Machine AKA
> Komplett-Restore eines Komplett-Backups ohne lachhaften Zirkus mit
> manueller Installation, manuellem Restore, manuellem "Fixen" von dies
> und das im Anschluß) willst Du wohl nicht begreifen. Das hat alles nix
> mit Server oder Client zu tun sondern nur mit dem Umfang des Backups und
> der Funktionsweise des Restore...
Kollege hat das TM-Backup bei der Installation einspielen mal gemacht,
war mit dem Ergebnis aber auch zufrieden.
> Aber das ist alles nur Zeitverschwendung hier...
Ich weis ja nicht, was bei dir 3 Tage dauert.
Schneeleopard installiert sich inkl. Patches in unter 1 Stunde auf
einem 2 Jahre alten Mac. Das 50 GByte Time Machine Backup ist ebenfalls
in einer Stunde eingespielt (Firewire Platte, 3 Jahre alt).
Fehlen noch die zwei, drei programme/Treiber, die TM nicht komplett
zurueckspielt, das kann man in ein paar Minuten nachinstallieren.
Es funktioniert. Es ist Ausreichend. Es ist Bequem und es ist Zuverlaessig.
Das sind vier von fuenf Kriterien fuer ein Clientsystembackup, wo vor TM
keine einzige andere kostenfreie oder beim OS integrierte Loesung auch
nur zwei Kriterien erfuellen konnte. Egal welches OS.
Juergen
Volker Birk
> Volker Birk <bum...@dingens.org> wrote:
>> Warum jammerst Du dann hier rum, statt das Ding entweder so anzupassen,
>> wie Du es brauchst, oder was anderes zu nehmen?
> Weil es einfach broken-by-design ist, wenn sowas wichtiges wie
> User-mails nicht mitgesichert werden. Das kann man gar nicht laut genug
;-)
Eigentlich tut es doch ganz gut, wenn Server-Admins, die das Recover
nicht testen, auf die Nase fallen.
> Selbstverständlich gehe ich davon aus, dass Thomas seinen Server richtig
> backuppen kann...
Ich auch. Er hat ja selbst die Config-Files genannt, deshalb ja die
Frage.
Thomas Kaiser
Entschuldige mal, aber in welch' falschem Film befinde ich mich denn
inzwischen? Du meinst tatsächlich diesen Dialog?
http://kaiser-edv.de/tmp/k7D0H3/Bild%201.png
Den kann er doch gar nicht meinen, denn wenn er davon schwadroniert, daß
er mittels Migrations-Assistent etwas aus dem Time Machine Backup holt,
dann ist es doch einerseits völlig klar und andererseits keinerlei
Erwähnung wert, daß er im Migrations-Assistenten auch "Time Machine" als
Quelle auswählt, oder nicht?
An der Stelle geschieht auch weit und breit nix Spannendes. Um zu
beurteilen, wie umfänglich so ein Restore dann ausfallen wird, sind die
Optionen _danach_ spannend. Da der Migrations-Assistent zum teil *völlig
anders* agiert, wenn er direkt von den Installations-Medien aufgerufen
wird (und das betrifft nicht nur die Wirkungsweise bspw. bzgl.
User-Accounts sondern auch die Dialoge also das UI), fand ich ein
entsprechendes Nachhaken schon angebracht, welche mittlere Option "von
den dreien" er nun angeklickst hat.
Wenn man den Migrations-Assistent stand-alone aus dem laufenden System
heraus aufruft, bekommt man folgende Dialoge zu Gesicht:
http://kaiser-edv.de/tmp/k7D0H3/Bild%202.png
http://kaiser-edv.de/tmp/k7D0H3/Bild%203.png
http://kaiser-edv.de/tmp/k7D0H3/Bild%204.png
Und was man hier anklickst, ist *maßgeblich* dafür, in wie viel
manuelles Gepfriemel man anschließend verwickelt ist. Ist diese Dialog-
Abfolge exakt die gleiche, wenn man den Migrations-Assistenten direkt
von der 10.6-DVD aufruft? Und geschieht auch das Gleiche? Falls das
alles identisch sein sollte, hat er meine Nachfrage, wie *ganz konkret*
er denn per Migrations-Assistent Sachen aus dem Time Machine Backup
geholt hat, mit "aus dem Time Machine Backup" beantwortet. Reizend...
Aber alles mein Fehler, ich hab jetzt erst kapiert, daß er noch gar
nicht verstanden hat, wie der Migrations-Assistent idealerweise
funktioniert. In seiner "Failsafe"-Anleitung erscheint ja der Hinweis,
den Migrations-Assistenten nicht gleich im Rahmen der Installation
auszuführen (was natürlich das Sinnigste ist, weil man sich damit
Scherereien bzgl. abweichenden UIDs bzw. User-Kurznamen oder -Langnamen
erspart) sondern irgendwann später. Und wenn man's so wie vorgeschlagen,
d.h. falsch, macht, dann hat man auch große Chancen, auf Warndialoge wie
diesen hier
http://kaiser-edv.de/tmp/k7D0H3/Bild%205.png
zu stoßen.
Naja, wirklich alles langsam völlig egal. Warum man diese Vorgehensweise
wählen sollte (abseits partiellem Migrieren einzelner User auf ein neues
System oder Pseudo-OS-Downgrade) anstatt einen Komplett-Restore (aus
einem vollständigen Backup heraus) hat mir noch keiner hier erklären
können. Wird mir _hier_ auch keiner mehr erklären können, denn ich werd'
wegen völliger Sinnlosigkeit bzw. reiner Zeitverschwendung dcsm.mist
erstmal abbestellen.
Gruss,
Thomas
Thomas Kaiser
Entschuldige mal, aber in welch' falschem Film befinde ich mich denn
Michael Lestinsky
> Volker Birk <bum...@dingens.org> wrote:
>
>> Warum jammerst Du dann hier rum, statt das Ding entweder so anzupassen,
>> wie Du es brauchst, oder was anderes zu nehmen?
>
> Weil es einfach broken-by-design ist, wenn sowas wichtiges wie
> User-mails nicht mitgesichert werden. Das kann man gar nicht laut genug
> rausschreien, damit es möglichst viele Leute *rechtzeitig* mitbekommen.
Selbst schuld. ;-)
/etc/postfix/main.cf:
# The mail_spool_directory parameter specifies the directory where
# UNIX-style mailboxes are kept. The default setting depends on the
# system type.
#
#mail_spool_directory = /var/mail
#mail_spool_directory = /var/spool/mail
Bye,
Michael
Goetz Hoffart
> Selbst schuld. ;-)
>
> /etc/postfix/main.cf:
Ja - und? Soll »man« das in der Konfigdatei ändern, auf einem MOSX
Server? Und die GUI obendrauf kriegt das sauber mit und das übersteht
das nächste Update?
Thomas Kosch
> Glaub ich so nicht. Wobei ich mich hier auf _Komplett-Restore_ beziehe,
> d.h. von Installationsmedium booten, unter "Dienstprogramme" den Punkt
> "System aus Backup wiederherstellen" auswählen, passendes Backup (bzw.
> "Snapshot") auswählen, Komplett-Restore starten lassen. Das würde in der
> Appleschen TM-Implementierung perfekt funktionieren, wenn denn das
> vorher erstellte Backup hinreichend vollständig _wäre_, was es aber
> nicht ist, wenn man nicht an paar Schrauben dreht (und sich permanent
> vergewissert, daß diese Schrauben auch immer noch so angezogen sind, wie
Unter SL ist es hinreichend vollständig.
ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Michael Lestinsky
> Michael Lestinsky <mic...@uugrn.org> wrote:
>
>> Selbst schuld. ;-)
>>
>> /etc/postfix/main.cf:
>
> Ja - und? Soll »man« das in der Konfigdatei ändern, auf einem MOSX
> Server? Und die GUI obendrauf kriegt das sauber mit und das übersteht
> das nächste Update?
Wenn dich dies derart in die Bredouille bringt, solltest du überlegen ob
du einen Mailserver fachgerecht administrieren kannst.
Bye,
Michael
Dirk Kring
Du bist ein Held, gut das du dich mit Max-OS und Postfix so gut
auskennst. Bei SuSE war es mal so ähnlich. Jede Konfigurationsänderung
hat über SuSEConfig alle Änderungen in den Konfigurationsdateien mit
denen aus den YAST-Einstellungen überschrieben. Wer da direkt in den
Konfigurationsdateien geändert hat und da immer im Auge hatte, wo da
wann was alles überschrieben wurde, war ein "SuSE Profi".
--
Dirk Kring
Michael Lestinsky
> Michael Lestinsky <mic...@uugrn.org> wrote:
>
>> * Goetz Hoffart <use...@hoffart.de>:
>>
>> > Michael Lestinsky <mic...@uugrn.org> wrote:
>> >
>> >> Selbst schuld. ;-)
>> >>
>> >> /etc/postfix/main.cf:
>> >
>> > Ja - und? Soll »man« das in der Konfigdatei ändern, auf einem MOSX
>> > Server? Und die GUI obendrauf kriegt das sauber mit und das übersteht
>> > das nächste Update?
>>
>> Wenn dich dies derart in die Bredouille bringt, solltest du überlegen ob
>> du einen Mailserver fachgerecht administrieren kannst.
>>
>
> Du bist ein Held,
Ach, Leute! Ist es denn zu viel verlangt, dass jemand, der einen scheinbar
unternehmenskritischen Service anbietet, diesen auch hinreichend beherrscht?
> gut das du dich mit Max-OS und Postfix so gut
> auskennst.
Du irrst.
Bye,
Michael
Dirk Kring
> * Dirk Kring <dirk....@arcor.de>:
>
> > Michael Lestinsky <mic...@uugrn.org> wrote:
> >
> >> * Goetz Hoffart <use...@hoffart.de>:
> >>
> >> > Michael Lestinsky <mic...@uugrn.org> wrote:
> >> >
> >> >> Selbst schuld. ;-)
> >> >>
> >> >> /etc/postfix/main.cf:
> >> >
> >> > Ja - und? Soll »man« das in der Konfigdatei ändern, auf einem MOSX
> >> > Server? Und die GUI obendrauf kriegt das sauber mit und das übersteht
> >> > das nächste Update?
> >>
> >> Wenn dich dies derart in die Bredouille bringt, solltest du überlegen ob
> >> du einen Mailserver fachgerecht administrieren kannst.
> >>
> >
> > Du bist ein Held,
>
> Ach, Leute! Ist es denn zu viel verlangt, dass jemand, der einen scheinbar
> unternehmenskritischen Service anbietet, diesen auch hinreichend beherrscht?
>
Du warst derjenige, der einen im wesentlichen untauglichen Rat für OS X
Server einführte und dagegen wurde argumentiert. Aber ich breche hier
ab, es wird unproduktiv.
--
Dirk Kring
Ingo Lembcke
>Unter SL ist es hinreichend vollständig.
Und deine Freundin ist wahrscheinlich auch ein bischen schwanger?
Oh Mann, entweder ist es vollständig oder nicht. Hinreichend würde selbst
mit dem Zusatz "ich glaube" oder "für mich" eine unzulässige Einschränkung
darstellen.
Mfg,
Ingo Lembcke
--
Und eine deutsche Fehlermeldung
("Pfeife zerbrochen" oder ähnliches)
ist so richtig, richtig kontraproduktiv :-( aus de.comp.sys.mac.misc von Christian Kirsch
Goetz Hoffart
> > Ja - und? Soll �man� das in der Konfigdatei �ndern, auf einem MOSX
> > Server? Und die GUI obendrauf kriegt das sauber mit und das �bersteht
> > das n�chste Update?
>
> Wenn dich dies derart in die Bredouille bringt,
Es bringt nicht mich in die Bredouille, sondern den MOSX Server, der auf
sowas schlecht vorbereitet ist.
> solltest du �berlegen ob du einen Mailserver fachgerecht administrieren
> kannst.
Ah, herrlich, sowas mu�te im Thread ja noch kommen, das fehlte ganz
klar. Danke daf�r!!!1
EOD,
G�tz
Michael Lestinsky
> Michael Lestinsky <mic...@uugrn.org> wrote:
>
>> > Ja - und? Soll »man« das in der Konfigdatei ändern, auf einem MOSX
>> > Server? Und die GUI obendrauf kriegt das sauber mit und das übersteht
>> > das nächste Update?
>>
>> Wenn dich dies derart in die Bredouille bringt,
>
> Es bringt nicht mich in die Bredouille, sondern den MOSX Server, der auf
> sowas schlecht vorbereitet ist.
Dann sag das doch das nächste Mal auch bitte so. Ich kenne die
Server-Variante nicht (hab ich auch nie behauptet) sondern wollte nur
zeigen, dass es noch einen anderen Weg gibt, Usermails automatisch von TM
mitsichern zu lassen, indem man sie nämlich aus /var/spool herauslegt.
Wenn es gute Argumente dagegen gibt, dies zu tun, dann sei bitte das nächste
mal bitte etwas expliziter. An Dirks Ausführungen zu SuSE kann ich mich
noch gut selbst erinnern, ich dachte - naiverweise - sowas sei 2010 kein
Problem mehr.
> EOD,
In Ordnung.
Bye,
Michael
Thomas Kosch
> Hallo,
> >Unter SL ist es hinreichend vollständig.
>
> Und deine Freundin ist wahrscheinlich auch ein bischen schwanger?
> Oh Mann, entweder ist es vollständig oder nicht. Hinreichend würde selbst
Es ist vollständig genug um nach einem Baremetal Restore wieder ein
laufendes System zu haben dessen Nutzdatenbestand ein Loch < 1h hat.
Und ja, das schließt auch solche Sachen wie den Mailspool mit ein.
> mit dem Zusatz "ich glaube" oder "für mich" eine unzulässige Einschränkung
> darstellen.
Es ist nicht vollständig genug um nach einem Restore sagen zu können ich
habe ein identisches System.
Basar Alabay
use...@hoffart.de (Goetz Hoffart) wrote:
> Ah, herrlich, sowas mußte im Thread ja noch kommen, das fehlte ganz
> klar. Danke dafür!!!1
LOL ... ist doch das heutige Niwoo. DU bist Schuld, warum hast DU die
Maus abgeschaltet!
B. Alabay
Juergen P. Meier
> Hallo,
>>Unter SL ist es hinreichend vollständig.
>
> Und deine Freundin ist wahrscheinlich auch ein bischen schwanger?
Wenn du den semantischen Unterschied zwischen "hinreichend" und
"bisschen" nicht kennst, solltest du daran arbeiten diese
Wissensluecke zu schliessen statt dich weiterhin in aller
Oeffentlichkeit der Laecherlichkeit preiszugeben.