SuperDuper friert ein.
Albin
12:40:16 AM | Error | vsdbutil: Couldn't get volume information for '/Volumes/
Backup Dienstag': Invalid argument
| 12:40:16 AM | Error | vsdbutil: no valid volume UUID found on '/Volumes/Backup
Dienstag': Invalid argument
Das kann man auf verschiedenen sparsebundles reproduzieren.
Ich habe die "Disks" und die Zugriffsrechte repariert, ohne Erfolg.
Was kann ich noch tun?
Danke schon jetzt.
Peter
Florian Dietsch
> Nach jahrelangem problemlosen Betrieb friert SuperDuper ein.
SD 2.6.2 l�uft hier auf OSX 10.6.7 wie ein Flutsch.
> Das kann man auf verschiedenen sparsebundles reproduzieren.
> Ich habe die "Disks" und die Zugriffsrechte repariert, ohne Erfolg.
>
> Was kann ich noch tun?
CCC verwenden, ist praktisch dasselbe:
http://www.macupdate.com/app/mac/7032/carbon-copy-cloner
FD
Thomas Kaiser
> Albin <pfack...@gmx.net> wrote:
>>
>> Was kann ich noch tun?
>
> CCC verwenden, ist praktisch dasselbe:
Oder Backup machen. Ist praktisch nicht dasselbe wie stures Kloning.
Gruss,
Thomas
Stefan Mettenbrink
>> Nach jahrelangem problemlosen Betrieb friert SuperDuper ein.
>
> SD 2.6.2 l�uft hier auf OSX 10.6.7 wie ein Flutsch.
>
>> Das kann man auf verschiedenen sparsebundles reproduzieren.
>> Ich habe die "Disks" und die Zugriffsrechte repariert, ohne Erfolg.
>>
>> Was kann ich noch tun?
>
> CCC verwenden, ist praktisch dasselbe:
Fr�her war es mal so, dass CCC irgendwelche Metainformationen nicht mit
kopiert hat. Ist das jetzt anders?
MfG, Metti.
Florian Dietsch
> Fr�her war es mal so, dass CCC irgendwelche Metainformationen nicht mit
> kopiert hat. Ist das jetzt anders?
Seit geraumer Zeit ist alles OK. CCC kopiert alles. Kann Dir dazu keine
URL auf die schnelle nennen.
FD
Florian Dietsch
Ich nutze SuperDuper, aber sicher kann auch CCC inkrementelle Backups.
F�r meine Privatrechner reichen SN und CCC.
FD
Paul-Wilhelm Hermsen
Die aktuelle Version ist 2.6.4!
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Florian Dietsch schrieb in <news:1k5fqva.1l3ylm4mpskcsN%diet...@uni.de>
>> > Albin <pfack...@gmx.net> wrote:
>> >>
>> >> Was kann ich noch tun?
>> >
>> > CCC verwenden, ist praktisch dasselbe:
>>
>> Oder Backup machen. Ist praktisch nicht dasselbe wie stures Kloning.
>
> Ich nutze SuperDuper, aber sicher kann auch CCC inkrementelle Backups.
CCC kann/könnte inkrementelle Backups, SuperDuper nicht. SuperDuper kann
nur inkrementell einen Klon auffrischen, wie es auch CCC kann. Aber es
entstehen keine Versionen. Keine Versionen, kein Backup. So simpel ist
das. :-)
Der OP scheint das ja zu umschiffen, indem er seine Klone täglich
rotiert. Wenn's Spaß macht, warum nicht...
> Für meine Privatrechner reichen SN und CCC.
Für meine Privatrechner und meine Firmenrechner reicht TimeMachine. Und
ab und an ein Klon. Backup ist kein Luxus mehr seit TimeMachine. Und
trotzdem klonen viele aus alter Gewohnheit weiter stur in der Gegend
herum...
Gruss,
Thomas
Albin
Albin
> Updaten!
> Die aktuelle Version ist 2.6.4!
Laeuft hier (sollte zumindest).
Albin
> Florian Dietsch schrieb in <news:1k5fu7g.qi715q1pi6229N%diet...@uni.de>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>
>>> Florian Dietsch schrieb in <news:1k5fqva.1l3ylm4mpskcsN%diet...@uni.de>
>>> > Albin <pfack...@gmx.net> wrote:
>>> >>
>>> >> Was kann ich noch tun?
>>> >
>>> > CCC verwenden, ist praktisch dasselbe:
>>>
>>> Oder Backup machen. Ist praktisch nicht dasselbe wie stures Kloning.
>>
>> Ich nutze SuperDuper, aber sicher kann auch CCC inkrementelle Backups.
>
> entstehen keine Versionen. Keine Versionen, kein Backup. So simpel ist
> das. :-)
>
> rotiert. Wenn's Spa� macht, warum nicht...
>
>> F�r meine Privatrechner reichen SN und CCC.
>
> F�r meine Privatrechner und meine Firmenrechner reicht TimeMachine. Und
> trotzdem klonen viele aus alter Gewohnheit weiter stur in der Gegend
> herum...
>
> Gruss,
>
> Thomas
Ja, ich rotiere,-)
Wenn ich wuesste, wie man TimeMachine rotieren lassen koennte ...
Gruss
Peter
Albin
> Nach jahrelangem problemlosen Betrieb friert SuperDuper ein.
>
> 12:40:16 AM | Error | vsdbutil: Couldn't get volume information for '/
Volumes/
> Backup Dienstag': Invalid argument
Backup
> Dienstag': Invalid argument
>
> Ich habe die "Disks" und die Zugriffsrechte repariert, ohne Erfolg.
>
> Was kann ich noch tun?
>
> Danke schon jetzt.
>
> Peter
Folgendes habe ich an Shirt Pocket geschickt, aber nur eine dumme Antwort
bekommen:
12:40:16 AM | Error | vsdbutil: Couldn't get volume information for '/Volumes/
Backup Dienstag': Invalid argument
Here SuperDuper freezes
External disk:
Capacity 319,94 GB
Free 13,08 GB
Sparsebundle:
Capacity 102,40 GB
Free 13,05 GB
Not here
External disk:
Capacity 1000,00 GB
Free 276,39 GB
Sparsebundle:
Capacity 102,06 GB
Free 22,53 GB
Is SuperDuper a bit sensitive here?
Gruss
Peter
Thomas Kaiser
> Wenn ich wuesste, wie man TimeMachine rotieren lassen koennte ...
Mach's einfach.
Nimm zwei Platten, laß die eine immer dran (stündliche Backups, olé) und
schließ die andere alle x Tage/Wochen an und ansonsten separat weg.
Alles, was Du dann tun mußt, ist kurz mal in den Systemeinstellungen das
TM-Volume umstellen und nach dem Sicherungslauf wieder zurück. Das
war's.
Was das Ganze *real* bringt im Vergleich zum lahmen Rotieren von Klonen
der ganzen Festplatte ist jetzt die Hausaufgabe, die's zu lösen gilt.
Gruss,
Thomas
Bernd Fröhlich
> Folgendes habe ich an Shirt Pocket geschickt, aber nur eine dumme Antwort
> bekommen:
Hmm, ich hatte da auch mal eine Frage hingeschickt. Die Antwort war sehr
kompetent und hilfsbereit.
Was haben sie Dir denn geantwortet?
Albin
"We couldn't care less about the size of the disk."
Vielleicht habe ich das auch falsch verstanden.
Peter
Albin
Michael Tueller
> Mach's einfach.
Was meinst Du bezüglich HFS+ und TimeMachine?
John Siracusa meinte kürzlich in einem Podcast, dass die Combo eigentlich
stark gefährdet sei für Auto-Zerstörung.
Ich hab die technischen Argumente nicht wirklich beisammen, es ging darum,
dass durch die Hardlinks für HFS+ über viele TM-Läufe gefährlich viele
Filesystem-Einträge entstünden, was wiederum etwas sei, womit HFS+ nicht
wirklich verlässlich umgehen könne (viele, viele Einträge).
Wie gesagt, tönt jetzt schwer nach FUD, weil ich a) nicht viel Ahnung und
b) die Quelle (noch) nicht parat habe.
(Ich glaube es war bei <http://5by5.tv> in Hypercritical).
Rein gefühlsmässig;-) wär mir auch wieder ein BU-Programm, das in einen
eigenen Container sichert lieber.
Muss mal wieder Retrospect testen, wenn ich masochistisch drauf bin.
Yvonne Steiner
> Updaten!
> Die aktuelle Version ist 2.6.4!
Und funktioniert auch bestens unter Lion.
--
Yvonne Steiner
Thomas Kaiser
> Was meinst Du bezüglich HFS+ und TimeMachine?
Funktioniert allemal besser als Dumpf-Kloning mit SuperDuper oder auch
CCC. V.a. wenn man im Hinterkopf hat, daß man Datensicherung betreiben
möchte und nicht nur stumpf Rituale zelebriert.
> John Siracusa meinte kürzlich in einem Podcast, dass die Combo eigentlich
> stark gefährdet sei für Auto-Zerstörung.
> Ich hab die technischen Argumente nicht wirklich beisammen, es ging darum,
> dass durch die Hardlinks für HFS+ über viele TM-Läufe gefährlich viele
> Filesystem-Einträge entstünden, was wiederum etwas sei, womit HFS+ nicht
> wirklich verlässlich umgehen könne (viele, viele Einträge).
Mag sein, legt man halt ab und an das Dateisystem auf den Backup-Medien
neu an. Ist ja auch überhaupt kein Problem, wenn man rotierende Backup-
Medien verwendet. Höchstens für Leute, die es wichtig finden, eine
durchgehende Backup-Historie von mehreren Jahren am Start zu haben
(möglicherweise ein Indiz dafür, daß man Backup mit Archivierung
verwechselt oder halt ein bisserl Spleen -- so wie Unix-Admins oft ohne
Not die Uptime irgendwelcher Server möglichst hoch halten wollen. Naja,
wie auch immer. Ich versteh's nicht)
> Wie gesagt, tönt jetzt schwer nach FUD, weil ich a) nicht viel Ahnung und
> b) die Quelle (noch) nicht parat habe.
> (Ich glaube es war bei <http://5by5.tv> in Hypercritical).
Puh, nee. Über 80 Minuten Lebenszeit verschwenden, um auf Verdacht einen
Podcast über mich ergehen zu lassen, um irgendwo Deine Aussage bestätigt
zu bekommen?
> Rein gefühlsmässig;-) wär mir auch wieder ein BU-Programm, das in einen
> eigenen Container sichert lieber.
> Muss mal wieder Retrospect testen, wenn ich masochistisch drauf bin.
LOL, ja ganz viel Spaß. Ich nehm einfach weiter Time Machine mit
rotierenden Medien. Und Rotation bei Time-Machine ist ganz simpel:
Einfach jede Woche oder alle zwei Wochen kurz auf eine separate Platte
sichern lassen. Bedingt durch "Alles im Dateisystem" kriegt die
automatisch ihre eigene Backup-Historie, d.h. ist in sich selbst
konsistent. Auf der fehlen halt nur ggf. Änderungen, die innerhalb der 1
oder 2 Wochen durchgeführt worden (aber die sind ja allesamt in durch
die stündlichen Sicherungen auf der anderen Platte abgedeckt).
Und wenn dann mal eine Backup-Platte oder auch nur ihr Dateisystem hopps
geht, dann hat man ja noch die andere mit einer intakten Historie (inkl.
Versionen). Und hey! Das sind nur die Datensicherungen. Die eigentlichen
Daten liegen doch woanders. Außer natürlich man macht den Fehler und
versucht, ein Backup-Werkzeug als Archiv-Lösung zu mißbrauchen...
Nee, nee. Das Hauptproblem mit TimeMachine ist, daß es zu simpel und zu
gut funktioniert. Damit haben Leute, die jahrelang durch z.B.
Retrospect-Benutzung "versaut" wurden, ihre Probleme. Analog zu den
Windows-Umsteigern auf Mac, die auch erstmal die Krise kriegen, weil auf
einmal nix mehr sch***kompliziert ist. ;-)
Gruss,
Thomas
Thomas Kaiser
> Paul-Wilhelm Hermsen <pwhe...@gmx.de> wrote:
>
>> Updaten!
>> Die aktuelle Version ist 2.6.4!
>
> Und funktioniert auch bestens unter Lion.
Und was funktioniert da so? Für was nutzt "man" denn SuperDuper unter
Lion?
Gruss,
Thomas
Yvonne Steiner
> Yvonne Steiner schrieb am 04.08.2011
> > Paul-Wilhelm Hermsen <pwhe...@gmx.de> wrote:
> >
> >> Updaten!
> >> Die aktuelle Version ist 2.6.4!
> >
> > Und funktioniert auch bestens unter Lion.
>
> Und was funktioniert da so? F�r was nutzt "man" denn SuperDuper unter
> Lion?
Um einen bootf�higen Klon zu erhalten.
Den erstelle ich zus�tzlich zum Backup mit Time Machine (2 x monatlich).
--
Yvonne Steiner
Volker Birk
> Nee, nee. Das Hauptproblem mit TimeMachine ist, daß es zu simpel und zu
> gut funktioniert.
Seltsam. Ich empfinde das gar nicht als Problem ;-)
Ganz ehrlich: Time Machine ist klasse. Das Ding hat mir wirklich gute
Dienste geleistet, und es spart den ganzen Ärger weg. Mein Bedarf für
Backup-Programme für den Mac ist damit vollständig gedeckt, allenfalls
gibts hier noch rsync für die Sicherung der Leenoox-Büchsen.
Viele Grüsse,
VB.
--
Wenn Du für eine Leistung nichts bezahlst,
bist Du nicht der Kunde, sondern die Ware.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Und was funktioniert da so? Für was nutzt "man" denn SuperDuper unter
>> Lion?
>
> Um einen bootfähigen Klon zu erhalten.
> Den erstelle ich zusätzlich zum Backup mit Time Machine (2 x monatlich).
Hmmm... nur so aus (ehrlichem) Interesse: Und wozu machst Du das?
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Nee, nee. Das Hauptproblem mit TimeMachine ist, daß es zu simpel und zu
>> gut funktioniert.
>
> Seltsam. Ich empfinde das gar nicht als Problem ;-)
Das Problem haben oft Leute, die von anderen Backup-Programmen her
vorkonditioniert sind. Die glauben dann, sie könnten TimeMachine
eigentlich nur wirklich "sicher" nutzen, wenn sie damit auch komplexe
Medien-Rotationsschemata dieser Art
http://en.wikipedia.org/wiki/Backup_rotation_scheme#Five-Tape_Hanoi_Schedule
nachbilden können (was zugegebenermaßen schwierig ist, weil andauernd
was umgestellt werden müsste aber ebenso zugebenermaßen überhaupt gar
nicht nötig ist, weil TM ja auch wunderhübsch auf einem Medium Versionen
anlegt, und die ganze Notwendigkeit für das Rotieren von Tapes einfach
so nicht mehr gegeben ist, da andere Medienart und anderes Sicherungs-
konzept).
> Ganz ehrlich: Time Machine ist klasse. Das Ding hat mir wirklich gute
> Dienste geleistet, und es spart den ganzen Ärger weg. Mein Bedarf für
> Backup-Programme für den Mac ist damit vollständig gedeckt
Wobei man schon dazusagen muß, daß sich TM in 10.5 also in der ersten
Inkarnation auch schwere Schnitzer erlaubte (v.a. unter MacOS X Server,
wo ohne Korrektur der Preferences die kompletten Mails der Nutzer vom
Backup ausgenommen waren). Aber aktuell reicht es für ca. 100% des
Backup-Bedarfs von Heim- oder SOHO-Anwendern. Und wenn der Admin weiß,
was er tut evtl. auch für die von etwas größeren Firmen.
Und wer wirklich auf Nummer sicher gehen will, der arbeitet mit 'nem
zweiten Medium. Das muß aber nicht wie bei anderen Backup-Programmen
oder Tapes täglich rotiert werden sondern es reicht, das zweite Medium
ab und an mal einzusetzen.
Gruss,
Thomas
Jochem Huhmann
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Nee, nee. Das Hauptproblem mit TimeMachine ist, daß es zu simpel und zu
>> gut funktioniert.
>
> Seltsam. Ich empfinde das gar nicht als Problem ;-)
>
> Ganz ehrlich: Time Machine ist klasse. Das Ding hat mir wirklich gute
> Dienste geleistet, und es spart den ganzen Ärger weg. Mein Bedarf für
> Backup-Programme für den Mac ist damit vollständig gedeckt, allenfalls
> gibts hier noch rsync für die Sicherung der Leenoox-Büchsen.
Wobei ich es für keine schlechte Idee halte, die stündliche Sicherung
sein zu lassen und die Automatik entweder auf seltenere Sicherungen
umzubiegen oder die Backups bei Bedarf manuell zu machen (kostet ja nur
einen Mausklick). Da fallen ansonsten Unmengen an Hardlinks an und die
Zweifel an HFS+ sind scheinbar wirklich nicht so ganz aus der Luft
gegriffen.
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
Volker Birk
> Da fallen ansonsten Unmengen an Hardlinks an und die
> Zweifel an HFS+ sind scheinbar wirklich nicht so ganz aus der Luft
> gegriffen.
Mir ist bisher noch gar kein HFS+ kaputtgegangen, an keinem Rechner.
Dagegen hatte ich schon mehrfach ausgenullte Dateien mit XFS erlebt.
<http://developer.apple.com/library/mac/#technotes/tn/tn1150.html>
| The Mac OS X implementation of hard links on HFS Plus volumes was done
| using the existing metadata fields of the catalog records. This makes it
| possible to back up and restore a volume using hard links, by backing up
| and restoring individual files, without having to understand or
| interpret the hard links. An HFS Plus implementation may choose to
| automatically follow hard links, or not.
Thomas Kaiser
> Volker Birk <bum...@dingens.org> writes:
>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>> Nee, nee. Das Hauptproblem mit TimeMachine ist, daß es zu simpel und
>>> zu gut funktioniert.
>>
>> Seltsam. Ich empfinde das gar nicht als Problem ;-)
>>
>> Ganz ehrlich: Time Machine ist klasse. Das Ding hat mir wirklich gute
>> Dienste geleistet, und es spart den ganzen Ärger weg. Mein Bedarf für
>> Backup-Programme für den Mac ist damit vollständig gedeckt, allenfalls
>> gibts hier noch rsync für die Sicherung der Leenoox-Büchsen.
>
> Wobei ich es für keine schlechte Idee halte, die stündliche Sicherung
> sein zu lassen und die Automatik entweder auf seltenere Sicherungen
> umzubiegen oder die Backups bei Bedarf manuell zu machen (kostet ja nur
> einen Mausklick).
Genau das eliminiert aber zwei zentrale Vorteile von TimeMachine:
- Alles Manuelle im Kontext mit Backup macht man immer solange brav,
solange es nicht nötig ist. Tritt dann der Restore-Fall ein, stellt
man fest, daß man wegen $was-auch-immer die Zeit vorher kein Backup
gemacht hat (AKA Murphy's Law). Hier auf Automatismen zu verzichten
halte ich für beinahe schon töricht
- grad die stündliche Sicherung ist ein Pluspunkt von TM solange noch
nicht alle Software sich des Versions-Feature von 10.7 bedient. Im
Zweifel mehrere ältere Versionen eines Dokuments zur Hand zu haben,
wenn man irgendwann gemerkt hat, daß man sich bspw. durch einen
Copy&Paste-Fehler relevante Teile des Dokuments geschreddert hat, kann
sehr hilfreich sein
> Da fallen ansonsten Unmengen an Hardlinks an und die Zweifel an HFS+
> sind scheinbar wirklich nicht so ganz aus der Luft gegriffen.
Hast Du dafür eine belastbare bzw. schnell prüfbare Quelle?
Gruss,
Thomas
Jochem Huhmann
>> Wobei ich es für keine schlechte Idee halte, die stündliche Sicherung
>> sein zu lassen und die Automatik entweder auf seltenere Sicherungen
>> umzubiegen oder die Backups bei Bedarf manuell zu machen (kostet ja nur
>> einen Mausklick).
>
> Genau das eliminiert aber zwei zentrale Vorteile von TimeMachine:
>
> - Alles Manuelle im Kontext mit Backup macht man immer solange brav,
> solange es nicht nötig ist. Tritt dann der Restore-Fall ein, stellt
> man fest, daß man wegen $was-auch-immer die Zeit vorher kein Backup
> gemacht hat (AKA Murphy's Law). Hier auf Automatismen zu verzichten
> halte ich für beinahe schon töricht
>
> - grad die stündliche Sicherung ist ein Pluspunkt von TM solange noch
> nicht alle Software sich des Versions-Feature von 10.7 bedient. Im
> Zweifel mehrere ältere Versionen eines Dokuments zur Hand zu haben,
> wenn man irgendwann gemerkt hat, daß man sich bspw. durch einen
> Copy&Paste-Fehler relevante Teile des Dokuments geschreddert hat, kann
> sehr hilfreich sein
Kommt sehr auf die Art der Daten bzw. den eigenen Umgang damit an. Wenn
man das bewußt manuell macht, sollte das voraussetzen, dass man weiß,
was man wann sichert.
Aber klar, es hat schon seinen Grund, dass das per Default automatisch
und stündlich passiert. Wenn man sich mit Backups nicht weiter
herumschlagen will (und genau das ist ja Sinn und Zweck von TM) ist es
sicherlich nicht verkehrt, es dabei zu belassen.
>> Da fallen ansonsten Unmengen an Hardlinks an und die Zweifel an HFS+
>> sind scheinbar wirklich nicht so ganz aus der Luft gegriffen.
>
> Hast Du dafür eine belastbare bzw. schnell prüfbare Quelle?
Nur Anekdoten im Vorbeigehen, sorry. Die Fälle, in denen ein TM-Backup
auf lokalen Datenträgern von allein zerbröselt, scheinen nach längerer
Zeit auf ständig durchlaufenden Rechnern zu passieren. Eigentlich sollte
das überhaupt nicht passieren.
Thomas Kaiser
> Jochem Huhmann <j...@gmx.net> wrote:
>> Da fallen ansonsten Unmengen an Hardlinks an und die Zweifel an HFS+
>> sind scheinbar wirklich nicht so ganz aus der Luft gegriffen.
>
> Mir ist bisher noch gar kein HFS+ kaputtgegangen, an keinem Rechner.
Mir schon selbst. Und die Kunden, die vor 10 Jahren auf Macs als Server
setzten, waren sich irgendwann alle bewußt, daß sie ihre Daten einem
Dateisystem anvertrauten, das einen fatalen Hang zum Suizid hatte. Im
Ernst: Damals gab's regelmäßig Trouble, je größer die Volumes, desto
eher.
Allerdings habe ich die letzten Jahre nichts Dergleichen mehr
mitbekommen. Und das nicht etwa, weil kein HFS+ mehr eingesetzt würde
für große Datenmengen. Bei vielen Kunden stehen Macs als Sync-Ziel, um
dicke Server wegzusichern, da die Restore-Zeiten von Band albern hoch
wären...
> Dagegen hatte ich schon mehrfach ausgenullte Dateien mit XFS erlebt.
>
><http://developer.apple.com/library/mac/#technotes/tn/tn1150.html>
>| The Mac OS X implementation of hard links on HFS Plus volumes was done
>| using the existing metadata fields of the catalog records. This makes it
>| possible to back up and restore a volume using hard links, by backing up
>| and restoring individual files, without having to understand or
>| interpret the hard links. An HFS Plus implementation may choose to
>| automatically follow hard links, or not.
Da ist Apple in der Tat sehr vorsichtig: Neue OS-spezifische Anbauten
ans hauseigene Dateisystem werden streng "abwärtskompatibel" umgesetzt:
- Extended Attributes (in 10.4 eingeführt) werden als named forks im
Attributes File gespeichert. ACLs basieren auf EAs. Was in 10.4 neue
Features sind, sind aus Sicht des Dateisystems bzw. einer älteren
MacOS X Version einfach alte Bekannte mit uninteressantem Inhalt.
- Verzeichnis-Hardlinks (in 10.5 eingeführt) sehen aus Sicht eines 10.4
oder vorherigen Systems aus wie Aliase (und funktionieren so auch)
- komprimierte Dateien (in 10.6 eingeführt) sehen aus Sicht eines 10.5
oder vorherigen Systems aus wie eine leere Datei, an der Extended
Attributes -- Stichwort com.apple.decmpfs -- bzw. eine Resourcefork
kleben (die angeblich ach so deprecated Resourcefork wurde gewählt,
weil man auf keinem anderen Weg sicherstellen konnte, daß ein neues
Dateisystem-Feature, das erst ab 10.x funktioniert, nicht für Trouble
sorgt, wenn das Dateisystem mit MacOS X Vorversionen in Kontakt kommt)
- Und was sie in 10.7 Hübsches an HFS+ drangeschraubt haben, entzieht
sich bisher mangels Zeit/Interesse meiner Erkenntnis...
Gruss,
Thomas
Volker Birk
> Volker Birk schrieb in <news:j1gfvp...@news.in-ulm.de>
>> Jochem Huhmann <j...@gmx.net> wrote:
>>> Da fallen ansonsten Unmengen an Hardlinks an und die Zweifel an HFS+
>>> sind scheinbar wirklich nicht so ganz aus der Luft gegriffen.
>> Mir ist bisher noch gar kein HFS+ kaputtgegangen, an keinem Rechner.
> Mir schon selbst. Und die Kunden, die vor 10 Jahren auf Macs als Server
> setzten, waren sich irgendwann alle bewußt, daß sie ihre Daten einem
> Dateisystem anvertrauten, das einen fatalen Hang zum Suizid hatte. Im
> Ernst: Damals gab's regelmäßig Trouble, je größer die Volumes, desto
> eher.
Da hatte ich ja dann Glück, dass ich keine MacOS-Server betrieben hab.
Yvonne Steiner
> Yvonne Steiner schrieb
> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
> >> Und was funktioniert da so? F�r was nutzt "man" denn SuperDuper unter
> >> Lion?
> >
> > Um einen bootf�higen Klon zu erhalten.
> > Den erstelle ich zus�tzlich zum Backup mit Time Machine (2 x monatlich).
>
> Hmmm... nur so aus (ehrlichem) Interesse: Und wozu machst Du das?
In erster Linie zur doppelten Sicherheit.
Zurzeit l�uft aber das Lion-Backup meines MBP17 (intel) mit Time Machine auf
einer ext. Firewire-platte und der Klon mit SnowLeopard auf einer zweiten ext.
Firewire-Platte.
Brauche ich gelegentlich doch noch ein PowerPC-Programm, das der Lion nicht
mehr starten kann, so h�nge ich meinen SnowLeopard-Klon ans MBP und starte
damit auf.
Das ist doch eine gute L�sung, meinst du nicht auch?
--
Yvonne Steiner
Michael Tueller
> möglicherweise ein Indiz dafür, daß man Backup mit Archivierung
Das hab ich hinter mir, hat mal vor Jahren ganz laut Klick gemacht, das
war aber mal eine Erleichterung.
Aber Klonieren tu ich weiter, weil (jedenfalls bei mir schon 2 Mal) eine
Komplettwiederherstellung mit TM unglaublich viel länger dauert als eine
Rückklonierung mit einem dieser Dolly-Programme.
Vielleicht dann eventuell noch eines dieser Crashplan, Spideroak und was
haste nicht gesehen Dinger, aber die Cloud sehe ich für mich eher als
Archivierungsabsicherung und da reicht bei mir ja schon fast das jeweilige
Gratisangebot.
Michael, der grad das DAM-Buch vom Peter Krogh liest. (ja, das ist ein M
da am Schluss!)
Michael Tueller
> Mir ist bisher noch gar kein HFS+ kaputtgegangen, an keinem Rechner.
Mir schon, ist aber auch schon länger her.
Das hat mir DiskWarrior beschert und den lass' ich ab und zu mal laufen,
nur weil ich ihn hab.
Findet schon manchmal 'was, ein paar rote Einträge.
Wahrscheinlich meist eher Selbstrechtfertigung als wirklich tragische Lage.
Volker Birk
> Aber Klonieren tu ich weiter, weil (jedenfalls bei mir schon 2 Mal) eine
> Komplettwiederherstellung mit TM unglaublich viel länger dauert als eine
> Rückklonierung mit einem dieser Dolly-Programme.
Als mein MacBook Pro den Geist aufgab, ging ich in den Laden und holte
das Air hier.
Ich schaltete es ein, steckte die Backup-Platte dran, und wählte den
Menüpunkt aus, der es von einem Time-Machine-Backup wiederherstellen
sollte.
Der Mac zeigte mir dann irgendwas mit 40 Minuten an. Das hat in etwa
auch hingehauen, vielleicht wars auch eine knappe Stunde. Während dieser
Zeit musste ich rein gar nichts tun, konnte mich um andere Dinge
kümmern.
Danach loggte ich mich ein: sogar die Fensterpositionen waren an
derselben Stelle.
Ich empfinde das weder als lang noch als aufwendig noch als
problembehaftet, sondern schlicht als optimal.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Yvonne Steiner schrieb
>> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> >> Lion?
>> >
>> > Um einen bootfähigen Klon zu erhalten.
>> > Den erstelle ich zusätzlich zum Backup mit Time Machine (2 x
>>
>> Hmmm... nur so aus (ehrlichem) Interesse: Und wozu machst Du das?
>
> In erster Linie zur doppelten Sicherheit.
Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen im
laufenden Betrieb außer falls SuperDuper zaubern könnte. Wie will es
denn eine gerade geöffnete Datenbank wegsichern? Und derer gibt es viele
unter MacOS X. Das System selbst nutzt bspw. SQLite-Datenbanken für
Spotlight, Fonts, das Versions-Zeugs in 10.7 und noch andere Sachen.
Sogar simple Programme wie ein Firefox haben 'zig Datenbanken geöffnet,
während sie laufen. In welchem Zustand kommen die auf dem Klon an?
Konsistent etwa?
Ich klon ja auch ab und an mal, boote dazu aber von einem anderen Medium
(in Zukunft von der 10.7er Recovery Partition) und laß das Festplatten-
Dienstprogramm einen *konsistenten* Klon anfertigen und fertig. Nur so
hat man doch die Gewißheit, daß auch wirklich alles 1:1 und vor allem in
einem funktionierenden Zustand ankommt?
Gruss,
Thomas
Ralph A. Schmid, dk5ras
>Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen im
>laufenden Betrieb au�er falls SuperDuper zaubern k�nnte. Wie will es
>denn eine gerade ge�ffnete Datenbank wegsichern? Und derer gibt es viele
>unter MacOS X.
Warum soll das nicht gehen? Unter Windows gibt es auch den Volume
Shadow Copy Service, der perfekte Backu�ps eines laufenden Systems
erm�glicht, dann wird der Mac das ja wohl auch k�nnen?!
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Heiner Veelken
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
> >Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen im
> >laufenden Betrieb au�er falls SuperDuper zaubern k�nnte. Wie will es
> >denn eine gerade ge�ffnete Datenbank wegsichern? Und derer gibt es viele
> >unter MacOS X.
>
> Warum soll das nicht gehen? Unter Windows gibt es auch den Volume
> Shadow Copy Service, der perfekte Backu�ps eines laufenden Systems
> erm�glicht, dann wird der Mac das ja wohl auch k�nnen?!
Au�erdem, w�rde ich mich dann fragen (steinigt mich, wenn das Quatsch
sein sollte), warum TimeMachine das denn dann besser machen sollte,
bspw. eine "gerade ge�ffnete Datenbank wegsichern"?
--
Gruss Heiner
Volker Birk
> Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen im
> laufenden Betrieb außer falls SuperDuper zaubern könnte. Wie will es
> denn eine gerade geöffnete Datenbank wegsichern?
Wenn die Datenbank transaktionssicher implementiert ist, gibt es ja
keine Zustände, die zu ihrer Zerstörung führen können. Da würde ich mir
eher über andere Daten Gedanken machen.
SQLite implementiert die dazu notwendigen Mittel, ich hoffe doch, dass
die Leute bei Apple, die das Ding einsetzen, wissen was sie da tun.
Wie man einen Snapshot technisch zieht? Nun, blockweise ;-)
Yvonne Steiner
> Yvonne Steiner schrieb:1
> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
> >
> >> Yvonne Steiner schrieb
> >> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
> >> >> Und was funktioniert da so? F�r was nutzt "man" denn SuperDuper unter
> >> >> Lion?
> >> >
> >> > Um einen bootf�higen Klon zu erhalten.
> >> > Den erstelle ich zus�tzlich zum Backup mit Time Machine (2 x
> >> > monatlich).
> >>
> >> Hmmm... nur so aus (ehrlichem) Interesse: Und wozu machst Du das?
> >
> > In erster Linie zur doppelten Sicherheit.
>
> Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen im
> laufenden Betrieb au�er falls SuperDuper zaubern k�nnte.
Aber nein, ich klone nat�rlich *nicht* im laufenden Betrieb.
SuperDuper ist also das alleinige Programm, das w�hren des Klonens l�uft.
Zu meiner Schande stellte ich gerade fest, dass ich die Sache mit dem Klonen
leider etwas missverst�ndlich formuliert hatte und du dich deshalb mit Recht
so wunderst.
> Wie will es
> denn eine gerade ge�ffnete Datenbank wegsichern?
Keine Bange, mein Klon (per Superduper) *ist* ein exaktes Duplikat meiner
int. Mac-HD auf einer ext. Firewire-HD.
--
Yvonne Steiner
Stefan Nobis
> Aber nein, ich klone natürlich *nicht* im laufenden Betrieb.
> SuperDuper ist also das alleinige Programm, das währen des Klonens
> läuft.
Was Thomas meint, ist das Snapshot-Problem:
Das Betriebssystem hat eine Datei zum Schreiben geöffnet. In dieser
Zeit läuft ein Programm wie SuperDuper und versucht z.B. Block für
Block der Festplatte zu lesen. Jetzt kommt es an die Blöcke (nehmen
wir der Einfachheit mal 2 an) der besagten Datei. SuperDuper liest
Block 1, dann schlägt das preemtive Multitasking zu und der Prozess
(z.B. ein elementarer Prozess des Betriebssystems) bekommt
Rechenzeit. In dieser Zeit werden Änderungen in die Datei geschrieben,
die Block 1 verändern. Dann ist wieder SuperDuper dran, kriegt nichts
von den Änderungen an Block 1 mit und macht mit Block 2 weiter.
Damit hättest Du eine inkonsistente Kopie der Datei, Block 1 noch aus
der alten Version der Datei, Block 2 aus der neuen. Das kann dazu
führen, dass die Datenstrukturen innerhalb der Datei (also das, was
Programme aus dem Inhalt zu interpretieren versuchen) inkonsistent
geworden ist und damit die Datei unlesbar gemacht wurde.
Klassisch wird dieses Thema insbesondere im Bereich Datenbanken
behandelt. Ein DB-Server steht ja im Idealfall nie still und trotzdem
möchte man gerne eine konsistente Sicherungskopie seiner Daten. Das
geht eben leider nicht, indem man einfach die Datendateien des
DB-Servers kopiert, denn während des Kopiervorgangs werden diese
i.d.R. bereits wieder verändert, so dass die Kopie inkonsistent wird
und im schlimmsten Fall nur noch aus Datenmüll besteht. Große
DB-Server treiben einen nicht unerheblichen Aufwand, um dieses Problem
zu lösen, so einfach, wie Volker das suggerierte, ist es nicht.
Im Fall von MacOS wäre ich da aber etwas wagemutiger. SQLite ist IIRC
relativ harmlos. Dateien, die nur zum Lesen geöffnet werden, werden
IIRC nicht geändert und damit können keine Inkonsistenzen
entstehen. Auch beispielsweise bei LOG-Dateien ist das Schadpotenzial
überschaubar (na ja, dann fehlt vielleicht mal eine Zeile oder ist
nicht ganz vollständig, aber daran stirbt das Backup nicht
unbedingt). Ich habe das nicht wirklich analysiert, aber so
gefühlsmäßig würde ich sagen, ein ruhendes MacOS (keine aktiven
Programme außer SuperDuper) sollte eigentlich nicht viel zu schreiben
haben (und mein IO Anzeiger ist, wenn man MacOS nichts passiert, auch
längere Zeit ruhig).
Und außerdem kann man selbst bei vorhandenen Schreiboperationen auch
immer noch Glück haben, dass das Timing gerade stimmte und keine
Inkonsistenz verursacht wurde. :)
Insofern hat man mit dem Ansatz, alle Programme außer SuperDuper zu
schließen, ein wenig zu warten und dann zu klonen schon brauchbare
Chancen auf einen Klon, der sogar komplett konsistent sein kann oder
nur minimale und verschmerzbare Inkonsistenzen aufweist.
Aber wer auf Nummer Sicher gehen will, sollte unbedingt Thomas
Ratschlag beherzigen und von einer anderen Platte booten, um vom
System einen Klon zu ziehen.
Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
--
Stefan.
Volker Birk
> Große
> DB-Server treiben einen nicht unerheblichen Aufwand, um dieses Problem
> zu lösen, so einfach, wie Volker das suggerierte, ist es nicht.
Doch, genau so "einfach" (oder vielmehr gar nicht so einfach), wie
Volker es "suggerierte", ist es.
Wenn die Datenbank ACID-Kriterien erfüllt (SQLite lässt das zu) und die
Betreffende Software das korrekt nutzt (keine Ahnung, ob MacOS da in
allen Teilen korrekt implementiert ist), dann ist das genau so einfach.
Dann gibt es nämlich keine unauflösbaren Zustände auf Blockebene, und
man kann jederzeit einen Snapshot ziehen. Dazu hält man schreibende
Prozesse übrigens an, und lässt sie danach weiterlaufen.
Einen brauchbaren Einblick gibt die englische Wikipedia-Homepage zum Thema:
https://secure.wikimedia.org/wikipedia/en/wiki/Snapshot_%28computer_storage%29
MartinC
> Ach ja, TimeMachine hat nat�rlich prinzipiell dasselbe Problem!
Nur "prinzipiell", oder schlicht und einfach: dasselbe Problem?
Der h�ndische Ansatz mit SuperDuper oder CCC h�tte ja (bei allen
theoretischen und tats�chlichen Nachteilen) den Vorteil, da� man das Risiko
selbst in der Hand hat, und durch Ma�nahmen begrenzen kann.
Alle Programme au�er SD/CCC beenden = "hohe" Klongenauigkeit.
Von anderem Startvolume booten = "noch h�here" Klonggenauigkeit.
TimeMachine (bzw. jede nicht manuell angeschubste Kopie) die das laufende
System kopiert, macht das aber naturgem�� zu Zeitpunkten, die der Nutzer
nicht ausgesucht hat. Das ist ja auch grade - wenn ich die Diskussionen hier
richtig verstanden habe - das FEATURE. "Schalte TimeMachine ein, und k�mmer
Dich nie mehr darum. Selber Backup machen ist nix, das vergi�t Du fr�her
oder sp�ter. Also nimm TimeMachine und vergi� dann TimeMachine". So in der
Art.
L�uft man dann nicht Gefahr, da� man z.B. bei einer Datenbank, die laufend
ge�ffnet ist und laufend tempor�re �nderungen durchf�hrt, am Ende bei
TimeMachine gef�hlte 200 alte Versionen hat, die *alle* inkonsistent sind?
Ist nicht polemisch gemeint, das w�rde mich tats�chlich interessieren, ob
das nur ein theoretisches Problem ist (also ignorierbar, weil zu sehr
unwahrscheinlich) oder real.
Thomas Kaiser
> Ralph A. Schmid, dk5ras <ra...@radio-link.net> wrote:
>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>
>> >Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen
>> >es denn eine gerade geöffnete Datenbank wegsichern? Und derer gibt
>>
>> Warum soll das nicht gehen? Unter Windows gibt es auch den Volume
>> ermöglicht, dann wird der Mac das ja wohl auch können?!
Jaja, ich hab die Ironie schon verstanden. Aber am Mac u.v.a. in HFS+
ist da erstmal weit und breit nix mit echten Snapshots. Das ist ein
Feature, das wir evtl. in 10.8 als Teil von CoreStorage sehen werden.
Wen Details interessieren, was CoreStorage ist (neu mit 10.7). Jon
Siracusa hat wie üblich die Antwort:
http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/13#lion-file-system
> Außerdem, würde ich mich dann fragen (steinigt mich, wenn das Quatsch
> sein sollte), warum TimeMachine das denn dann besser machen sollte,
> bspw. eine "gerade geöffnete Datenbank wegsichern"?
Das hat mehrere Gründe:
Zum einen sichert TimeMachine manche dieser systemweiten Datenbanken gar
nicht erst mit. Heißt: Nach einem Restore fehlt dann bspw. die
Font-Datenbank oder die Spotlight-Indizes und werden automatisch neu
aufgebaut (das ist ja das wirklich Zeitraubende an einem TimeMachine-
Restore: Daß der erste Neustart nach einem Restore Reindizierungsorgien
anstehen). Aber keine dieser Datenbanken können inkonsistent sein und
somit Probleme verursachen. Jeder Klon-Apologet darf sich nun selbst
überlegen, was er gerne lieber hätte.
Dann geht TimeMachine so vor, daß es alle geöffneten Dateien, die es
während des ersten Laufs antrifft, in einer Liste vermerkt. Wenn der
TM-Lauf durch ist, wird sofort via des fsevents(d)-Mechanismus
nachgeschaut, welche Dateien sich während des direkt zuvor laufenden
Sicherungsvorgangs geändert hatten und dann wird versucht nochmal diese
neuen und die vorher geöffneten Dateien wegzusichern (in den selben
Sicherungsordner wie die direkt zuvor durchgeführte Sicherung). Wenn das
auch im zweiten Durchlauf nicht gelingt, wird das im Log vermerkt (je
Sicherungsordner). Der User kriegt aber nix davon mit, wohl weil sich
die TM-Macher gedacht haben: Na und? Klappt's halt nächste Stunde.
Wenn man Pech hat, bspw. weil man rund um die Uhr fette Datenbanken
laufen hat (wie ich bspw.), dann landen die nie in einem konsistenten
Zustand im Backup. Da muß man dann andere Strategien fahren bspw. den
Pfad zu den Datenbanken gleich ganz ausklammern und $irgendwie anders
sichern (bei Cumulus bspw. sinnvoll -- die geöffneten Datenbanken kriegt
man nie in einem konsitenten Zustand in ein Backup, dafür macht die
Bilddatenbank selbst Backup-Kopien per Scheduler und die sind dann
konsistent). Oder bspw. ein Entourage explizit schließen und dann die
Mail-Datenbank wegsichern (was bin ich froh, daß dieses Gschiß mit
Outlook der Vergangenheit angehört)
Ab 10.7 und mit Anwendungen, die "Versions" unterstützen, ist das
Problem aus TimeMachine-Sicht natürlich aus der Welt, da Programme, die
das Versions-API unterstützen immer auch automatisch eine konsistente
Version der Datei ablegen. Mit 10.7 hat dann MacOS X auf der Ebene mit
Windows/NTFS und dem Shadow Copy Feature gleichgezogen, siehe "VSS
Writer" in:
http://de.wikipedia.org/wiki/Volume_Shadow_Copy_Service
Gruss,
Thomas
Volker Birk
> Läuft man dann nicht Gefahr, daß man z.B. bei einer Datenbank, die laufend
> geöffnet ist und laufend temporäre Änderungen durchführt, am Ende bei
> TimeMachine gefühlte 200 alte Versionen hat, die *alle* inkonsistent sind?
> Ist nicht polemisch gemeint, das würde mich tatsächlich interessieren, ob
> das nur ein theoretisches Problem ist (also ignorierbar, weil zu sehr
> unwahrscheinlich) oder real.
Es ist ein reales Problem. Damit eine Datenbank hierbei integer bleibt,
muss sie darauf ausgelegt sein. Du findest mehr dazu unter dem Begriff
"ACID-Kriterien", in diesem Falle betrifft es im Wesentlichen das "I" in
"ACID", das steht für "Isolation":
https://secure.wikimedia.org/wikipedia/en/wiki/ACID#Isolation
Die einschlägigen Artikel der englischen Wikipedia sind hier brauchbar.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen
>> im laufenden Betrieb außer falls SuperDuper zaubern könnte. Wie will
>> es denn eine gerade geöffnete Datenbank wegsichern?
>
> Wenn die Datenbank transaktionssicher implementiert ist, gibt es ja
> keine Zustände, die zu ihrer Zerstörung führen können. Da würde ich
> mir eher über andere Daten Gedanken machen.
>
> SQLite implementiert die dazu notwendigen Mittel, ich hoffe doch, dass
> die Leute bei Apple, die das Ding einsetzen, wissen was sie da tun.
Keine Ahnung, ob sie das tun. Ich hab jedenfalls Datenbanken (Cumulus)
mit denen das nicht geht (da läßt sich aber aus dem Programm selbst das
Erzeugen einer konsistenten Backup-Kopie triggern, die man dann
wegsichern kann -- heißt: Man muß sich für Spezialfälle individuelle
Überlegungen bzgl. Sicherung machen, weil weder Kloning im laufenden
Betrieb als auch TimeMachine in allen Spezialsituationen paßt).
Ich weiß nicht mehr, wieviele Jahre es her ist: Aber ich hab das damals
mehrfach en Detail untersucht, was bei Kloning im laufenden Betrieb
herauskommt. IIRC mit CCC und rsync Klone gezogen, direkt anschl. per
"rsync --dry-run" mir eine Liste aller Dateien erzeugen lassen, deren
Inhalt zwischen Klon und Original abweichte und die dann im Klon einzeln
geprüft. Bis auf einen Lauf war jedesmal was Fatales dabei, IIRC defekte
Dateien unterhalb /var/db/dslocal (viel Spaß, das ist die lokale
DirectoryServices-Datenbank) oder /Library/Preferences. Das reicht mir,
um das Thema erstmal zu den Akten zu legen und Kloning nur noch "auf
Nummer sicher" anzugehen.
Als ich dann TimeMachine näher angeguckt habe und mal mitschneiden hab
lassen, welche Dateien sich während eines Sicherungslaufs so alle
ändern, hat sich die Haltung bestätigt. Übrigens: Wer glaubt, auf seinem
Mac würde sich nichts tun, wenn kein einziges Programm offen ist:
Einfach mal fseventer runterladen, starten auf "Aufzeichen" klicken und
zuschauen, wie "ruhig" das in Wirklichkeit ist:
http://fernlightning.com/doku.php?id=software:fseventer:start
Ach ja, die Pro-Klon-Fraktion führt ja immer gerne aus, daß trotz all
der theoretischen Bedenken das Ganze "völlig problemlos" funktionieren
würde. Hab das vor über einem Jahr mal bei 'nem Kunden nachprüfen
können. Mac-Admin, den ich auf meine Bedenken, von ihrem Mini Server
kein Backup zu machen sondern im laufenden Betrieb auf eine externe
Platte zusuperdupern, angesprochen habe, meinte dann erwartungsgemäß
"Kein Problem, funktioniert astrein, schonmal getestet".
Anderen Mini von der Klonplatte gebootet: Triumphierendes Admin-Gesicht.
Gut, die Lüfter fingen kurz danach an, auf Hochtouren zu laufen. Ich hab
ihm dann gezeigt, warum es nicht verkehrt ist, ab und an ins system.log
zu schauen (bzw. eine Monitoring-Lösung das machen zu lassen). Ein
Prozeß crashte im Sekunden-Rhythmus. Und ein anderer belegte einen
CPU-Core exklusiv, weil er amoklief (und das war nicht die Folge dessen,
daß die wohlbekannte Zicke "MacOS X Server" in einem anderen Netzwerk
gebootet wurde). Inzwischen machen die dort tatsächlich Backup und der
Admin kann administrieren, weil geschult worden.
Kann sein, daß das alles immer nur tragische Einzelfälle waren. Mir
reicht's aber schon, um über ein stumpf-Kloning im laufenden Betrieb
nicht mehr nachzudenken. Es fehlen einfach nach wie vor die technischen
Voraussetzungen, die sowas 100% sauber umsetzbar machen würden. "No
risk, no fun" ist auch mein Motto in manchen Bereichen. "Datensicherung"
gehört aber nicht dazu.
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Yvonne Steiner schrieb:1
>> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> >
>> >> Yvonne Steiner schrieb
>> >> > Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> >> >> unter Lion?
>> >> >
>> >> > Um einen bootfähigen Klon zu erhalten.
>> >> > Den erstelle ich zusätzlich zum Backup mit Time Machine (2 x
>> >>
>> >> Hmmm... nur so aus (ehrlichem) Interesse: Und wozu machst Du das?
>> >
>> > In erster Linie zur doppelten Sicherheit.
>>
>> Hmm... ich hab das nie verstanden, wie das gehen soll mit dem Klonen
>
> SuperDuper ist also das alleinige Programm, das währen des Klonens läuft.
Kennst Du "Dienstprogramme --> Aktivitätsanzeige"? Falls nicht, mach das
mal auf und stell sicher, daß rechts oben "Alle Prozesse" ausgewählt
ist. Dann siehst Du neben Deinem "alleinigen Programm" noch all die
anderen Prozesse, die parallel laufen. Wenn Du wissen willst, welche
Dateien geschrieben werden, obwohl "der Mac gar nix tut", dann hilft
fseventer, siehe Parallelposting.
> Keine Bange, mein Klon (per Superduper) *ist* ein exaktes Duplikat meiner
> int. Mac-HD auf einer ext. Firewire-HD.
Na gut, SuperSuper kann also doch zaubern. :-)
Und blöde Frage: Was macht Dich so sicher, daß das ein exaktes Duplikat
ist? Wirklich schon mal nachgeschaut, bspw. per "diff -r -a -q"?
Gruss,
Thomas
Thomas Kaiser
> Insofern hat man mit dem Ansatz, alle Programme außer SuperDuper zu
> schließen, ein wenig zu warten und dann zu klonen schon brauchbare
> Chancen auf einen Klon, der sogar komplett konsistent sein kann oder
> nur minimale und verschmerzbare Inkonsistenzen aufweist.
Yep. Aber wenn man den Mac in der Zeit eh nicht nutzt, könnte man auch
gleich von anderem Medium neustarten und dann den Klon in einem wirklich
konsistenten Zustand anstubsen. Das Festplatten-Dienstprogramm kennt
leider keinen inkrementellen Modus wie in CCC oder auch SuperDuper
anbieten. Dafür beherrscht es "block level"-Klone, was gerade auf
Dateisystemen mit irrwitzig vielen kleinen Dateien (AKA Systempartition
mit MacOS X drauf) deutlich schneller als "file level"-Kloning geht. In
Summe dürfte es aber länger dauern als der inkrementelle Ansatz.
Heißt: DasBoot [1] mit CCC drauf auf eine separate Partition wäre eine
sinnige Ausgangsbasis für wirklich 100% konsistente Klone. Leider hat
Apple in das BaseSystem.dmg, das auf Lions Recovery Partition residiert,
kein rsync eingebaut. Das wäre auch noch ein netter Ansatz gewesen. Aber
ich denke, es wird eh nicht lange dauern, bis die ersten Tüftler merken,
daß man BaseSystem.dmg auch bisserl pimpen kann und dann wird die
Recovery Partition auch für nicht Kommandozeilen-Artisten zu einem noch
mächtigeren Werkzeug.
> Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
Nö, weil es bei Sicherungen 'ne Menge, das potentiell inkonsistent sein
könnte, gleich von vorneherein ausspart (siehe Spotlight-Reindizierungs-
Gerödel nach Komplett-Restore) und weil es mehrstufig vorgeht, um zum
Zeitpunkt des ersten Sicherungslaufs geöffnete Dateien anschl. in
konsistentem Zustand zu erwischen.
Gruss,
Thomas
Thomas Kaiser
> TimeMachine (bzw. jede nicht manuell angeschubste Kopie) die das
> Diskussionen hier richtig verstanden habe - das FEATURE. "Schalte
> ist nix, das vergißt Du früher oder später. Also nimm TimeMachine und
> vergiß dann TimeMachine". So in der Art.
>
> Läuft man dann nicht Gefahr, daß man z.B. bei einer Datenbank, die
> laufend geöffnet ist und laufend temporäre Änderungen durchführt, am
> Ende bei TimeMachine gefühlte 200 alte Versionen hat, die *alle*
> inkonsistent sind?
Das wäre die eine Variante, die andere, daß man Gefahr läuft, daß man
gar keine Sicherung davon hat, weil TM die Datei nie in einem
sicherungswürdigen Zustand antrifft und heimlich, still und leise
jedesmal ausläßt (das betraf meine Entourage-Datenbank früher, die wurde
nur gesichert, wenn ich Entourage beendet hatte. Nach irgendeinem Update
wurde dann jedesmal der 4 GByte-Brocken als neue Version auf die
TM-Platte geklatscht. Abhilfe: Entourage-DB von der Sicherung
ausgenommen und ein Skript darum kümmern lassen: Hat Entourage beendet,
eine Version der letzten Sicherung durch Duplizieren erzeugt, die
älteren gesicherten Versionen durchrotiert und dann per rsync die
letzten Änderungen weggesichert. Häßlich viel Platzverbrauch aber
wenigstens eine tägliche Sicherung. Für einen Kunden haben wir das Ganze
auch netzwerkweit so ähnlich umgesetzt)
Gruss,
Thomas
Volker Birk
>> SQLite implementiert die dazu notwendigen Mittel, ich hoffe doch, dass
>> die Leute bei Apple, die das Ding einsetzen, wissen was sie da tun.
> Keine Ahnung, ob sie das tun. Ich hab jedenfalls Datenbanken (Cumulus)
> mit denen das nicht geht (da läßt sich aber aus dem Programm selbst das
> Erzeugen einer konsistenten Backup-Kopie triggern, die man dann
> wegsichern kann -- heißt: Man muß sich für Spezialfälle individuelle
> Überlegungen bzgl. Sicherung machen, weil weder Kloning im laufenden
> Betrieb als auch TimeMachine in allen Spezialsituationen paßt).
Klar.
> Ich weiß nicht mehr, wieviele Jahre es her ist: Aber ich hab das damals
> mehrfach en Detail untersucht, was bei Kloning im laufenden Betrieb
> herauskommt. IIRC mit CCC und rsync Klone gezogen
Geklont wird blockweise, nicht mit rsync. Zudem muss man während dem
Klonen schreibende Prozesse anhalten. Darüber hinaus muss alle Software
den notwendigen Integritätslevel implementieren.
Alternativ kann man virtuelle Maschinen klonen, das geht auch ohne
Softwareunterstützung "innen": man hält die Maschine an und speichert
den vollständigen Betriebszustand.
> Ich hab
> ihm dann gezeigt, warum es nicht verkehrt ist, ab und an ins system.log
> zu schauen
Du hast einem Admin erklären müssen, warum es sinnvoll ist, Logbücher zu
lesen? Mein Beileid!
Volker Birk
> Das wäre die eine Variante, die andere, daß man Gefahr läuft, daß man
> gar keine Sicherung davon hat, weil TM die Datei nie in einem
> sicherungswürdigen Zustand antrifft und heimlich, still und leise
> jedesmal ausläßt
Man sollte vielleicht hinzufügen:
Ich verwende nicht nur TimeMachine, sondern auch FileVault. Und das
zwingt einen, während der Sicherung ausgeloggt zu sein. Das ist in
diesem Falle durchaus ein Vorteil: denn so ist alles gesichert, was ich
zum Arbyten brauche.
Thomas Kaiser
> Geklont wird blockweise, nicht mit rsync. Zudem muss man während dem
> Klonen schreibende Prozesse anhalten. Darüber hinaus muss alle Software
> den notwendigen Integritätslevel implementieren.
LOL, ja genau, das ist die Diskrepanz zwischen dem, wie "man's" machen
sollte und dem wie es die "üblichen Verdächtigen" am Mac machen. Wobei
man der Fairness halber dazu sagen muß, daß die (also CCC und
SuperDuper) wohl inzwischen auch so ihre Vorkehrungen betreiben, um
konsistente Klone wahrscheinlicher zu machen.
> Du hast einem Admin erklären müssen, warum es sinnvoll ist, Logbücher
> zu lesen? Mein Beileid!
Das ist bei dem Gros der Mac-Admins, die mir in den letzten 15 Jahren
über den Weg gelaufen sind, völlig normal. Wenn's irgendwo bei 'nem User
klemmt, ziehen die sich das Voodoo-Priester-Röckchen über, holen ein
Hühnchen, warten bis Vollmond und dann das volle Programm:
"Parameter-RAM zappen" (früher) bzw. "Rechte Reparieren" (heute), ein
bisschen mit Onyx herumklicken hier, ein wenig mit Tinkertool verstellen
dort, und wenn alles nichts geholfen hat, dann wird die Kiste halt
"plattgemacht". Dazu viel Hühnerblut verspritzen, rituelle Gesänge und
gegen den Uhrzeigersinn um den Mac herumtanzen.
Ich frag meistens schon gar nicht mehr, warum sie nicht zur Abwechslung
mal einfach das Problem an sich zu analysieren versuchen. Die Antworten
fallen dann... immer... irgendwie... ach, lassen wir das. Tischkanten
schmecken einfach scheiße.
Gruss,
Thomas
Albin
>
> Insofern hat man mit dem Ansatz, alle Programme au�er SuperDuper zu
> schlie�en, ein wenig zu warten und dann zu klonen schon brauchbare
> Chancen auf einen Klon, der sogar komplett konsistent sein kann oder
> nur minimale und verschmerzbare Inkonsistenzen aufweist.
Ich weiss nicht, ob dies mit dem urspruenglichen (meinem) Problem etwas zu tun
haben koennte.
Shirt Pocket schreibt:
"And my point is that a user-level program such as SuperDuper! *CANNOT* lock up
your system. The problem is actually occurring in OSX's kernel, in the I/O
subsystem. That's blocking us and Finder and your system."
Ich kenne das so:
Ein Programm kann eine Datei nicht lesen und sagt es.
Es bleibt nicht haengen und laehmt nicht das OS incl. Finder.
Ich bin kein Programmierer wie er, aber ich glaube ihm nicht.
Gruss
Peter
Thomas Kaiser
> Stefan Nobis <sno...@gmx.de> schrieb:
>>
>> Insofern hat man mit dem Ansatz, alle Programme außer SuperDuper zu
>> schließen, ein wenig zu warten und dann zu klonen schon brauchbare
>> nur minimale und verschmerzbare Inkonsistenzen aufweist.
>
> Ich weiss nicht, ob dies mit dem urspruenglichen (meinem) Problem
> etwas zu tun haben koennte.
>
> Shirt Pocket schreibt: "And my point is that a user-level program such
> as SuperDuper! *CANNOT* lock up your system. The problem is actually
> occurring in OSX's kernel, in the I/O subsystem. That's blocking us
> and Finder and your system."
>
> Ich kenne das so:
> Ein Programm kann eine Datei nicht lesen und sagt es.
> Es bleibt nicht haengen und laehmt nicht das OS incl. Finder.
Er beschreibt ganz klar was anderes: SuperSuper als Programm ist nicht
in der Lage, das System komplett einfrieren zu lassen sondern das
passiert wenn dann eine Ebene tiefer auf Kernel-Ebene im I/O-Subsystem.
Und wenn dort alles hängt, hängen Prozesse, die grad I/O spielen wollen
(Finder, SuperDuper), ebenfalls.
Ohne Eure Konversation vollständig vorliegen zu haben, kann man aber
kaum sagen, warum er das hervorhebt und was er Dir damit sagen will.
Gruss,
Thomas
Volker Birk
> Tischkanten
> schmecken einfach scheiße.
Etwas Senf? ;-)
Thomas Kaiser
> Das wäre die eine Variante, die andere, daß man Gefahr läuft, daß man
> gar keine Sicherung davon hat, weil TM die Datei nie in einem
> sicherungswürdigen Zustand antrifft und heimlich, still und leise
> jedesmal ausläßt
So, bin jetzt wieder in der Nähe meiner TM-Sicherungen und hab mal
nachgeschaut. Erste Korrektur: TimeMachine versucht sogar zweimal direkt
nacheinander geöffnete Dateien in einem konsistenten Zustand
anzutreffen. Und erst wenn das nicht klappt, wird aufgegeben. Und das
Ganze passiert häufiger als man denkt.
Je Sicherungsordner gibt es ein ".Backup.log", aus dem IMO klar genug
hervorgeht, was TM da je konkretem Sicherungslauf macht und warum es
ggf. noch zweimal nachfaßt. Da hab ich mal drin suchen lassen:
cd /Volumes/TM-Schraddel/Backups.backupdb/macbookpro-tk
find . -name ".Backup.log" -maxdepth 2 | while read ; do grep -q "Still busy after 2 retries" "${REPLY}" && dirname "${REPLY}"; done
./2010-12-12-221702
./2011-01-02-135234
./2011-01-23-215453
./2011-02-16-192059
./2011-03-09-220636
./2011-03-27-121521
./2011-04-13-224154
./2011-04-28-231815
./2011-06-06-231601
./2011-06-18-122100
./2011-06-27-094425
./2011-07-11-192355
./2011-07-13-211958
./2011-07-27-103757
./2011-08-03-171903
Passiert also häufiger als man denkt -- in meinem konkreten Fall in 15
von insg. 21 Sicherungen auf dieser Platte (das ist mein Rotations-
Medium, das ca. einmal pro Woche an die Daten ran darf)
Gruss,
Thomas
Michael Tueller
Hier noch der HFS-Teil des Siracusa-Rants:
<http://dl.dropbox.com/u/4728895/siracusa.mp3>
Wahrscheinlich müssen die schon mal auf 'was anderes umsteigen.
Aber wir speichern ja eh bals alle unsere Daten direkt bei Apple;-)
Stefan Nobis
>> Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
> Nur "prinzipiell", oder schlicht und einfach: dasselbe Problem?
Na ja, ich bin mit den Details vom TM nicht richtig gut
vertraut. Soweit ich mich erinnere, können Programme sich quasi in TM
einklinken und so spezialiserte Backup-Routinen realiseren (damit sind
ja auch Objekt-Level Backups, also z.B. einzelne Kontakte im
Adressbuch, möglich).
Außerdem arbeitet TM auf Datei-Ebene, nicht auf Block-Ebene. Damit
hat TM grundsätzlich die Möglichkeit nachzusehen, ob eine Datei
geöffnet ist und geeignete Maßnahmen treffen. Wie Thomas in seiner
Gründlichkeit geprüft hat, nutzt TM diese prinzipielle Chance auch
wirklich aus.
Insofern erstmal nur prinzipiell dasselbe Problem. Im Einzelfall muss
man eben genauer hinsehen. Aber mittelfristig sieht's mit TM schon
ganz gut aus, sofern man das Backup zumindest gelegentlich auch
wirklich mal testet (z.B. einmal im Quartal ein Restore auf eine
externe Platte und zumindest Stichproben der wichtigsten Daten
und Anwendungen machen).
> Alle Programme außer SD/CCC beenden = "hohe" Klongenauigkeit.
Na ja, wie hoch das wirklich ist, kommt auf den Einzelfall an. Nur
weil man alle möglichen Programme beendet, heißt das ja nicht, dass da
nicht evtl. noch irgendwelche Prozesse des Programms im Hintergrund
laufen, die evtl stören könnten. Und vor dem Hintergrund Lion wird das
alles noch mal etwas wackeliger.
Also wenn man sich schon Sorgen um die Konsistenz macht, dann nur so:
> Von anderem Startvolume booten = "noch höhere" Klonggenauigkeit.
Der einzige Weg (unter den gegebenen Voraussetzungen, also MacOS, HFS+
etc), Konsistenz zu garantieren. Alternativ müsste das Betriebssystem
resp. Dateisystem entsprechende Features bieten (siehe ZFS und Btrfs).
--
Stefan.
Frank Reutter
> Passiert also h�ufiger als man denkt -- in meinem konkreten Fall in 15
> von insg. 21 Sicherungen auf dieser Platte
Was das 15x die selbe Datei?
Und was zeigt TM dem User, der in den Sicherungen bl�ttert an der Stelle
der nicht gesicherten Datei? Die letzte gesicherte Version? Gar nix?
cu
f
--
...ausserdem halte ich verdunkelte Heckscheiben f�r antisozial und dumm.
Stefan Nobis
> Wenn die Datenbank ACID-Kriterien erfüllt (SQLite lässt das zu) und
> die Betreffende Software das korrekt nutzt (keine Ahnung, ob MacOS
> da in allen Teilen korrekt implementiert ist), dann ist das genau so
> einfach. Dann gibt es nämlich keine unauflösbaren Zustände auf
> Blockebene, und man kann jederzeit einen Snapshot ziehen.
Hmmm... das ist schon eine Weile her, dass ich mich damit en Detail
beschäftigt habe, aber IIRC bezieht sich ACID erstmal überhaupt nicht
auf den physischen Level und noch viel weniger auf's
Dateisystem. Damit ist doch erstmal ausschließlich die logische Sicht
auf die Daten, also insbesondere das, was bei parallelen und folgenden
Abfragen herauskommt, gemeint. Mit ACID kann ich garantieren, dass
während mein UPDATE oder INSERT läuft, parallele SELECT Anfragen keine
Mischung aus alten und neuen Informationen liefern.
Ich bin mir ziemlich sicher, dass man z.B. bei Postgresql oder Oracle
durchaus inkonsistente Datendateien bekommen kann, wenn man im genau
falschen Moment den Strom komplett abschneidet. Die machen schon auch
eine Menge im RAM und schreiben nicht immer alles sofort atomar auf
Platte -- das wäre vermutlich auch ein wenig arg lahm. Außerdem bin
ich mir gar nicht so sicher, dass man alles, was auf logischer Ebene
atomar abläuft auch wirklich auf physikalischer Ebene und insbesondere
auf Blockebene im Dateisystem atomar abbilden kann. IIRC haben (oder
zumindest hatten) die großen DBMS doch explizite Snapshot-Features
(d.h. für ein Backup konnte man explizit ein Snapshot anfordern). Und
selbst ein Isolation-Level SERIALIZABLE garantiert doch erstmal nur
DBMS interne Snapshots, die dann DBMS Tools für einen konsistenten
Dump nutzen können (sagt also noch nichts über die Blöcke auf der
Festplatte aus) - und ich kenne erstmal niemanden, der seine DBs
standardmäßig mit SERIALIZABLE fährt.
Falls ich da falsch liege oder meine Informationen schlicht überholt
sind, lasse ich mich aber gerne eines Besseren belehren (zumal ich mit
den Feinheiten moderner Ansätze wie MVCC nicht ganz so fitt bin).
Bei SQLite habe ich mich auch noch nicht so sehr mit den Innereien
beschäftigt. Es wäre also durchaus möglich, dass SQLite sogar
Atomizität auf Datei- und Blockebene garantiert. Aber aus dem ACID
Feature allein geht das eher nicht hervor.
> Dazu hält man schreibende Prozesse übrigens an, und lässt sie danach
> weiterlaufen.
Das ist beim Betriebssystem mitunter schwierig (und auch bei anderen
Programmen, die z.B. mit dauerhaften Hintergrundprozessen arbeiten,
nicht immer trivial). :)
Daher ja auch Thomas Hinweis, man solle von einem externen Medium
booten, um einen konsistenten Klon der Systempartition zu erstellen.
Oder man benötigt ein Dateisystem, das Snapshots unterstützt (das löst
zwar nicht zwangsläufig komplett alle Probleme, man ist dem Ziel aber
schon recht nah und in den meisten Fällen ist, evtl. mit einer paar
weiteren begleitenden Maßnahmen, dieser Ansatz völlig ausreichend).
> https://secure.wikimedia.org/wikipedia/en/wiki/Snapshot_%28computer_storage%29
Genau: Alles ausschalten oder Dateisysteme mit Snapshot-Funktion.
--
Stefan.
Stefan Nobis
>> Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
> Nö, weil es bei Sicherungen 'ne Menge, das potentiell inkonsistent
> sein könnte, gleich von vorneherein ausspart
Na ja, fehlende Dateien zähle ich jetzt nicht unbedingt in die
Kategorie konsistentes Backup. :)
Aber ich schrieb ja, TM hat prinzipiell dasselbe Problem. Es gibt sich
mehr Mühe und es gibt die Möglichkeit für Programme, sauber zu
kooperieren. Daher ist die Chance auf ein konsistentes Backup mit TM
schon höher als bei einem Klon im laufenden Betrieb. Aber
grundsätzlich löst TM das Snapshot-Problem auch nicht plötzlich
magisch auf. Deshalb warten wir ja weiter gespannt auf ZFS (resp. eine
entsprechende Alternative). :)
--
Stefan.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> writes:
>> [Stefan Nobis wrote:]
>>> Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
>
>> Nö, weil es bei Sicherungen 'ne Menge, das potentiell inkonsistent
>> sein könnte, gleich von vorneherein ausspart
>
> Na ja, fehlende Dateien zähle ich jetzt nicht unbedingt in die
> Kategorie konsistentes Backup. :)
Der Unterschied ist ganz simpel: TM läßt gewisse Sachen einfach aus:
Caches, Spotlight-Indizes und so Kram -- letztlich Sachen, die in
irgendeiner Form redundant sind und im Falle eines Komplett-Restores des
Systems auch (nahezu komplett) wiederherstellbar sind.
Heißt: Bei TM fehlt's komplett, was insofern ein konsistenter Zustand
ist, da durch Neuanlegen des Krams wieder ein sauberer Zustand
geschaffen wird.
Werden/würden solche Dateien allerdings durch einen Sync- oder
Klonvorgang am Ziel defekt ankommen, dann fliegt ein davon gebootetes
System oder nur einzelne Bestandteile wie irgendwelche Dienste halt auf
die Fresse, da nur mit den Zuständen "Keine Datei" (also neu anlegen)
oder "intakte Datei" (lesen/schreiben wie gehabt) richtig umgegangen
wird.
> Aber ich schrieb ja, TM hat prinzipiell dasselbe Problem. Es gibt sich
> mehr Mühe und es gibt die Möglichkeit für Programme, sauber zu
> kooperieren.
Jein, beim Backup schaut TM nur auf Dateien. Die Kooperations-
Möglichkeiten seitens Anwendungsprogrammen finden sich auf der Restore-
Seite wieder. Heißt: Du kannst ins Adreßbuch wechseln, von dort
TimeMachine starten und nun kannst Du innerhalb alter, d.h. ggf.
zwischenzeitlich geänderter oder gelöschter _Kontakte_ herumsuchen. Du
suchst nicht nach Dateien, die Kontaktdaten enthalten, sondern Du suchst
nach Personen bzw. Daten, die an der Person kleben, bspw. Name "Lieschen
Müller".
D.h. Du bist nicht wie bei einem primitivem Backup-Programm (z.B.
Retrospect) oder dem Klon-Ansatz dazu verdammt, Dich mit den Interna der
SyncServices auszukennen bzw. wo verdammt nochmal im Dateisystems die
entsprechenden "Proxy-Dateien" stecken, in denen die Kontaktdaten der
Person drinstecken, deren alte Adresse man grad sucht. Sondern bedingt
dadurch, daß TM ein Objekt-API anbietet, suchts Du in alten Backups
völlig abstrahiert vom physischen Speicherort der eigentlichen Daten
bzw. deren Format. Dito funktioniert der Restore so, daß Du Dir keine
Gedanken darüber machen mußt, wo da was zurückgesichert wird, sondern Du
holst halt die alte Version in genau der Fassung zurück, in der Du sie
brauchst. Heißt: Lieschen Müllers Kontaktdaten in der Fassung vom
1.1.2011 mögen vielleicht in
~/Library/Application Support/AddressBook/Metadata/0FDD851D-143A-4DE2-A1AA-A7FDDD296E3B:ABPerson.abcdp
gespeichert gewesen sein und wenn Du jetzt diese Fassung in TM haben
willst, dann wird beim Restore der aktuelle Datensatz von Lieschen
Müller, d.h. bspw. die Datei
13D96EC0-B952-4161-BA45-A4121BBB7976:ABPerson.abcdp
gelöscht und es entsteht ein neue Datei
2100364B-0D72-4561-907F-D2F8DCE8EA7D:ABPerson.abcdp
die die alten Kontaktdaten von Lieschen enthält. Aber das kann Dir alles
herzlich egal sein, da Adreßbuch und TimeMachine zusammenarbeiten und
diesen ganzen physischen Ablagequatsch, dito das eigentliche Format der
Daten vor Dir abstrahieren. Dito z.B. Mail.app (das eh das bessere
Beispiel wäre, weil die TM-Integration im Adreßbuch etwas buggy ist --
aber da ich kein Mail.app nutze, halt ich diesbzgl. auch lieber die
Klappe)
Diese Objektorientiertheit, was die Suche und den Restore von Daten
angeht, ist ja eigentlich das Schönste an TimeMachine. Und zugleich das,
was die wenigstens kapieren.
> Daher ist die Chance auf ein konsistentes Backup mit TM schon höher
> als bei einem Klon im laufenden Betrieb. Aber grundsätzlich löst TM
> das Snapshot-Problem auch nicht plötzlich magisch auf. Deshalb warten
> wir ja weiter gespannt auf ZFS (resp. eine entsprechende Alternative).
Wie schon geschrieben: Das Versions-Feature in 10.7, so denn vom
entsprechenden Programm unterstützt, könnte hier das Bindeglied zu einer
stets konsistenten Version in der TimeMachine-Sicherung sein. Hab ich
mir aber noch nicht angeschaut, wie das konkret implementiert ist.
Gruss,
Thomas
Thomas Kaiser
>
> Hier noch der HFS-Teil des Siracusa-Rants:
>
><http://dl.dropbox.com/u/4728895/siracusa.mp3>
>
> Wahrscheinlich müssen die schon mal auf 'was anderes umsteigen.
Jon Siracusa sieht ja in CoreStorage in 10.7 die zarten Triebe eines
neuen Dateisystems, das aus Apples eigener Züchtung stammt:
http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/13#lion-file-system
Gruss,
Thomas
Thomas Kaiser
> MartinC <nor...@nospam.invalid> writes:
>
>>> Ach ja, TimeMachine hat natürlich prinzipiell dasselbe Problem!
>
>> Nur "prinzipiell", oder schlicht und einfach: dasselbe Problem?
>
> Na ja, ich bin mit den Details vom TM nicht richtig gut vertraut.
> Soweit ich mich erinnere, können Programme sich quasi in TM einklinken
> und so spezialiserte Backup-Routinen realiseren (damit sind ja auch
> Objekt-Level Backups, also z.B. einzelne Kontakte im Adressbuch,
> möglich).
Nein, an der Stelle "Backup" ist die TM-Konformität einfach nur: Es muß
eine einzelne Datei sein. Bzw. wo das aus irgendwelchen Gründen nicht
geht, können sog. Proxy-Dateien an deren Stelle treten. So hat bspw.
Entourage zwar immer alles in einer monolithischen Datenbank, erzeugt
aber seit irgendeinem Update auch noch entsprechende Proxy-Dateien für
jede Mail und jeden Kontakt unterhalb
~/Library/Caches/Metadata/
(im Falle Entourage also faktische Verdopplung des Speicherbedarfs, weil
sowohl alles in Datenbank steckt als auch in einzelnen Dateien im
Filesystem). Das machen aber manche Apple-Programme genauso. Kontakte
verstaut das SyncServices-Framework einmal intern und legt sie parallel
noch unterhalb
~/Library/Application Support/AddressBook/Metadata/
ab. Termine landen auch noch als Proxy-Dateien in
~/Library/Caches/Metadata/iCal/
usw. usf. Das ist nicht nur für Spotlight wichtig sondern auch im
Kontext TimeMachine und zwar, wenn's an den Restore geht. Dann kann
innerhalb des Programms, wenn es an die TM-API andockt, auf Objekt- und
nicht Dateisystem-Ebene nach Sachen gesucht werden. Nutzen nur leider
die wenigsten Programme...
> Außerdem arbeitet TM auf Datei-Ebene, nicht auf Block-Ebene.
SuperDuper und CCC in dem Modus, wie ihn die "Kloner" benutzen, macht
das aber genauso. Das, was da entstehen soll, ist ein stets frischer
Klon. Aber entstehen tut der per Sync, wenn man's mit der Wortklauberei
wirklich ernst nehmen will ;-)
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Passiert also häufiger als man denkt -- in meinem konkreten Fall in
>
> Was das 15x die selbe Datei?
Keine Ahnung. Im Log steht ja nur lakonisch:
Some filesystem changes made during the course of the backup may not
be accounted for. Still busy after 2 retries.
> Und was zeigt TM dem User, der in den Sicherungen blättert an der
> Stelle der nicht gesicherten Datei? Die letzte gesicherte Version? Gar
> nix?
Keine Ahnung, hab nie konkret nachgeschaut. Kannst' Dich ja selbst mal
auf die Suche machen. Im .Backup.log der letzten Sicherung nachgucken,
ob der Fall auftrat und dann als root ein
diff -r -a -q $src $dst
absetzen. Obacht, da fliegt Dir natürlich ein ganzer Schwall von
Abweichungen entgegen, einfach schon weil TM ganz schön viel nicht
mitsichert (siehe bspw. [1]). Insofern etwas mühselig, herauszufinden,
was konkret betroffen war ;-)
Gruss,
Thomas
[1] http://groups.google.com/group/de.comp.sys.mac.misc/msg/8535949917025eae
Volker Birk
> Hmmm... das ist schon eine Weile her, dass ich mich damit en Detail
> beschäftigt habe, aber IIRC bezieht sich ACID erstmal überhaupt nicht
> auf den physischen Level und noch viel weniger auf's
> Dateisystem.
Da liegst Du in einem gewissen Sinne gleich zweimal falsch.
Integritätslevel beziehen sich auch auf das, was Du vermutlich mit
"physischer Level" meinst, Dateisysteme haben dasselbe Problem, denn sie
sind schlicht hierarchische Datenbanken.
> Ich bin mir ziemlich sicher, dass man z.B. bei Postgresql oder Oracle
> durchaus inkonsistente Datendateien bekommen kann, wenn man im genau
> falschen Moment den Strom komplett abschneidet.
Wenn man sie falsch betreibt, sicher. Denn wie ist "konsistent" im
Einzelfalle konkret gemeint?
> eine Menge im RAM und schreiben nicht immer alles sofort atomar auf
> Platte -- das wäre vermutlich auch ein wenig arg lahm.
Atomarität ist das "A" in "ACID", übrigens.
> Außerdem bin
> ich mir gar nicht so sicher, dass man alles, was auf logischer Ebene
> atomar abläuft auch wirklich auf physikalischer Ebene und insbesondere
> auf Blockebene im Dateisystem atomar abbilden kann. IIRC haben (oder
> zumindest hatten) die großen DBMS doch explizite Snapshot-Features
> (d.h. für ein Backup konnte man explizit ein Snapshot anfordern). Und
> selbst ein Isolation-Level SERIALIZABLE garantiert doch erstmal nur
> DBMS interne Snapshots, die dann DBMS Tools für einen konsistenten
> Dump nutzen können (sagt also noch nichts über die Blöcke auf der
> Festplatte aus) - und ich kenne erstmal niemanden, der seine DBs
> standardmäßig mit SERIALIZABLE fährt.
Tatsächlich ist es ein Unterschied, ob das blockweise Abbild einer
Datenbank immer integer ist, oder ob SERIALIZABLE das für
Dump-Befehle garantiert.
Dass das blockweise Abbild aber immer zumindest eine Rückführung auf
einen konsistenten Zustand zulässt, und somit jedes geschriebene
blockweise Abbild integer ist, das ist eine Forderung an transaktions-
sichere Datenbanken. Wer diese Forderung erfüllt, kann durch Absturz
keine kaputten Daten mehr erwirken. Und das war deshalb die Forderung,
die ich gestellt hatte.
Sowohl mit Oracle, als auch mit Microsoft SQL Server, als auch mit
PostgreSQL und sogar mit SQLite ist das hinzukriegen, wenn man das
richtig macht.
>> Dazu hält man schreibende Prozesse übrigens an, und lässt sie danach
>> weiterlaufen.
> Das ist beim Betriebssystem mitunter schwierig (und auch bei anderen
> Programmen, die z.B. mit dauerhaften Hintergrundprozessen arbeiten,
> nicht immer trivial). :)
Solange es Prozesse sind, ist es auf einem UNIX-artigen Betriebssystem
immer trivial zu machen: man schickt SIGSTOP. Es ist für Kernel-Threads
nicht einfach hinzukriegen.
> Daher ja auch Thomas Hinweis, man solle von einem externen Medium
> booten, um einen konsistenten Klon der Systempartition zu erstellen.
Das ist das einfachste. Aber es ist ja auch kein Online-Snapshot,
sondern ein Offline-Snapshot. Und die sind trivial. Blockkopie, fertig.
> Oder man benötigt ein Dateisystem, das Snapshots unterstützt (das löst
> zwar nicht zwangsläufig komplett alle Probleme, man ist dem Ziel aber
> schon recht nah und in den meisten Fällen ist, evtl. mit einer paar
> weiteren begleitenden Maßnahmen, dieser Ansatz völlig ausreichend).
Es löst gar keine der besprochenen Probleme, die über die Konsistenz des
Dateisystems hinausgehen. Man könnte auch sagen, es löst keinerlei
Konsistenzprobleme, was die Inhalte der Dateien angeht.
Volker Birk
> Die Datenbank kommt halt wieder hoch, bemerkt den unsauberen Zustand
> und macht ein Logreplay und versucht zu retten, was zu retten ist.
Und wenn die notwendigen Kriterien erfüllt sind, führt das
garantiert zu einem konsistenten Zustand. "Was zu retten ist" klingt
nach "es ist nicht alles zu retten". Und das klingt nach "die Datenbank
unterstützt nicht die notwendien ACID-Kriterien".
;-) Um hier mal den Thomas zu geben: Nicht dass ich es nicht gewohnt
wäre, solche Datenbanken auch 2011 noch an relevanten Stellen
vorzufinden, weil weder Software-Designer noch DBAs die Sache
durchschauen.
Volker Birk
> Volker Birk <bum...@dingens.org> schrieb:
>> "Was zu retten ist" klingt nach "es ist nicht alles zu retten". Und
>> das klingt nach "die Datenbank unterstützt nicht die notwendien
>> ACID-Kriterien".
Das bezweifle ich. Dazu beschäftige ich mich vermutlich ein, zwei
Jahrzehnte zu lange mit dem Thema, und habe auch schon zuviele eigene
Datenbank-Engines implementiert.
> Es garantiert Dir die Konsistenz
> innerhalb der Datenbank und das alles auf der Platte ist. Es heißt aber
> nicht, daß alles in einer einzigen Datei ist, die man mit einem Backup
> auf Block- oder Filesystemebene einfach mitnehmen kann.
Letzteres hab ich ja auch nicht behauptet. Aber ACID-Kriterien dienen
durchaus zur Herstellung von Transaktionssicherheit. Und da geht es
durchaus auch um die Robustheit, nicht nur um die Stabilität.
> Die Datenbank mag hinreichend atomar arbeiten und ACID erfüllen - das
> Backup ist aber kein atomarer Vorgang wenn mehrere Datenbankdateien im
> Spiel sind.
Du, bei "ACID" gibt es vier Buchstaben, da ist nicht nur ein "A". Und
ich sprach bereits davon, dass man schreibende Prozesse während einem
Snapshot anhalten sollte.
> Und keine ernsthafte Datenbank arbeitet heute noch nur mit Single Files
Ahem... Du hältst PostgreSQL nicht für "ernsthaft"? Nicht dass das was
mit "ACID" zu tun hätte, natürlich, ob die Datenbank direkt blockweise
ohne Dateisystem auf die Platte schreibt, oder ob da ein Dateisystem
dazwischen ist. Oder was meinst Du mit "Single Files"?
> und selbst dann, kann wie schon beschrieben noch z.B. noch das OS
> und Multitasking dazwischenfunken.
Wenn ein Prozess angehalten ist, so "funkt" da kein "Multitasking
dazwischen".
> Backup auf File- und Blockebene ist (nicht nur bei Datenbanken) immer
> automatisch auch eine Race Condition
Nein. Nur wenn die Software die notwendigige Integrität auf Blockebene
nicht gewährleistet (was leider ganz schön viel Software tut).
> die einem irgendwann auch ins
> Gesicht springt, wenn man es gerade überhaupt nicht gebrauchen kann.
Das mag sein.
Volker Birk
>> Du, bei "ACID" gibt es vier Buchstaben, da ist nicht nur ein "A". Und
>> ich sprach bereits davon, dass man schreibende Prozesse während einem
>> Snapshot anhalten sollte.
> Moment, wo Du die Datenbank anhälst, sieht es anders aus und dann hast
> Du Recht. Dann muß eine Sicherung normalerweise klappen.
Übrigens: Deine Zweifel haben schon Gründe. Denn leider sind viele
Datenbanken nicht so implementiert, dass das klappen kann. Das geht bis
in die Anwendungsprogrammierung, damit das sauber klappt. Und da haperts
auch oft.
Albin
> Stefan Nobis <sno...@gmx.de> schrieb:
>>
>> Insofern hat man mit dem Ansatz, alle Programme außer SuperDuper zu
>> schließen, ein wenig zu warten und dann zu klonen schon brauchbare
>> Chancen auf einen Klon, der sogar komplett konsistent sein kann oder
>> nur minimale und verschmerzbare Inkonsistenzen aufweist.
>
> Ich weiss nicht, ob dies mit dem urspruenglichen (meinem) Problem etwas zu tun
> haben koennte.
>
> Shirt Pocket schreibt:
> "And my point is that a user-level program such as SuperDuper! *CANNOT* lock
up
> your system. The problem is actually occurring in OSX's kernel, in the I/O
> subsystem. That's blocking us and Finder and your system."
>
> Ich kenne das so:
> Ein Programm kann eine Datei nicht lesen und sagt es.
> Es bleibt nicht haengen und laehmt nicht das OS incl. Finder.
>
> Ich bin kein Programmierer wie er, aber ich glaube ihm nicht.
Inzwischen sichere ich seit 2 Wochen mit Carbon Copy Cloner - keine Probleme.
Noch eine Woche Probezeit, dann werde ich das Share bezahlen.
Peter