Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Time Machine: Warum fehlen Daten im Backup?
442 views
Skip to first unread message
Dirk Wagner
Nov 12, 2015, 2:44:57 PM11/12/15
to
Wie in <1mdshf0.2bp35x18plcleN%usenet...@diwasoft.de> geschrieben
vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen hatte
(die ich inzwischen aber aus einer anderen Sicherung wieder habe
herstellen können), sondern auch DAteien, die sich in Ordnern befanden,
die ich definitiv NICHT aus der Sicherung ausgeschlossen habe.
Konkret handelt es sich um Dateien und Ordner aus dem "Bilder" Ordner.
So ist die Katalogdatei von Media-Pro, die eigentlich wöchentlich
aktualisiert wurde NICHT im Backup - eine alte Version, die ich im
letzten Winter zuletzt gesichert habe ist aber da.
Ähnliches auch bei Unterordnern mit Bildern: Der Ordner mit den RAW
Dateien fehlt komplett, in anderen Ordnern fehlen teilweise Unterordner.
Mal einer, mal alle.
Mal sind es neue Ordner (z.B. Juni 2015), mal alte aus dem letzten Jahr
oder noch älter.
Ein Muster erschließt sich mir da nicht...
Gibt es einen Weg, sicher zu gehen, dass sowas nicht noch mal passiert?
Bisher hatte ich bei Restores aus TimeMachine noch keine Probleme, was
aber nur bedeutet, dass ich bisher immer nur die Dateien zurückholen
wollte, die auch gesichert waren...
Bilder wollte ich bisher noch keine zurückspielen ;-/
Ciao
dirk
vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen hatte
(die ich inzwischen aber aus einer anderen Sicherung wieder habe
herstellen können), sondern auch DAteien, die sich in Ordnern befanden,
die ich definitiv NICHT aus der Sicherung ausgeschlossen habe.
Konkret handelt es sich um Dateien und Ordner aus dem "Bilder" Ordner.
So ist die Katalogdatei von Media-Pro, die eigentlich wöchentlich
aktualisiert wurde NICHT im Backup - eine alte Version, die ich im
letzten Winter zuletzt gesichert habe ist aber da.
Ähnliches auch bei Unterordnern mit Bildern: Der Ordner mit den RAW
Dateien fehlt komplett, in anderen Ordnern fehlen teilweise Unterordner.
Mal einer, mal alle.
Mal sind es neue Ordner (z.B. Juni 2015), mal alte aus dem letzten Jahr
oder noch älter.
Ein Muster erschließt sich mir da nicht...
Gibt es einen Weg, sicher zu gehen, dass sowas nicht noch mal passiert?
Bisher hatte ich bei Restores aus TimeMachine noch keine Probleme, was
aber nur bedeutet, dass ich bisher immer nur die Dateien zurückholen
wollte, die auch gesichert waren...
Bilder wollte ich bisher noch keine zurückspielen ;-/
Ciao
dirk
Thomas Kaiser
Nov 12, 2015, 3:16:48 PM11/12/15
to
Dirk Wagner schrieb in <news:1mdsjut.rmho8j1fqn7x2N%usenet...@diwasoft.de>
Quelle größer Ziel war (immer verkehrt)? Und hast Du mal das Dateisystem
des TM-Mediums geprüft? Wenn ja, mit welchem Ergebnis?
TimeMachine arbeitete ja mit Verzeichnis-basierten Hardlinks (ein
Konzept, das es so gut wie nirgendwo anders gibt, weil man sich damit
ultraformidabel in den Fuß schießen kann). Da HFS+ elender Schrott aus
dem letzten Jahrtausend ist, wurde dieses Feature auch nur wieder
irgendwie abwärtskompatibel drangepappt (die Details findet Tante
Google, wenn man sie nach "timemachine jon siracusa hardlink half
million files" oder so befragt -- was man nicht tun sollte, wenn man zu
irrationalen Ängsten neigt, weil man TM dann anschließend nicht mehr
einsetzen will). Aber wenn da mal was schiefgeht, dann ist die Sicherung
halt maximal inkonsistent.
> Gibt es einen Weg, sicher zu gehen, dass sowas nicht noch mal
> passiert?
Hängt bisserl von der Antwort auf obige Frage ab.
Gruss,
Thomas, kann immer wieder nur dringend zu 2 rotierenden TM-Medien raten.
Eins gerne immer dranhängend, das andere ab und an und ansonsten sauber
verräumt.
> Wie in <1mdshf0.2bp35x18plcleN%usenet...@diwasoft.de> geschrieben
> vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
> Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen
> hatte (die ich inzwischen aber aus einer anderen Sicherung wieder habe
> herstellen können), sondern auch DAteien, die sich in Ordnern
> befanden, die ich definitiv NICHT aus der Sicherung ausgeschlossen
> habe.
Ich hab's nicht mehr ganz auf dem Schirm. Aber war das nicht so, dass
> vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
> Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen
> hatte (die ich inzwischen aber aus einer anderen Sicherung wieder habe
> herstellen können), sondern auch DAteien, die sich in Ordnern
> befanden, die ich definitiv NICHT aus der Sicherung ausgeschlossen
> habe.
Quelle größer Ziel war (immer verkehrt)? Und hast Du mal das Dateisystem
des TM-Mediums geprüft? Wenn ja, mit welchem Ergebnis?
TimeMachine arbeitete ja mit Verzeichnis-basierten Hardlinks (ein
Konzept, das es so gut wie nirgendwo anders gibt, weil man sich damit
ultraformidabel in den Fuß schießen kann). Da HFS+ elender Schrott aus
dem letzten Jahrtausend ist, wurde dieses Feature auch nur wieder
irgendwie abwärtskompatibel drangepappt (die Details findet Tante
Google, wenn man sie nach "timemachine jon siracusa hardlink half
million files" oder so befragt -- was man nicht tun sollte, wenn man zu
irrationalen Ängsten neigt, weil man TM dann anschließend nicht mehr
einsetzen will). Aber wenn da mal was schiefgeht, dann ist die Sicherung
halt maximal inkonsistent.
> Gibt es einen Weg, sicher zu gehen, dass sowas nicht noch mal
> passiert?
Gruss,
Thomas, kann immer wieder nur dringend zu 2 rotierenden TM-Medien raten.
Eins gerne immer dranhängend, das andere ab und an und ansonsten sauber
verräumt.
Dirk Wagner
Nov 12, 2015, 3:51:22 PM11/12/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ich hab's nicht mehr ganz auf dem Schirm. Aber war das nicht so, dass
> Quelle größer Ziel war (immer verkehrt)?
Quelle war größer als Ziel. Ja.
> Ich hab's nicht mehr ganz auf dem Schirm. Aber war das nicht so, dass
> Quelle größer Ziel war (immer verkehrt)?
Allerdings war die Quelle auch nur zu etwas mehr als 50% gefüllt, so
dass 3TB Backupmedium knapp 2TB Daten gegenüberstanden.
> Und hast Du mal das Dateisystem
> des TM-Mediums geprüft? Wenn ja, mit welchem Ergebnis?
"Die Partitionstabelle mus repariert werden, da ein Problem mit dem
Dateisystem der EFI-Systempartition aufgetreten ist"
Für das TM-Volume auf der Platte wurden keine Fehler gefunden...
>
> > Gibt es einen Weg, sicher zu gehen, dass sowas nicht noch mal
> > passiert?
>
> Hängt bisserl von der Antwort auf obige Frage ab.
Im Moment werden auf dem TM-Volume etwa 50% Belegung angezeigt.
Das sollte eigentlich ein wenig mehr sein...
Alternativ könnte ich auf den momentan nicht belegten 2TB am Mac
schauen, ob sich da noch Reste alter Dateien finden.
> kann immer wieder nur dringend zu 2 rotierenden TM-Medien raten.
> Eins gerne immer dranhängend, das andere ab und an und ansonsten sauber
> verräumt.
gleich aus...
Der Grundstock der alten Dateien ist der selbe...
Auch bei der dritten Platte, die schon länger nicht mehr aktiv war.
Inzwischen habe ich für das 3,5TB Fusion-Drive zwei 5TB TM-Laufwerke.
Doch mit DIESER Erfahrung jetzt, bin ich mir nicht mehr wirklich sicher,
ob ich mich (ausschließlich) darauf verlassen will.
Vor mehr als 10 Jahren hatte ich mein Backup noch mit Retrospekt auf
DLT-Bänder gemacht. Doch mit dem Einsatz von OS-X bin ich dann auf
TimeMachine gewechselt.
Bislang (d.h. bis zu meiner blöden Aktion vor 3 Wochen) schien das auch
auszureichen.
Ciao
dirk
Dirk Münster
Nov 12, 2015, 4:08:24 PM11/12/15
to
On 2015-11-12 19:44:55 +0000, Dirk Wagner said:
> Wie in <1mdshf0.2bp35x18plcleN%usenet...@diwasoft.de> geschrieben
> vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
> Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen hatte
> (die ich inzwischen aber aus einer anderen Sicherung wieder habe
> herstellen können), sondern auch DAteien, die sich in Ordnern befanden,
> die ich definitiv NICHT aus der Sicherung ausgeschlossen habe.
Jeder Mac-User sollte langsam begriffen haben, dass Apple keine
> Wie in <1mdshf0.2bp35x18plcleN%usenet...@diwasoft.de> geschrieben
> vermisse ich nach einem Komplett-Restore aus einem TM-Backup nicht nur
> Dateien, die ich dusseligerweise aus der Sicherung ausgeschlossen hatte
> (die ich inzwischen aber aus einer anderen Sicherung wieder habe
> herstellen können), sondern auch DAteien, die sich in Ordnern befanden,
> die ich definitiv NICHT aus der Sicherung ausgeschlossen habe.
Software machen kann. Vertraue Apple keine Daten an! Nimm stattdessen
SuperDuper oder CarbonCopyCloner und klone Deine Harddisk 1:1 auf eine
externe Platte. Da weißt Du, daß Du 100 % jede Datei gesichert hast.
TimeMachine ist ein unberechenbares Apple-Spielzeug. Sowas nimmt man
nur, wen einem die eigenen Daten nichts wert sind. Das betrifft alle
"Sondersoftware" von Apple. Kompatibilität: null, Standards-Compliance:
null, Datenverlust: fest eingebaut. Solcher Apple-Schrott ist auch
Pages, Keynote, Numbers. Apple packt's nicht. Nur eine schöne
Oberfläche. Langzeitsicherheit: null. Langzeitvertrauen: null. Wieviel
Apple-Software ist schon gekommen und gegangen? Da hat man heute die
Dateien, kann sie aber nicht mehr öffnen.
Dirk
Thomas Kaiser
Nov 12, 2015, 4:57:07 PM11/12/15
to
Dirk Münster schrieb in <news:n22v43$sve$1...@speranza.aioe.org>
ausschließlich auf den verläßt, bist Du halt einfach nur dämlich, weil
mit Backup hat das -- im Gegensatz zu TimeMachine -- halt nunmal genau
gar nichts zu tun :-)
> TimeMachine ist ein unberechenbares Apple-Spielzeug.
Genau. Und ich mach mich zum Trottel, weil ich dem Troll antworte. :-)
Gut' Nacht,
Thomas
> Nimm stattdessen SuperDuper oder CarbonCopyCloner und klone Deine
> Harddisk 1:1 auf eine externe Platte. Da weißt Du, daß Du 100 % jede
> Datei gesichert hast.
Nix hast Du "gesichert". Du hast halt einen Klon. Und wenn Du Dich
> Harddisk 1:1 auf eine externe Platte. Da weißt Du, daß Du 100 % jede
> Datei gesichert hast.
ausschließlich auf den verläßt, bist Du halt einfach nur dämlich, weil
mit Backup hat das -- im Gegensatz zu TimeMachine -- halt nunmal genau
gar nichts zu tun :-)
> TimeMachine ist ein unberechenbares Apple-Spielzeug.
Gut' Nacht,
Thomas
Thomas Kaiser
Nov 12, 2015, 4:59:56 PM11/12/15
to
Dirk Wagner schrieb in <news:1mdsmgd.71i3y31or8w7aN%usenet...@diwasoft.de>
Quelle. Tja, keine Ahnung. Aber sowas ist mir bislang noch nicht
untergekommen.
Gruss,
Thomas, der ab und an händisch "tmutil compare" mehr so aus Langeweile
laufen läßt und ansonsten drauf achtet, dass TM-Medien nicht "zu alt"
werden -- schön rotieren und immer wieder bei null anfangen je Medium.
> Ich hatte sogar 3 rotierende Medien - und auf allen dreien sieht es
> gleich aus...
Hui, das ist bitter, weil da liegt die Ursache tatsächlich an der
> gleich aus...
Quelle. Tja, keine Ahnung. Aber sowas ist mir bislang noch nicht
untergekommen.
Gruss,
Thomas, der ab und an händisch "tmutil compare" mehr so aus Langeweile
laufen läßt und ansonsten drauf achtet, dass TM-Medien nicht "zu alt"
werden -- schön rotieren und immer wieder bei null anfangen je Medium.
Fritz
Nov 13, 2015, 3:15:34 AM11/13/15
to
Am 12.11.15 um 22:59 schrieb Thomas Kaiser:
Ich hatte zwei TM Backups (ich nutze schon seit Längerem alternierend
zwei USB Festplatten dazu) mit unterschiedlichen Datenbeständen.
Das lässt mich nun ernsthaft darüber nachdenken endlich meine CCC Lizenz
upzugraden (da war bei OS X 10.10 Schluss).
--
Fritz
Ironie, Sarkasmus, Satire, Farce, Groteske, Persiflage, Metapher sind
keinesfalls ausgeschlossen!
> Dirk Wagner schrieb in<news:1mdsmgd.71i3y31or8w7aN%usenet...@diwasoft.de>
>> >Ich hatte sogar 3 rotierende Medien - und auf allen dreien sieht es
>> >gleich aus...
> Hui, das ist bitter, weil da liegt die Ursache tatsächlich an der
> Quelle. Tja, keine Ahnung. Aber sowas ist mir bislang noch nicht
> untergekommen.
So etwas habe ich auch schon einmal erlebt.
>> >Ich hatte sogar 3 rotierende Medien - und auf allen dreien sieht es
>> >gleich aus...
> Hui, das ist bitter, weil da liegt die Ursache tatsächlich an der
> Quelle. Tja, keine Ahnung. Aber sowas ist mir bislang noch nicht
> untergekommen.
Ich hatte zwei TM Backups (ich nutze schon seit Längerem alternierend
zwei USB Festplatten dazu) mit unterschiedlichen Datenbeständen.
Das lässt mich nun ernsthaft darüber nachdenken endlich meine CCC Lizenz
upzugraden (da war bei OS X 10.10 Schluss).
--
Fritz
Ironie, Sarkasmus, Satire, Farce, Groteske, Persiflage, Metapher sind
keinesfalls ausgeschlossen!
Guenther Fischer
Nov 13, 2015, 4:10:28 AM11/13/15
to
In article <slrnn4a2ph.1ll...@phg-online.de>, Thomas Kaiser
Danke, dass Du das gemacht hast. Timemachine ist zum schnellen
zurückholen "verlorener Dateien" unverzichtbar. Inzwischen ist auch
Retrospect wieder recht gut dabei. Es hakelt zwar immer noch etwas mit
dem Verwalten von Volumes im Netz, wenn diese häufig wechseln (Laptops
und externe Laufwerke). Aber sonst erfüllt es bei mir alle Wünsche nach
Datensicherheit und Zuverlässigkeit. Und die Updates kommen regelmässig
und sind fast synchron mit den Betriebssystem-Updates.
zurückholen "verlorener Dateien" unverzichtbar. Inzwischen ist auch
Retrospect wieder recht gut dabei. Es hakelt zwar immer noch etwas mit
dem Verwalten von Volumes im Netz, wenn diese häufig wechseln (Laptops
und externe Laufwerke). Aber sonst erfüllt es bei mir alle Wünsche nach
Datensicherheit und Zuverlässigkeit. Und die Updates kommen regelmässig
und sind fast synchron mit den Betriebssystem-Updates.
Dirk Wagner
Nov 13, 2015, 4:31:50 AM11/13/15
to
Fritz <fr...@sea.nomail.invalid> wrote:
> So etwas habe ich auch schon einmal erlebt.
> Ich hatte zwei TM Backups (ich nutze schon seit Längerem alternierend
> zwei USB Festplatten dazu) mit unterschiedlichen Datenbeständen.
Unterschiedliche Datenbestände, was die neuesten DAten betrifft, könnte
> So etwas habe ich auch schon einmal erlebt.
> Ich hatte zwei TM Backups (ich nutze schon seit Längerem alternierend
> zwei USB Festplatten dazu) mit unterschiedlichen Datenbeständen.
ich ja noch verstehen - aber wenn ein Ordner, der die Unterordner
200401,200402,...,200412,200501,...,201509 beinhaltet hat, auf dem
Backup nur noch 6 der 120 Unterordner hat, dann passt was nicht.
Dabei handelt es sich um 201011,201108,201408,201505,201507 und 201508.
Die letzten 3 Ordner wurden im September 2015 das letzte mal angefasst,
die anderen 2011 und 20012...
Ciao
dirk
Frank Reutter
Nov 13, 2015, 5:10:23 AM11/13/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> > TimeMachine ist ein unberechenbares Apple-Spielzeug.
>
> Genau. Und ich mach mich zum Trottel, weil ich dem Troll antworte. :-)
... es lag mir auf der Zunge.
> > TimeMachine ist ein unberechenbares Apple-Spielzeug.
>
> Genau. Und ich mach mich zum Trottel, weil ich dem Troll antworte. :-)
cu
f
--
...ausserdem halte ich verdunkelte Heckscheiben für antisozial und dumm.
Joe Kotroczo
Nov 13, 2015, 5:33:24 AM11/13/15
to
On 12/11/2015 21:57, Thomas Kaiser wrote:
> Dirk Münster schrieb in <news:n22v43$sve$1...@speranza.aioe.org>
(...)
> Dirk Münster schrieb in <news:n22v43$sve$1...@speranza.aioe.org>
>> TimeMachine ist ein unberechenbares Apple-Spielzeug.
>
> Genau. Und ich mach mich zum Trottel, weil ich dem Troll antworte. :-)
Dennoch liest man immer wieder daß TimeMachine nicht alles sichert...
>
> Genau. Und ich mach mich zum Trottel, weil ich dem Troll antworte. :-)
Vertrauen geht anders.
Man braucht TimeMachine halt leider trotzdem seit Apple-Software
Änderungen in Dateien übernimmt ohne daß man explizit "speichert". Da
muß man dann leider häufiger frühere Versionen von Dateien "restoren".
Insofern muß man ihm leider Recht geben, Vertrauen in die
Zukunftssicherheit von Apple-Software tendiert nach dem Final Cut Pro
Debakel gegen Null, und das Vertrauen in TimeMachine ist auch nicht viel
höher. Ich mache zusätzlich zu TimeMachine (mit mehreren Medien an
unterschiedlichen Orten) noch Backups von den wichtigsten Sachen mit Arq
und regelmäßige Clones per CCC oder Disk Utility. Ich weiß halt nur
nicht welches ich im Schadensfall zuerst zurückspielen würde, ich ahne
daß das in eine Order-Vergleichs-Orgie ausarten würde.
Thomas Kaiser
Nov 13, 2015, 6:47:50 AM11/13/15
to
Guenther Fischer schrieb in <news:131120151010259419%ne...@spam.invalid>
zu, steckst die TimeMachine-Platte ab und wirfst das MacBook aus dem
Fenster. Dann kaufst Du beim Gemüsehändler ums Eck einen Mac Mini,
stöpselst an den die TM-Platte, schaltest ein und läßt alles aus dem
Backup wieder herstellen. Und arbeitest 2 Stunden auf dem Mini dort
weiter, wo Du auf dem weggeschmissenen MacBook aufgehört hast. BTDT --
zwar unfreiwillig aber ging aufgrund Apple-Bugs im 10.10.4-Installer
irgendwann nicht anders.
Das System, mit dem ich hier arbeite, ist kontinuierlich von MacOS 8.0
hochgezogen worden. Zigmal per Setup- und Migrations-Assistent migriert
worden, einmal jetzt auch aus 'nem TM-Backup migriert worden und ein
anderes mal per Full-Restore aus dem TM-Backup gezuzelt. Funktionierte
immer wunderbar und der einzige Fehler, der je auftrat, war dem Nutzer
vor dem Mac geschuldet (~/Downloads nicht mitgesichert und folglich ein
Skript, das ich dämlicherweise da drinnen mitten in einem Download
entwickelte hatte, futsch)
Hilft Dirk jetzt nicht weiter. Aber das ist der Normalzustand. Und dem
kann man ein klein wenig nachhelfen, indem man alle Nas' lang mal den
Mac mit gedrückter [shift]-Taste startet und sich angewöhnt, alle paar
Monate mal eines der rotierenden TM-Medien frisch zu formatieren. Also
wenn man der Idee "Prävention" was abgewinnen kann und nicht etwa auf
Drama als Lebenskonzept steht.
Gruss,
Thomas
> Timemachine ist zum schnellen zurückholen "verlorener Dateien"
> unverzichtbar.
TimeMachine taugt noch zu ganz anderen Sachen. Du klappst Dein MacBook
> unverzichtbar.
zu, steckst die TimeMachine-Platte ab und wirfst das MacBook aus dem
Fenster. Dann kaufst Du beim Gemüsehändler ums Eck einen Mac Mini,
stöpselst an den die TM-Platte, schaltest ein und läßt alles aus dem
Backup wieder herstellen. Und arbeitest 2 Stunden auf dem Mini dort
weiter, wo Du auf dem weggeschmissenen MacBook aufgehört hast. BTDT --
zwar unfreiwillig aber ging aufgrund Apple-Bugs im 10.10.4-Installer
irgendwann nicht anders.
Das System, mit dem ich hier arbeite, ist kontinuierlich von MacOS 8.0
hochgezogen worden. Zigmal per Setup- und Migrations-Assistent migriert
worden, einmal jetzt auch aus 'nem TM-Backup migriert worden und ein
anderes mal per Full-Restore aus dem TM-Backup gezuzelt. Funktionierte
immer wunderbar und der einzige Fehler, der je auftrat, war dem Nutzer
vor dem Mac geschuldet (~/Downloads nicht mitgesichert und folglich ein
Skript, das ich dämlicherweise da drinnen mitten in einem Download
entwickelte hatte, futsch)
Hilft Dirk jetzt nicht weiter. Aber das ist der Normalzustand. Und dem
kann man ein klein wenig nachhelfen, indem man alle Nas' lang mal den
Mac mit gedrückter [shift]-Taste startet und sich angewöhnt, alle paar
Monate mal eines der rotierenden TM-Medien frisch zu formatieren. Also
wenn man der Idee "Prävention" was abgewinnen kann und nicht etwa auf
Drama als Lebenskonzept steht.
Gruss,
Thomas
Thomas Kaiser
Nov 13, 2015, 6:52:08 AM11/13/15
to
Joe Kotroczo schrieb in <news:dalsjh...@mid.individual.net>
zu erklären versucht, dass ich es jetzt einfach lasse.
> Vertrauen geht anders.
Du mußt jetzt ganz tapfer sein: Dein CCC sichert -- abermals aus gutem
Grund -- auch nicht alles:
https://bombich.com/kb/ccc3/some-files-and-folders-are-automatically-excluded-backup-task
Ansonsten: Auf 2 _taugliche_ Ansätze zur Datensicherung parallel zu
setzen, ist natürlich besser als auf eine. Das ist keiner Diskussion
würdig.
Gruss,
Thomas
> Dennoch liest man immer wieder daß TimeMachine nicht alles sichert...
Ja, aus gutem Grund. Ich hab das hier in den letzten Jahren schon so oft
zu erklären versucht, dass ich es jetzt einfach lasse.
> Vertrauen geht anders.
Du mußt jetzt ganz tapfer sein: Dein CCC sichert -- abermals aus gutem
Grund -- auch nicht alles:
https://bombich.com/kb/ccc3/some-files-and-folders-are-automatically-excluded-backup-task
Ansonsten: Auf 2 _taugliche_ Ansätze zur Datensicherung parallel zu
setzen, ist natürlich besser als auf eine. Das ist keiner Diskussion
würdig.
Gruss,
Thomas
Dirk Wagner
Nov 13, 2015, 7:19:34 AM11/13/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Das System, mit dem ich hier arbeite, ist kontinuierlich von MacOS 8.0
> hochgezogen worden. Zigmal per Setup- und Migrations-Assistent migriert
> worden, einmal jetzt auch aus 'nem TM-Backup migriert worden und ein
> anderes mal per Full-Restore aus dem TM-Backup gezuzelt.
Ja, so habe ich das mit dem iMac hier auch gemacht.
> Das System, mit dem ich hier arbeite, ist kontinuierlich von MacOS 8.0
> hochgezogen worden. Zigmal per Setup- und Migrations-Assistent migriert
> worden, einmal jetzt auch aus 'nem TM-Backup migriert worden und ein
> anderes mal per Full-Restore aus dem TM-Backup gezuzelt.
Die ersten 4 Jahre lief der auf einem System, bei dem alle Benutzerdaten
per Assisten von einem G5 kamen.
Alle Updates von 10.4 bis 10.6.8.
Irgendwann habe ich dann auf 10.9 gewechselt und aus SSD und HDD ein
Fusiondrive gemacht. Bei DER Aktion bin ich über das TM-Backup gegangen
und alles hat funktioniert.
Genauso, bei Updates und Umzügen von weiteren Rechnern hier in der
Familie.
Warum es jetzt beim wichtigsten Rechner NICHT funktioniert hat, weiß der
Geier.
Alternativen zu TM wie der hier immer wieder erwähnte Klon der Platte
haben in meinen Augen den Nachteil, nicht wirklich automatisch zu
funktionieren.
Ich habe als Ergänzung zum TM-Backup auch teile meiner Daten immer
wieder auf externe Daten kopiert.
Aber dabei verliert man irgendwann den Überlick und so häufen sich alte
Daten in unkontrolierbarer Menge an.
Ciao
dirk
Joe Kotroczo
Nov 13, 2015, 7:20:08 AM11/13/15
to
On 13/11/2015 11:52, Thomas Kaiser wrote:
> Joe Kotroczo schrieb in <news:dalsjh...@mid.individual.net>
>> Dennoch liest man immer wieder daß TimeMachine nicht alles sichert...
>
> Ja, aus gutem Grund. Ich hab das hier in den letzten Jahren schon so oft
> zu erklären versucht, dass ich es jetzt einfach lasse.
Let me rephrase that: ... daß TimeMachine Nutzdaten die man eigentlich
> Joe Kotroczo schrieb in <news:dalsjh...@mid.individual.net>
>> Dennoch liest man immer wieder daß TimeMachine nicht alles sichert...
>
> Ja, aus gutem Grund. Ich hab das hier in den letzten Jahren schon so oft
> zu erklären versucht, dass ich es jetzt einfach lasse.
sichern wollte nicht sichert.
>> Vertrauen geht anders.
>
> Du mußt jetzt ganz tapfer sein: Dein CCC sichert -- abermals aus gutem
> Grund -- auch nicht alles:
>
> https://bombich.com/kb/ccc3/some-files-and-folders-are-automatically-excluded-backup-task
immer noch ein "richtiger" Clone, oder?. Ich schau beim nächsten Mal ob
das immer noch so ist. Es geht mir beim Clone ja auch eher um das
Szenario "Laptop ist weg, ich kann vom Clone booten und sofort
weiterarbeiten".
Thomas Kaiser
Nov 13, 2015, 7:46:10 AM11/13/15
to
Joe Kotroczo schrieb in <news:dam2rn...@mid.individual.net>
Ansonsten sichert TM alles das nicht, was einem diese Befehle
ausspucken:
defaults read /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions
defaults read /Library/Preferences/com.apple.TimeMachine ExcludeByPath
mdfind com_apple_backup_excludeItem = "com.apple.backupd"
defaults read /Library/Preferences/com.apple.TimeMachine SkipPaths
Und noch ein paar Sachen mehr nicht, die intern hartkodiert sind.
>>> Vertrauen geht anders.
>>
>> Du mußt jetzt ganz tapfer sein: Dein CCC sichert -- abermals aus
>> gutem Grund -- auch nicht alles:
>>
>> https://bombich.com/kb/ccc3/some-files-and-folders-are-automatically-excluded-backup-task
>
> Das bezieht sich auf die "Backup" Funktion von CCC. Ein Clone ist
> AFAIK immer noch ein "richtiger" Clone, oder?.
Das betrifft auch den Klon-Modus und es ist ja auch detailliert
beschrieben, warum das so sein muß. Weil Du von dem Ding ggf. booten
können willst, darf Zeugs, das das Booten verhindern würde, nicht
mitgesichert/-synct/-klont werden. Bspw. /private/var/db/dyld/dyld_*
Und Bombich listet die Ordner übrigens deshalb so komich auf, weil das
genau das 'exclude'-Format ist, das dann später an rsync übergeben wird,
das den eigentlichen Job macht. Wenn Dich das im Detail interessiert
(also was *noch* alles *nicht* mitgesynct wird):
defaults read /Applications/Carbon\ Copy\ Cloner.app/Contents/Resources/defaults itemsWithSpecialRequirements
Aus dieser Preference baut CCC dann dynamisch das exklude-File, das
rsync dann per --exclude-from übergeben wird.
> Es geht mir beim Clone ja auch eher um das Szenario "Laptop ist weg,
> ich kann vom Clone booten und sofort weiterarbeiten".
Klar, der beliebteste Irrglaube aller Zeiten :-)
Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden System
heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
unterstützen -- nein, OS X hat weder das eine noch das andere). Also
System runterfahren, in die Recovery Partition booten, Klon-Platte
anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
weil viel zu aufwändig. Also gibt man sich mit einem nur zu 99,x%
bootbaren Klon zufrieden, der irgendwie inkonsistent ist. Die
Inkosistenz beschert einem später irgendwann mal Datenverlust, was man
aber nicht dem vormaligen Klonen anlastet sondern einer höheren Macht
zuschreibt. Ach, Mist, jetzt habe ich mich doch wieder dazu hinreißen
lassen, auf diesen Quatsch, den Mac-User anscheinend nicht verstehen
*können*, einzugehen.
Gruss,
Thomas
> On 13/11/2015 11:52, Thomas Kaiser wrote:
>> Joe Kotroczo schrieb in <news:dalsjh...@mid.individual.net>
>>> Dennoch liest man immer wieder daß TimeMachine nicht alles
>>> sichert...
>>
>> Ja, aus gutem Grund. Ich hab das hier in den letzten Jahren schon so
>> oft zu erklären versucht, dass ich es jetzt einfach lasse.
>
> Let me rephrase that: ... daß TimeMachine Nutzdaten die man eigentlich
> sichern wollte nicht sichert.
Kenn ich nicht. Bei mir macht TimeMachine das.
>> Joe Kotroczo schrieb in <news:dalsjh...@mid.individual.net>
>>> Dennoch liest man immer wieder daß TimeMachine nicht alles
>>> sichert...
>>
>> Ja, aus gutem Grund. Ich hab das hier in den letzten Jahren schon so
>> oft zu erklären versucht, dass ich es jetzt einfach lasse.
>
> Let me rephrase that: ... daß TimeMachine Nutzdaten die man eigentlich
> sichern wollte nicht sichert.
Ansonsten sichert TM alles das nicht, was einem diese Befehle
ausspucken:
defaults read /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions
defaults read /Library/Preferences/com.apple.TimeMachine ExcludeByPath
mdfind com_apple_backup_excludeItem = "com.apple.backupd"
defaults read /Library/Preferences/com.apple.TimeMachine SkipPaths
Und noch ein paar Sachen mehr nicht, die intern hartkodiert sind.
>>> Vertrauen geht anders.
>>
>> Du mußt jetzt ganz tapfer sein: Dein CCC sichert -- abermals aus
>> gutem Grund -- auch nicht alles:
>>
>> https://bombich.com/kb/ccc3/some-files-and-folders-are-automatically-excluded-backup-task
>
> Das bezieht sich auf die "Backup" Funktion von CCC. Ein Clone ist
> AFAIK immer noch ein "richtiger" Clone, oder?.
beschrieben, warum das so sein muß. Weil Du von dem Ding ggf. booten
können willst, darf Zeugs, das das Booten verhindern würde, nicht
mitgesichert/-synct/-klont werden. Bspw. /private/var/db/dyld/dyld_*
Und Bombich listet die Ordner übrigens deshalb so komich auf, weil das
genau das 'exclude'-Format ist, das dann später an rsync übergeben wird,
das den eigentlichen Job macht. Wenn Dich das im Detail interessiert
(also was *noch* alles *nicht* mitgesynct wird):
defaults read /Applications/Carbon\ Copy\ Cloner.app/Contents/Resources/defaults itemsWithSpecialRequirements
Aus dieser Preference baut CCC dann dynamisch das exklude-File, das
rsync dann per --exclude-from übergeben wird.
> Es geht mir beim Clone ja auch eher um das Szenario "Laptop ist weg,
> ich kann vom Clone booten und sofort weiterarbeiten".
Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden System
heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
unterstützen -- nein, OS X hat weder das eine noch das andere). Also
System runterfahren, in die Recovery Partition booten, Klon-Platte
anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
weil viel zu aufwändig. Also gibt man sich mit einem nur zu 99,x%
bootbaren Klon zufrieden, der irgendwie inkonsistent ist. Die
Inkosistenz beschert einem später irgendwann mal Datenverlust, was man
aber nicht dem vormaligen Klonen anlastet sondern einer höheren Macht
zuschreibt. Ach, Mist, jetzt habe ich mich doch wieder dazu hinreißen
lassen, auf diesen Quatsch, den Mac-User anscheinend nicht verstehen
*können*, einzugehen.
Gruss,
Thomas
Joe Kotroczo
Nov 13, 2015, 8:14:06 AM11/13/15
to
On 13/11/2015 12:46, Thomas Kaiser wrote:
(...)
Partition. Gemacht hab ich schon mindestens einmal, CCC schien
komfortabler aber wenn das Resultat nicht 100% ist dann ist das für mich
zumindest ungut.
Danke für die Ausführungen.
(...)
> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden System
> heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
> unterstützen -- nein, OS X hat weder das eine noch das andere). Also
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
> weil viel zu aufwändig. Also gibt man sich mit einem nur zu 99,x%
> bootbaren Klon zufrieden, der irgendwie inkonsistent ist. Die
> Inkosistenz beschert einem später irgendwann mal Datenverlust, was man
> aber nicht dem vormaligen Klonen anlastet sondern einer höheren Macht
> zuschreibt. Ach, Mist, jetzt habe ich mich doch wieder dazu hinreißen
> lassen, auf diesen Quatsch, den Mac-User anscheinend nicht verstehen
> *können*, einzugehen.
Fazit: ab jetzt mache ich den Klon per Disk Utility aus der Recovery
> heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
> unterstützen -- nein, OS X hat weder das eine noch das andere). Also
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
> weil viel zu aufwändig. Also gibt man sich mit einem nur zu 99,x%
> bootbaren Klon zufrieden, der irgendwie inkonsistent ist. Die
> Inkosistenz beschert einem später irgendwann mal Datenverlust, was man
> aber nicht dem vormaligen Klonen anlastet sondern einer höheren Macht
> zuschreibt. Ach, Mist, jetzt habe ich mich doch wieder dazu hinreißen
> lassen, auf diesen Quatsch, den Mac-User anscheinend nicht verstehen
> *können*, einzugehen.
Partition. Gemacht hab ich schon mindestens einmal, CCC schien
komfortabler aber wenn das Resultat nicht 100% ist dann ist das für mich
zumindest ungut.
Danke für die Ausführungen.
Thomas Kaiser
Nov 13, 2015, 8:47:52 AM11/13/15
to
Joe Kotroczo schrieb in <news:dam60t...@mid.individual.net>
10.10 (oder gar schon 10.9) mitliefert, alle Apple-Besonderheiten an
Bord hat. In älteren OS X Versionen müsste man sich das dem CCC
beiliegende rsync schnappen.
> Gemacht hab ich schon mindestens einmal, CCC schien komfortabler aber
> wenn das Resultat nicht 100% ist dann ist das für mich zumindest
> ungut.
Das Problem, warum man kein _laufendes_ System unfallfrei klonen kann,
basiert darauf:
1) Gerade offene Dateien, speziell Datenbanken. Die kann man ja
versuchen, durch die Gegend zu klonen aber die wird hundertpro nicht
in sich konsistent sein (weil Teile der Datenbank noch im RAM liegen
und jede halbwegs taugliche Datenbank ein internes Flag "nicht sauber
geschlossen worden" mit sich führt, das erst beim ordentlichen
Schließen der Datenbank entfernt wird). "Wie Datenbanken?! Sowas
nutze ich nicht!" -- weit gefehlt, OS X hat an allen Ecken und Enden
welche in Gebrauch. Alleine die SQLite-Dinger für dies und das
summieren sich bei mir grad auf fast 50 geöffnete Datenbanken! [1]
2) Kein Snapshot-fähiges Dateisystem, ergo keine Möglichkeit, das FS
konsistent zu sichern. Wenn so ein Klonvorgang eine Viertelstunde
lang durchs Dateisystem rennt und Sachen von der Quelle aufs Ziel
schiebt, und dann eine Software parallel an zwei Stellen im Datei-
system Sachen ändert, die zueinander konsistent sein sollen, dann
kann's passieren (bzw. passiert andauernd bei dem depperten Blödel-
geklone, dem Macianer blindlings vertrauen), dass der Klonvorgang die
eine Änderung nicht mitzieht, weil er dort schon vor 'ner Minute
vorbeigerödelt ist. Die einzige Möglichkeit, dieses Risiko zu
minimieren, wäre, nach dem erfolgreichen Klonvorgang per fsevents
nachgucken zu lassen, was sich während der Klonerei alles geändert
hat (also analog wie TimeMachine per fseventsd nachschaut) und dann
dieses Änderungsdelta erneut zu syncen. Aber auch das muß nicht zu
100% sauber enden, man minimiert das Risiko nur.
Die beiden Sachen zusammen bedeuten: Es geht halt einfach nicht. Das hat
auch die ganze Welt begriffen, hat Dateisysteme mit Snapshot-
Funktionalität entwickelt bzw. entsprechende Dienste ins Betriebsystem
eingebaut, mit denen man Konsistenz herstellen kann, unter Windows bspw.
https://de.wikipedia.org/wiki/Volume_Shadow_Copy_Service
Überall ist das ein akzeptiertes Übel, dem man durch Software-Adaptionen
beikommen kann, aber nur dort, wo *nichts* dergleichen existiert,
glauben die User allen Ernstes, das wären Herausforderungen, die am Mac
keine Bedeutung hätten. Und klonen wie die Blöden inkonsistent in der
Gegend herum und merkens noch nicht einmal. Bzw. erst wenn's zu spät ist
und dann ohne Wirkung und Ursache in einen Zusammenhang zu bringen.
Und warum? Weil Software-Klitschen mit dem "Klonen am Mac geht doch"-
Versprechen Kohle machen. Mit der Hauptgrund, warum ich SuperDuper!
nicht ausstehen kann...
Gruss,
Thomas
[1] macbookpro-tk:~ tk$ lsof | grep "\.db$" | cut -c74- | sort | uniq
/Applications/Utilities/Adobe Application Manager/pim.db
/Applications/Utilities/Adobe Creative Cloud/pim.db
/Library/Application Support/Adobe/Adobe PCD/cache/cache.db
/Library/Application Support/Adobe/Adobe PCD/pcd.db
/Library/Application Support/Adobe/Extension Manager CC/Configuration/DB/ExMan.db
/Library/Application Support/Adobe/caps/caps.db
/Users/tk/Library/Application Support/Adobe/CoreSync/e5967ee929da65427e42580cc2ab13b8.db
/Users/tk/Library/Application Support/Adobe/OOBE/ANEData.db
/Users/tk/Library/Application Support/Adobe/OOBE/opm.db
/Users/tk/Library/Application Support/Dock/desktoppicture.db
/Users/tk/Library/Application Support/Firefox/Profiles/default.cci/cert8.db
/Users/tk/Library/Application Support/Firefox/Profiles/default.cci/key3.db
/Users/tk/Library/Application Support/com.apple.TCC/TCC.db
/Users/tk/Library/Caches/com.apple.Safari/Cache.db
/Users/tk/Library/Caches/com.apple.Spotlight/Cache.db
/Users/tk/Library/Caches/com.apple.Terminal/Cache.db
/Users/tk/Library/Caches/com.apple.finder/Cache.db
/Users/tk/Library/Caches/com.apple.metadata.SpotlightNetHelper/Cache.db
/Users/tk/Library/Caches/com.apple.nbagent/Cache.db
/Users/tk/Library/Caches/com.barebones.bbedit/Cache.db
/Users/tk/Library/Caches/com.flexibits.fantastical/Cache.db
/Users/tk/Library/Caches/com.latenightsw.ScriptDebugger5/Cache.db
/Users/tk/Library/Caches/com.mactrackerapp.Mactracker/Cache.db
/Users/tk/Library/Caches/com.microsoft.Outlook/Cache.db
/Users/tk/Library/Caches/com.runningwithcrayons.Alfred-2/Cache.db
/Users/tk/Library/Caches/net.tunnelblick.tunnelblick/Cache.db
/Users/tk/Library/Caches/org.sveinbjorn.Platypus/Cache.db
/Users/tk/Library/Caches/storeaccountd/Cache.db
/Users/tk/Library/Caches/storeassetd/Cache.db
/Users/tk/Library/Caches/storedownloadd/Cache.db
/Users/tk/Library/Caches/ws.agile.1Password/Cache.db
/Users/tk/Library/Dictionaries/CoreDataUbiquitySupport/tk~1AB5C128-3BB0-5090-8AFC-0182DF9DB678/UserDictionary/local/store/UserDictionary.db
/Users/tk/Library/Keychains/1AB5C128-3BB0-5090-8AFC-0182DF9DB678/keychain-2.db
/Users/tk/Library/Safari/Databases/Databases.db
/Users/tk/Library/Safari/Databases/safari-extension_com.agilebits.onepassword-safari-2bua8c4s2c_0/1ddad34a-d0f0-4bf5-9a19-801975cf4494.db
/Users/tk/Library/Safari/History.db
/Users/tk/Library/Safari/LocalStorage/StorageTracker.db
/Users/tk/Library/Safari/WebpageIcons.db
/Users/tk/Library/WebKit/com.apple.Safari/WebsiteData/LocalStorage/StorageTracker.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Preview/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari.SearchHelper/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari/ApplicationCache.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari/SafeBrowsing.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.WebKit.Networking+com.apple.Safari/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.WebKit.WebContent+com.apple.Spotlight/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.quicklook.ui.helper/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/mds/mdsDirectory.db
> On 13/11/2015 12:46, Thomas Kaiser wrote:
> (...)
>> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden
>> System heraus anfertigen (oder man hat ein Dateisystem und APIs, die
>> das unterstützen -- nein, OS X hat weder das eine noch das andere).
>> Also System runterfahren, in die Recovery Partition booten,
>> Klon-Platte anschließen, klonen lassen. Und dann weiterarbeiten.
>> Macht kein Mensche, weil viel zu aufwändig. Also gibt man sich mit
>> einem nur zu 99,x% bootbaren Klon zufrieden, der irgendwie
>> inkonsistent ist. Die Inkosistenz beschert einem später irgendwann
>> mal Datenverlust, was man aber nicht dem vormaligen Klonen anlastet
>> sondern einer höheren Macht zuschreibt. Ach, Mist, jetzt habe ich
>> mich doch wieder dazu hinreißen lassen, auf diesen Quatsch, den
>> Mac-User anscheinend nicht verstehen *können*, einzugehen.
>
> Fazit: ab jetzt mache ich den Klon per Disk Utility aus der Recovery
> Partition.
Ginge dort inzwischen auch inkrementell, weil das rsync, das Apple seit
> (...)
>> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden
>> System heraus anfertigen (oder man hat ein Dateisystem und APIs, die
>> das unterstützen -- nein, OS X hat weder das eine noch das andere).
>> Also System runterfahren, in die Recovery Partition booten,
>> Klon-Platte anschließen, klonen lassen. Und dann weiterarbeiten.
>> Macht kein Mensche, weil viel zu aufwändig. Also gibt man sich mit
>> einem nur zu 99,x% bootbaren Klon zufrieden, der irgendwie
>> inkonsistent ist. Die Inkosistenz beschert einem später irgendwann
>> mal Datenverlust, was man aber nicht dem vormaligen Klonen anlastet
>> sondern einer höheren Macht zuschreibt. Ach, Mist, jetzt habe ich
>> mich doch wieder dazu hinreißen lassen, auf diesen Quatsch, den
>> Mac-User anscheinend nicht verstehen *können*, einzugehen.
>
> Fazit: ab jetzt mache ich den Klon per Disk Utility aus der Recovery
> Partition.
10.10 (oder gar schon 10.9) mitliefert, alle Apple-Besonderheiten an
Bord hat. In älteren OS X Versionen müsste man sich das dem CCC
beiliegende rsync schnappen.
> Gemacht hab ich schon mindestens einmal, CCC schien komfortabler aber
> wenn das Resultat nicht 100% ist dann ist das für mich zumindest
> ungut.
basiert darauf:
1) Gerade offene Dateien, speziell Datenbanken. Die kann man ja
versuchen, durch die Gegend zu klonen aber die wird hundertpro nicht
in sich konsistent sein (weil Teile der Datenbank noch im RAM liegen
und jede halbwegs taugliche Datenbank ein internes Flag "nicht sauber
geschlossen worden" mit sich führt, das erst beim ordentlichen
Schließen der Datenbank entfernt wird). "Wie Datenbanken?! Sowas
nutze ich nicht!" -- weit gefehlt, OS X hat an allen Ecken und Enden
welche in Gebrauch. Alleine die SQLite-Dinger für dies und das
summieren sich bei mir grad auf fast 50 geöffnete Datenbanken! [1]
2) Kein Snapshot-fähiges Dateisystem, ergo keine Möglichkeit, das FS
konsistent zu sichern. Wenn so ein Klonvorgang eine Viertelstunde
lang durchs Dateisystem rennt und Sachen von der Quelle aufs Ziel
schiebt, und dann eine Software parallel an zwei Stellen im Datei-
system Sachen ändert, die zueinander konsistent sein sollen, dann
kann's passieren (bzw. passiert andauernd bei dem depperten Blödel-
geklone, dem Macianer blindlings vertrauen), dass der Klonvorgang die
eine Änderung nicht mitzieht, weil er dort schon vor 'ner Minute
vorbeigerödelt ist. Die einzige Möglichkeit, dieses Risiko zu
minimieren, wäre, nach dem erfolgreichen Klonvorgang per fsevents
nachgucken zu lassen, was sich während der Klonerei alles geändert
hat (also analog wie TimeMachine per fseventsd nachschaut) und dann
dieses Änderungsdelta erneut zu syncen. Aber auch das muß nicht zu
100% sauber enden, man minimiert das Risiko nur.
Die beiden Sachen zusammen bedeuten: Es geht halt einfach nicht. Das hat
auch die ganze Welt begriffen, hat Dateisysteme mit Snapshot-
Funktionalität entwickelt bzw. entsprechende Dienste ins Betriebsystem
eingebaut, mit denen man Konsistenz herstellen kann, unter Windows bspw.
https://de.wikipedia.org/wiki/Volume_Shadow_Copy_Service
Überall ist das ein akzeptiertes Übel, dem man durch Software-Adaptionen
beikommen kann, aber nur dort, wo *nichts* dergleichen existiert,
glauben die User allen Ernstes, das wären Herausforderungen, die am Mac
keine Bedeutung hätten. Und klonen wie die Blöden inkonsistent in der
Gegend herum und merkens noch nicht einmal. Bzw. erst wenn's zu spät ist
und dann ohne Wirkung und Ursache in einen Zusammenhang zu bringen.
Und warum? Weil Software-Klitschen mit dem "Klonen am Mac geht doch"-
Versprechen Kohle machen. Mit der Hauptgrund, warum ich SuperDuper!
nicht ausstehen kann...
Gruss,
Thomas
[1] macbookpro-tk:~ tk$ lsof | grep "\.db$" | cut -c74- | sort | uniq
/Applications/Utilities/Adobe Application Manager/pim.db
/Applications/Utilities/Adobe Creative Cloud/pim.db
/Library/Application Support/Adobe/Adobe PCD/cache/cache.db
/Library/Application Support/Adobe/Adobe PCD/pcd.db
/Library/Application Support/Adobe/Extension Manager CC/Configuration/DB/ExMan.db
/Library/Application Support/Adobe/caps/caps.db
/Users/tk/Library/Application Support/Adobe/CoreSync/e5967ee929da65427e42580cc2ab13b8.db
/Users/tk/Library/Application Support/Adobe/OOBE/ANEData.db
/Users/tk/Library/Application Support/Adobe/OOBE/opm.db
/Users/tk/Library/Application Support/Dock/desktoppicture.db
/Users/tk/Library/Application Support/Firefox/Profiles/default.cci/cert8.db
/Users/tk/Library/Application Support/Firefox/Profiles/default.cci/key3.db
/Users/tk/Library/Application Support/com.apple.TCC/TCC.db
/Users/tk/Library/Caches/com.apple.Safari/Cache.db
/Users/tk/Library/Caches/com.apple.Spotlight/Cache.db
/Users/tk/Library/Caches/com.apple.Terminal/Cache.db
/Users/tk/Library/Caches/com.apple.finder/Cache.db
/Users/tk/Library/Caches/com.apple.metadata.SpotlightNetHelper/Cache.db
/Users/tk/Library/Caches/com.apple.nbagent/Cache.db
/Users/tk/Library/Caches/com.barebones.bbedit/Cache.db
/Users/tk/Library/Caches/com.flexibits.fantastical/Cache.db
/Users/tk/Library/Caches/com.latenightsw.ScriptDebugger5/Cache.db
/Users/tk/Library/Caches/com.mactrackerapp.Mactracker/Cache.db
/Users/tk/Library/Caches/com.microsoft.Outlook/Cache.db
/Users/tk/Library/Caches/com.runningwithcrayons.Alfred-2/Cache.db
/Users/tk/Library/Caches/net.tunnelblick.tunnelblick/Cache.db
/Users/tk/Library/Caches/org.sveinbjorn.Platypus/Cache.db
/Users/tk/Library/Caches/storeaccountd/Cache.db
/Users/tk/Library/Caches/storeassetd/Cache.db
/Users/tk/Library/Caches/storedownloadd/Cache.db
/Users/tk/Library/Caches/ws.agile.1Password/Cache.db
/Users/tk/Library/Dictionaries/CoreDataUbiquitySupport/tk~1AB5C128-3BB0-5090-8AFC-0182DF9DB678/UserDictionary/local/store/UserDictionary.db
/Users/tk/Library/Keychains/1AB5C128-3BB0-5090-8AFC-0182DF9DB678/keychain-2.db
/Users/tk/Library/Safari/Databases/Databases.db
/Users/tk/Library/Safari/Databases/safari-extension_com.agilebits.onepassword-safari-2bua8c4s2c_0/1ddad34a-d0f0-4bf5-9a19-801975cf4494.db
/Users/tk/Library/Safari/History.db
/Users/tk/Library/Safari/LocalStorage/StorageTracker.db
/Users/tk/Library/Safari/WebpageIcons.db
/Users/tk/Library/WebKit/com.apple.Safari/WebsiteData/LocalStorage/StorageTracker.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Preview/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari.SearchHelper/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari/ApplicationCache.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.Safari/SafeBrowsing.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.WebKit.Networking+com.apple.Safari/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.WebKit.WebContent+com.apple.Spotlight/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/com.apple.quicklook.ui.helper/mds/mdsDirectory.db
/private/var/folders/2d/l6bcc6q88xlb_x008k8dljqh0000gn/C/mds/mdsDirectory.db
Andre Igler
Nov 13, 2015, 9:19:06 AM11/13/15
to
Am 13.11.15 um 13:46 schrieb Thomas Kaiser:
Als ich noch für Tageszeitungen meinen DTP-Scheiz gemacht hab' und es
echt zeitkritisch war, hab ich genau das getan. Weil nur das garantiert
genau das obgenannte, nämlich "von Klon booten & weiterarbeiten". Wenn
Du der Druckerei punkt sechs deine Arbeit liefern sollst, und pro Minute
Überzeit 1k € Pönale zahlst, und es den Jungs sch*egal ist, warum Dein
Rechner gerade *jetzt* gestorben ist ... Szenario klassisch: Daten extra
gesichert, und Produktionsmaschine geklont. Und zwar nach jedem
Programm/OS update.
> Also gibt man sich mit einem nur zu 99,x%
> bootbaren Klon zufrieden, der irgendwie inkonsistent ist.
Das ist *kein* Klon. Ich bin ja auch nicht zu 99,x% schwanger. Entweder
es ist einer, oder nicht. Causa tertium non datur.
ad*scnr*dio
--
pm <mein vorname> bei <mein nachname> punkt at
www.albinschwarz.com http://weblog.igler.at
> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden System
> heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
> unterstützen -- nein, OS X hat weder das eine noch das andere). Also
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
> weil viel zu aufwändig.
Oh ja, ich.
> heraus anfertigen (oder man hat ein Dateisystem und APIs, die das
> unterstützen -- nein, OS X hat weder das eine noch das andere). Also
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
> weil viel zu aufwändig.
Als ich noch für Tageszeitungen meinen DTP-Scheiz gemacht hab' und es
echt zeitkritisch war, hab ich genau das getan. Weil nur das garantiert
genau das obgenannte, nämlich "von Klon booten & weiterarbeiten". Wenn
Du der Druckerei punkt sechs deine Arbeit liefern sollst, und pro Minute
Überzeit 1k € Pönale zahlst, und es den Jungs sch*egal ist, warum Dein
Rechner gerade *jetzt* gestorben ist ... Szenario klassisch: Daten extra
gesichert, und Produktionsmaschine geklont. Und zwar nach jedem
Programm/OS update.
> Also gibt man sich mit einem nur zu 99,x%
> bootbaren Klon zufrieden, der irgendwie inkonsistent ist.
es ist einer, oder nicht. Causa tertium non datur.
ad*scnr*dio
--
pm <mein vorname> bei <mein nachname> punkt at
www.albinschwarz.com http://weblog.igler.at
Thomas Kaiser
Nov 13, 2015, 10:01:58 AM11/13/15
to
Andre Igler schrieb in <news:dam9qo...@mid.individual.net>
hohe Verfügbarkeit brauchen. Und da ist die Lösung heutzutage meist,
einfach zu virtualisieren. Vor jedem Update, nen Snapshot der VM
anfertigen und zu dem einfach per Knopfdruck zurück, wenn das Update was
versemmelt hat. Und falls die Hardware ausfällt, fährt man die VM halt
auf 'nem anderen Server wieder hoch. Alles recht handzahm inzwischen.
>> Also gibt man sich mit einem nur zu 99,x% bootbaren Klon zufrieden,
>> der irgendwie inkonsistent ist.
> Das ist *kein* Klon. Ich bin ja auch nicht zu 99,x% schwanger.
> Entweder es ist einer, oder nicht.
Scusa, mein Fehler. Ich schrieb von "bootbar" meinte aber die ganze Zeit
konsistent bzw. problemfrei. Man kann unter OS X keinen konsistenten
Klon aus einem laufenden System erstellen. Und das damit einhergehende
Risiko von Inkonsistenzen (irgendeine Software schreibt während schon
geklont wird, an zwei verschiedenen Stellen auf Platte, bspw. Cache-
Inhalt und dazu passende Preferences, und ersteres landet zufälliger-
weise im Klon, das andere nicht bzw. erst mit der nächsten Klonerei),
kann für Software-Stabilitätsprobleme sorgen, im blödsten Fall gar
Datenverlust durch amoklaufende Software. Später dann, nachdem man vom
Klon gebootet hat.
D.h. der Klon mag zwar 100% bootbar sein aber eben nicht frei von
Inkonsistenzen. Und die ganzen Klon-Fetischisten wollen sich ja nicht
mit technischen Details beschäftigen sondern hängen sich einfach nur an
dem -- falschen -- Versprechen auf: 1:1-Klon, dann *muß* alles passen.
Die Logik dahinter stimmt ja eigentlich auch, was halt leider nicht
paßt, sind die dazu nötigen Randbedingungen, die unter OS X auch anno
2015 nicht mal ansatzweise erfüllt sind. Windows hat das dafür nötige
seit XP, OS X genau gar nix.
Gruss,
Thomas
> Am 13.11.15 um 13:46 schrieb Thomas Kaiser:
>> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden
>> System heraus anfertigen (oder man hat ein Dateisystem und APIs, die
>> das unterstützen -- nein, OS X hat weder das eine noch das andere).
>> Also System runterfahren, in die Recovery Partition booten,
>> Klon-Platte anschließen, klonen lassen. Und dann weiterarbeiten.
>> Macht kein Mensche, weil viel zu aufwändig.
> Oh ja, ich.
>
> Als ich noch für Tageszeitungen meinen DTP-Scheiz gemacht hab' und es
> echt zeitkritisch war, hab ich genau das getan. Weil nur das
> garantiert genau das obgenannte, nämlich "von Klon booten &
> weiterarbeiten". Wenn Du der Druckerei punkt sechs deine Arbeit
> liefern sollst, und pro Minute Überzeit 1k € Pönale zahlst, und es den
> Jungs sch*egal ist, warum Dein Rechner gerade *jetzt* gestorben ist
> ... Szenario klassisch: Daten extra gesichert, und Produktionsmaschine
> geklont. Und zwar nach jedem Programm/OS update.
Hmm... also in unserem Kundenumfeld sind's eher die Server, die extrem
>> Einen Klon, der 100% bootbar ist, kann man nur aus einem ruhenden
>> System heraus anfertigen (oder man hat ein Dateisystem und APIs, die
>> das unterstützen -- nein, OS X hat weder das eine noch das andere).
>> Also System runterfahren, in die Recovery Partition booten,
>> Klon-Platte anschließen, klonen lassen. Und dann weiterarbeiten.
>> Macht kein Mensche, weil viel zu aufwändig.
> Oh ja, ich.
>
> Als ich noch für Tageszeitungen meinen DTP-Scheiz gemacht hab' und es
> echt zeitkritisch war, hab ich genau das getan. Weil nur das
> garantiert genau das obgenannte, nämlich "von Klon booten &
> weiterarbeiten". Wenn Du der Druckerei punkt sechs deine Arbeit
> liefern sollst, und pro Minute Überzeit 1k € Pönale zahlst, und es den
> Jungs sch*egal ist, warum Dein Rechner gerade *jetzt* gestorben ist
> ... Szenario klassisch: Daten extra gesichert, und Produktionsmaschine
> geklont. Und zwar nach jedem Programm/OS update.
hohe Verfügbarkeit brauchen. Und da ist die Lösung heutzutage meist,
einfach zu virtualisieren. Vor jedem Update, nen Snapshot der VM
anfertigen und zu dem einfach per Knopfdruck zurück, wenn das Update was
versemmelt hat. Und falls die Hardware ausfällt, fährt man die VM halt
auf 'nem anderen Server wieder hoch. Alles recht handzahm inzwischen.
>> Also gibt man sich mit einem nur zu 99,x% bootbaren Klon zufrieden,
>> der irgendwie inkonsistent ist.
> Das ist *kein* Klon. Ich bin ja auch nicht zu 99,x% schwanger.
> Entweder es ist einer, oder nicht.
konsistent bzw. problemfrei. Man kann unter OS X keinen konsistenten
Klon aus einem laufenden System erstellen. Und das damit einhergehende
Risiko von Inkonsistenzen (irgendeine Software schreibt während schon
geklont wird, an zwei verschiedenen Stellen auf Platte, bspw. Cache-
Inhalt und dazu passende Preferences, und ersteres landet zufälliger-
weise im Klon, das andere nicht bzw. erst mit der nächsten Klonerei),
kann für Software-Stabilitätsprobleme sorgen, im blödsten Fall gar
Datenverlust durch amoklaufende Software. Später dann, nachdem man vom
Klon gebootet hat.
D.h. der Klon mag zwar 100% bootbar sein aber eben nicht frei von
Inkonsistenzen. Und die ganzen Klon-Fetischisten wollen sich ja nicht
mit technischen Details beschäftigen sondern hängen sich einfach nur an
dem -- falschen -- Versprechen auf: 1:1-Klon, dann *muß* alles passen.
Die Logik dahinter stimmt ja eigentlich auch, was halt leider nicht
paßt, sind die dazu nötigen Randbedingungen, die unter OS X auch anno
2015 nicht mal ansatzweise erfüllt sind. Windows hat das dafür nötige
seit XP, OS X genau gar nix.
Gruss,
Thomas
Fritz
Nov 13, 2015, 10:52:59 AM11/13/15
to
Am 13.11.15 um 10:31 schrieb Dirk Wagner:
Bei mir waren es Unterschiede in den Unterordner vom Thunderbird
User-Verzeichnis.
Was mich veranlasste die wichtigen Ablagen zu vergleichen.
Ich verwende tagsüber beide TM Backup USB Festplatten abwechselnd - aber
niemals sind Beide angeschlossen.
User-Verzeichnis.
Was mich veranlasste die wichtigen Ablagen zu vergleichen.
Ich verwende tagsüber beide TM Backup USB Festplatten abwechselnd - aber
niemals sind Beide angeschlossen.
Fritz
Nov 13, 2015, 11:05:31 AM11/13/15
to
Am 13.11.15 um 13:19 schrieb Dirk Wagner:
von Mail.app oder Outlook.app - besonders wenn deren archivierte Anzahl
in die tausende geht.
Wichtig sind mir Fotos und Word/Excel Dokumente.
Wobei der Vergleich von iPhoto Datenbanken nicht gerade einfach ist.
Ich habe mir da letztendlich so geholfen - von den anderen iPhoto
Datenbanken den Foto Verzeichnisbaum (die Originale) heraus kopiert und
diesen erneut in iPhoto importiert - Duplikate nicht importieren angehakt.
Ich benutze den Mac aber nicht beruflich.
> Ich habe als Ergänzung zum TM-Backup auch teile meiner Daten immer
> wieder auf externe Daten kopiert.
> Aber dabei verliert man irgendwann den Überlick und so häufen sich alte
> Daten in unkontrolierbarer Menge an.
Das kenne ich auch - und wer vergleicht schon den kompletten Mailbestand
> wieder auf externe Daten kopiert.
> Aber dabei verliert man irgendwann den Überlick und so häufen sich alte
> Daten in unkontrolierbarer Menge an.
von Mail.app oder Outlook.app - besonders wenn deren archivierte Anzahl
in die tausende geht.
Wichtig sind mir Fotos und Word/Excel Dokumente.
Wobei der Vergleich von iPhoto Datenbanken nicht gerade einfach ist.
Ich habe mir da letztendlich so geholfen - von den anderen iPhoto
Datenbanken den Foto Verzeichnisbaum (die Originale) heraus kopiert und
diesen erneut in iPhoto importiert - Duplikate nicht importieren angehakt.
Ich benutze den Mac aber nicht beruflich.
Fritz
Nov 13, 2015, 11:23:20 AM11/13/15
to
Am 13.11.15 um 11:33 schrieb Joe Kotroczo:
korrupten Dateien bestünde, wirds haarig ....
Ich hatte mal Probleme mit meinem 15" MBP, da kopierte ich halt die
wichtigsten Dateien und Verzeichnisse vom letzten TM Backup auf das 13"
MB (u.a. auch Reservegerät) und ich konnte weiter arbeiten.
Outlook 2011, Thunderbird, Firefox Datenbestände sind da kein Problem.
Als das 15" MBP wieder funktionierte kopierte ich einfach diese
Verzeichnisse vom 13" MP anstelle der vom TM Restore zurück - alles lief
wieder wie gehabt.
> Ich weiß halt nur nicht welches ich im Schadensfall zuerst zurückspielen
> würde, ich ahne daß das in eine Order-Vergleichs-Orgie ausarten würde.
Das hängt auch von der Art des Schadens ab, wenn die Gefahr von
> würde, ich ahne daß das in eine Order-Vergleichs-Orgie ausarten würde.
korrupten Dateien bestünde, wirds haarig ....
Ich hatte mal Probleme mit meinem 15" MBP, da kopierte ich halt die
wichtigsten Dateien und Verzeichnisse vom letzten TM Backup auf das 13"
MB (u.a. auch Reservegerät) und ich konnte weiter arbeiten.
Outlook 2011, Thunderbird, Firefox Datenbestände sind da kein Problem.
Als das 15" MBP wieder funktionierte kopierte ich einfach diese
Verzeichnisse vom 13" MP anstelle der vom TM Restore zurück - alles lief
wieder wie gehabt.
Goetz Hoffart
Nov 13, 2015, 3:12:19 PM11/13/15
to
Joe Kotroczo <kotr...@mac.com> wrote:
> daß TimeMachine Nutzdaten die man eigentlich sichern wollte nicht sichert
Ja, in Mac OS X 10.5 Server wurden die Mailserver-Daten-Verzeichnisse
> daß TimeMachine Nutzdaten die man eigentlich sichern wollte nicht sichert
nicht gesichert. Aber sowas ist lang her.
Grüße
Götz
--
http://www.knubbelmac.de/
Maurice Bonnet
Nov 14, 2015, 2:12:15 AM11/14/15
to
Am 12.11.15 um 22:59 schrieb Thomas Kaiser:
> -- schön rotieren und immer wieder bei null anfangen je Medium.
Was heißt das? Medium löschen und komplettes TM-Backup drauf? Dann kann
aber die durchaus vernünftige Strategie "Große TM-Platte, um lange
Versionierung vorhalten zu können" nicht gefahren werden.
Mir ist auch schon mherfach das TM-Backup abgeschmiert (also nicht mehr
zugänglich). Wenn TM so anfällig ist für einen Betrieb über einen langen
Zeitraum, dann ist es als BackUp-Tool wirklich nur bedingt brauchbar.
Ich nutze es auch (mit 2 Medien), aber ohne einen Klon noch nebenher zu
haben, ist mir das zu riskant. Wenn es nur darum geht, mal eine Datei
wiederherzustellen - Time Machine super (wenn sie geht). Aber um das
komplette System wiederherzustellen (z.B. Festplattentausch) nur auf TM
zu verlassen - niemals.
Grüße
Maurice
Maurice Bonnet
Nov 14, 2015, 3:45:01 AM11/14/15
to
Am 13.11.15 um 13:46 schrieb Thomas Kaiser:
> Also
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
Klon vom ruhenden System mache ich schon. Ich nutze die drei Anwendungen
> System runterfahren, in die Recovery Partition booten, Klon-Platte
> anschließen, klonen lassen. Und dann weiterarbeiten. Macht kein Mensche,
TM, Migrationsassistent und Klon in folgenden Settings (ich habe nur
beschränkte Anzahl an Festplatten, die mir die 1 TB meines Macs schlucken):
Kauf eines neuen Rechners: Migrationsassistent
Wiederherstellung verlorener Daten: Time Machine
Einbau neuer Festplatte:
vor Umbau Klon aus dem laufenden System (dann habe ich schonmal 99 %,
falls im folgenden Prozess irgendwas komplett schief geht, TM hab eich
ja auch noch) auf externe Festplatte,
Booten von dieser externen Festplatte und dann mit Klon-Tool die interne
Platte auf die neue Platte, die ebenfalls extern am Rechner hängt, klonen.
Eibau der neuen Platte - fertig.
Regelmäßig mache ich auch immer wieder einen Smart-Klon (mit
Super-Duper), falls die 2 TM-Medien mal komplett ausfallen.
Ein Klon steht noch bei meiner Mutter, falls mal die Bude abbrennt. In
10 Jahren Lehrertätigkeit hat sich allerhand an Unterrichtsvorbereitung
etc. auf dem Rechner gesammelt. Wäre der Mega-Gau, wenn das irgendwie
vernichtet wäre.
Da schon mehr als einmal die TM-Platte komplett nicht ansprechbar war,
traue ich TM nur bedingt. Ja, Prävention kann gut sein, schütz aber
nicht 100 % davor, dass *irgendwann* völlig unerwartet die Krankheit
ausbricht. Aber das gilt für jedes Szenario.
Grüße
Maurice
Dirk Wagner
Nov 14, 2015, 4:08:18 AM11/14/15
to
Ich habe mir gestern mal die Backupplatten angeschaut:
Im Ordner
Backups.backupdb gibt es den Ordner
"g5" - so heißt der zu sichernde Rechner.
Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
trägt.
Also z.B. 2015-10-22-144738
Weiterhin auf jeder Platten ein Datei namens (z.B.)
2015-10-25-145428.inProgress
und den Link "Latest".
DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
bereitgehalten wird.
Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
2015-10-22-144738
Eigenartig ist für mich aber nach wie vor die Zusammensetzung der Daten
in der Sicherung.
So sind eigentlich alle "alten" Daten gesichert.
Also alles von vor 2012.
Danach ist z.B. in Bezug auf REchnungen, Briefen u.ä. auch alles
verfügbar.
Aber Bilder (egal in welchem Dateiformat) nur teilweise.
im Ordner "diverses" liegen 8 Bilder 4 aus dem August 2014, 2 aus 2011,
und je eines aus 2010 und 1006. Auch die Daten der letzten Änderung oder
des letzten Öffnen liegen in den entsprechenden Jahren.
Die restlichen (geschätzt über 1000 Bilder) sind nicht da.
Gleiches im Ordner "Fahrräder".
Bilder aus 2005, 2011 und 2015 - aber bei weitem nicht alle.
So weiß ich, dass ich 2011 ALLE meine Räder fotografiert habe.
Da müssten allein aus den Sommermonaten mehr als 100 Dateien vorhanden
sein.
Die in 2012 und 2014 neu angeschaften und fotografierten Räder finden
sich gar nicht...
Im "Urlaube" Ordner finden sich keine 20 Unterordner sondern nur noch 2
aus 2014.
Wobei im 2014er Ordner nur noch 5 und nicht 1200 Bilder liegen.
Allerdings sieht es so aus, als seien die in der obersten Ebene von
"Bilder" liegenden Dateien alle da.
Aber nur die Dateien, nicht die Ordner.
So findet sich der Ordner mit den Original-RAW Dateien NIRGENS.
Diesen ORdner habe ich zuletzt im April geändert.
Das alles ist sehr eigenartig - und folgt keinem Muster, das ich auf
Anhieb erkennen würde.
Ich habe über Nacht mal auf der Backup-Platte nach gelöschten DAteien
gesucht und auf diese Art ca. 3500 RAW-DAteien gefunden.
Sowie noch mal deutlich mehr DAteieinträge, die aber auf keine gültigen
Dateien mehr verwiesen.
Im Moment lasse ich die Platte am iMac durchsuchen. Beim
Wiederherstellen des TM-Backups wurde zwar die Platte gelöscht - aber
ich gehe mal davon aus, dass hier kein sicheres Löschen stattfand - und
da im Moment noch ca. die Hälfte der Platte nicht belegt ist, besteht
zumindest die Chance, da noch was zu finden...
Ciao
dirk
Im Ordner
Backups.backupdb gibt es den Ordner
"g5" - so heißt der zu sichernde Rechner.
Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
trägt.
Also z.B. 2015-10-22-144738
Weiterhin auf jeder Platten ein Datei namens (z.B.)
2015-10-25-145428.inProgress
und den Link "Latest".
DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
bereitgehalten wird.
Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
2015-10-22-144738
Eigenartig ist für mich aber nach wie vor die Zusammensetzung der Daten
in der Sicherung.
So sind eigentlich alle "alten" Daten gesichert.
Also alles von vor 2012.
Danach ist z.B. in Bezug auf REchnungen, Briefen u.ä. auch alles
verfügbar.
Aber Bilder (egal in welchem Dateiformat) nur teilweise.
im Ordner "diverses" liegen 8 Bilder 4 aus dem August 2014, 2 aus 2011,
und je eines aus 2010 und 1006. Auch die Daten der letzten Änderung oder
des letzten Öffnen liegen in den entsprechenden Jahren.
Die restlichen (geschätzt über 1000 Bilder) sind nicht da.
Gleiches im Ordner "Fahrräder".
Bilder aus 2005, 2011 und 2015 - aber bei weitem nicht alle.
So weiß ich, dass ich 2011 ALLE meine Räder fotografiert habe.
Da müssten allein aus den Sommermonaten mehr als 100 Dateien vorhanden
sein.
Die in 2012 und 2014 neu angeschaften und fotografierten Räder finden
sich gar nicht...
Im "Urlaube" Ordner finden sich keine 20 Unterordner sondern nur noch 2
aus 2014.
Wobei im 2014er Ordner nur noch 5 und nicht 1200 Bilder liegen.
Allerdings sieht es so aus, als seien die in der obersten Ebene von
"Bilder" liegenden Dateien alle da.
Aber nur die Dateien, nicht die Ordner.
So findet sich der Ordner mit den Original-RAW Dateien NIRGENS.
Diesen ORdner habe ich zuletzt im April geändert.
Das alles ist sehr eigenartig - und folgt keinem Muster, das ich auf
Anhieb erkennen würde.
Ich habe über Nacht mal auf der Backup-Platte nach gelöschten DAteien
gesucht und auf diese Art ca. 3500 RAW-DAteien gefunden.
Sowie noch mal deutlich mehr DAteieinträge, die aber auf keine gültigen
Dateien mehr verwiesen.
Im Moment lasse ich die Platte am iMac durchsuchen. Beim
Wiederherstellen des TM-Backups wurde zwar die Platte gelöscht - aber
ich gehe mal davon aus, dass hier kein sicheres Löschen stattfand - und
da im Moment noch ca. die Hälfte der Platte nicht belegt ist, besteht
zumindest die Chance, da noch was zu finden...
Ciao
dirk
Guenther Fischer
Nov 14, 2015, 5:40:14 AM11/14/15
to
In article <slrnn4bur5.1ra...@phg-online.de>, Thomas Kaiser
Will hier nur mal kurz anmerken, dass Clone X4 ein recht braucbares
Tool zur Anfertigung von bootbaren Clones ist. Hat sich bei mir seit
Jahren bewährt. Gekauft hatte ich es mal zusammen mit einem anderen
Programm als "Zugabe". Ist das Geld aber wert, wenn man mal die mit OSX
kostenlos mitgelieferten Tools ausser Acht lässt.
Was Thomas hier beschreibt, ist absolut richtig. Clone X4 erlaubt daher
gar kein Clonen von laufenden Systemen. Die Konfiguration ist zudem
denkbar einfach. Wer will, kann hinterher sogar vergleichen, ob
Original und Clone identisch sind oder nicht.
Tool zur Anfertigung von bootbaren Clones ist. Hat sich bei mir seit
Jahren bewährt. Gekauft hatte ich es mal zusammen mit einem anderen
Programm als "Zugabe". Ist das Geld aber wert, wenn man mal die mit OSX
kostenlos mitgelieferten Tools ausser Acht lässt.
Was Thomas hier beschreibt, ist absolut richtig. Clone X4 erlaubt daher
gar kein Clonen von laufenden Systemen. Die Konfiguration ist zudem
denkbar einfach. Wer will, kann hinterher sogar vergleichen, ob
Original und Clone identisch sind oder nicht.
Thomas Kaiser
Nov 14, 2015, 5:53:28 AM11/14/15
to
Maurice Bonnet schrieb in <news:n26msf$oe9$1...@news.albasani.net>
Finder. Geht darum, ein Dateisystem _extra vergine_ zu bekommen.
> Dann kann aber die durchaus vernünftige Strategie "Große TM-Platte, um
> lange Versionierung vorhalten zu können" nicht gefahren werden.
Das ist nicht vernünftig sondern konzeptioneller Mißbrauch. TimeMachine
ist Backup und nicht Archiv. Wer diesen Unterschied ignoriert wird
scheitern. Die Backup-Medien sollten größer sein (125%-150% -- hängt
aber halt von den Änderungs-Deltas ab, die so auftreten) weil sonst das
mit der Versionierung nicht klappt. Aber da die Backups irgendwann wenn
der Platz nicht mehr reicht automatisch ausgedünnt werden, *darf* man
TimeMachine nicht für Archivzwecke mißbrauchen. Weil ein Archiv per
Definition nicht geändert werden darf, TimeMachine aber das Gegenteil
macht: Es schmeißt "von hinten" anfangen Sachen aus dem Backup raus. Was
richtig ist, weil es um Backup und nicht Archiv geht!
Und "der Platz reicht nicht mehr aus", kann einfach so aus dem Nichts
auftreten, bspw. wenn irgendeine Malware anfängt, alle Dateien auf dem
zu sichernden Datenbestand zu manipulieren. Dann muß alles gesichert
werden --> zu wenig Platz --> alte Versionen wegschmeißen, da die
Strategie bei Backup immer ist, die *frischesten* Sachen in möglichst
vielen Versionen aufzubewahren. Bei Archiv geht es darum, *alles* und
vor allem auch Uraltes zu bewahren. Geht mit Backup-Konzepten *nie*.
Gruss,
Thomas
> Am 12.11.15 um 22:59 schrieb Thomas Kaiser:
>> -- schön rotieren und immer wieder bei null anfangen je Medium.
>
> Was heißt das? Medium löschen und komplettes TM-Backup drauf?
Ja. Und zwar im Festplatten-Dienstprogramm löschen, nicht den Inhalt im
>> -- schön rotieren und immer wieder bei null anfangen je Medium.
>
> Was heißt das? Medium löschen und komplettes TM-Backup drauf?
Finder. Geht darum, ein Dateisystem _extra vergine_ zu bekommen.
> Dann kann aber die durchaus vernünftige Strategie "Große TM-Platte, um
> lange Versionierung vorhalten zu können" nicht gefahren werden.
ist Backup und nicht Archiv. Wer diesen Unterschied ignoriert wird
scheitern. Die Backup-Medien sollten größer sein (125%-150% -- hängt
aber halt von den Änderungs-Deltas ab, die so auftreten) weil sonst das
mit der Versionierung nicht klappt. Aber da die Backups irgendwann wenn
der Platz nicht mehr reicht automatisch ausgedünnt werden, *darf* man
TimeMachine nicht für Archivzwecke mißbrauchen. Weil ein Archiv per
Definition nicht geändert werden darf, TimeMachine aber das Gegenteil
macht: Es schmeißt "von hinten" anfangen Sachen aus dem Backup raus. Was
richtig ist, weil es um Backup und nicht Archiv geht!
Und "der Platz reicht nicht mehr aus", kann einfach so aus dem Nichts
auftreten, bspw. wenn irgendeine Malware anfängt, alle Dateien auf dem
zu sichernden Datenbestand zu manipulieren. Dann muß alles gesichert
werden --> zu wenig Platz --> alte Versionen wegschmeißen, da die
Strategie bei Backup immer ist, die *frischesten* Sachen in möglichst
vielen Versionen aufzubewahren. Bei Archiv geht es darum, *alles* und
vor allem auch Uraltes zu bewahren. Geht mit Backup-Konzepten *nie*.
Gruss,
Thomas
Thomas Kaiser
Nov 14, 2015, 6:10:15 AM11/14/15
to
Dirk Wagner schrieb in <news:1mdveye.1tsuvi8kuxyisN%usenet...@diwasoft.de>
> und den Link "Latest".
Der zeigt hoffentlich auf den anderen Ordner? Also 2015-10-22-144738?
> DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
> bereitgehalten wird.
Schlimmer: Das bedeutet, dass bei Dir gar kein aktuelles Backup gemacht
wurde. Und das auf allen drei Platten. Versuch mal, in den inProgress
reinzuwandern (rechter Mausklick und gucken, ob da was geht, ansonssten
gleich in der Shell als root reinhüpfen), stell den Inhalt der da drin
liegenden Log-Datei auf pastebin.com und schieb den Link dazu hierher.
Die Log-Datei ist aus dem Finder heraus vermutlich nicht zu sehen, weil
ihr Name mit 'nem Punkt beginnt: .Backup.log -- wenn bei Dir an dem
Namen aber noch ein Wust aus Zahlen dranhängt (was ich aktuell leider
vermuten würde), bspw. .Backup.469191863.228403.log dann ist das ein
Indiz dafür, dass das Backup nie fertig wurde (evtl. weil der backupd
immer beim Sichern der selben Datei einfach gecrasht ist -- das Log
hilft da evtl.)
Ach ja, der Inhalt von .com.apple.TMCheckpoint wäre auch gleich noch
interessant, falls die Datei da drinliegt.
Gruss,
Thomas
> Ich habe mir gestern mal die Backupplatten angeschaut:
> Im Ordner
>
> Backups.backupdb gibt es den Ordner
> "g5" - so heißt der zu sichernde Rechner.
> Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
> trägt.
> Also z.B. 2015-10-22-144738
>
> Weiterhin auf jeder Platten ein Datei namens (z.B.)
> 2015-10-25-145428.inProgress
Das sollte keine Datei sein sondern ein Verzeichnis.
> Im Ordner
>
> Backups.backupdb gibt es den Ordner
> "g5" - so heißt der zu sichernde Rechner.
> Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
> trägt.
> Also z.B. 2015-10-22-144738
>
> Weiterhin auf jeder Platten ein Datei namens (z.B.)
> 2015-10-25-145428.inProgress
> und den Link "Latest".
> DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
> bereitgehalten wird.
wurde. Und das auf allen drei Platten. Versuch mal, in den inProgress
reinzuwandern (rechter Mausklick und gucken, ob da was geht, ansonssten
gleich in der Shell als root reinhüpfen), stell den Inhalt der da drin
liegenden Log-Datei auf pastebin.com und schieb den Link dazu hierher.
Die Log-Datei ist aus dem Finder heraus vermutlich nicht zu sehen, weil
ihr Name mit 'nem Punkt beginnt: .Backup.log -- wenn bei Dir an dem
Namen aber noch ein Wust aus Zahlen dranhängt (was ich aktuell leider
vermuten würde), bspw. .Backup.469191863.228403.log dann ist das ein
Indiz dafür, dass das Backup nie fertig wurde (evtl. weil der backupd
immer beim Sichern der selben Datei einfach gecrasht ist -- das Log
hilft da evtl.)
Ach ja, der Inhalt von .com.apple.TMCheckpoint wäre auch gleich noch
interessant, falls die Datei da drinliegt.
Gruss,
Thomas
Wolfgang Kommere||
Nov 14, 2015, 6:55:44 AM11/14/15
to
Guenther Fischer <ne...@spam.invalid> wrote:
> Will hier nur mal kurz anmerken, dass Clone X4 ein recht braucbares
> Tool zur Anfertigung von bootbaren Clones ist. Hat sich bei mir seit
> Jahren bewährt. Gekauft hatte ich es mal zusammen mit einem anderen
> Programm als "Zugabe". Ist das Geld aber wert, wenn man mal die mit OSX
> kostenlos mitgelieferten Tools ausser Acht lässt.
> Was Thomas hier beschreibt, ist absolut richtig. Clone X4 erlaubt daher
> gar kein Clonen von laufenden Systemen. Die Konfiguration ist zudem
> denkbar einfach. Wer will, kann hinterher sogar vergleichen, ob
> Original und Clone identisch sind oder nicht.
Was wäre denn der konkrete Vorteil gegenüber dem
> Will hier nur mal kurz anmerken, dass Clone X4 ein recht braucbares
> Tool zur Anfertigung von bootbaren Clones ist. Hat sich bei mir seit
> Jahren bewährt. Gekauft hatte ich es mal zusammen mit einem anderen
> Programm als "Zugabe". Ist das Geld aber wert, wenn man mal die mit OSX
> kostenlos mitgelieferten Tools ausser Acht lässt.
> Was Thomas hier beschreibt, ist absolut richtig. Clone X4 erlaubt daher
> gar kein Clonen von laufenden Systemen. Die Konfiguration ist zudem
> denkbar einfach. Wer will, kann hinterher sogar vergleichen, ob
> Original und Clone identisch sind oder nicht.
Festplattendienstprogramm?
W.
Iwan
Nov 14, 2015, 8:24:10 AM11/14/15
to
Am 14.11.2015, 11:53 Uhr, schrieb Thomas Kaiser
<Thomas...@phg-online.de>:
Es waere ein bissel mehr Arbeit, aber wenn ich vor dem Backup (z.B. mit
CCC) von einer anderen bootfaehigen Platte starte, sollte ich dann nicht
von der (dann ruhenden) Rechner-Festplatte ein komplettes Backup schaffen?
Peter
--
Support NSA and GCHQ - Write in English
Soutiens DGSE - Écris en français
<Thomas...@phg-online.de>:
CCC) von einer anderen bootfaehigen Platte starte, sollte ich dann nicht
von der (dann ruhenden) Rechner-Festplatte ein komplettes Backup schaffen?
Peter
--
Support NSA and GCHQ - Write in English
Soutiens DGSE - Écris en français
Guenther Fischer
Nov 14, 2015, 8:50:28 AM11/14/15
to
In article <1mdvnw0.16j99231tpj3fjN%wolk...@arcor.de>, Wolfgang
Clone X 4 vergleicht zwei Volumes (Clone und Original) und legt auch
ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
ist bequem und zuverlässig....
ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
ist bequem und zuverlässig....
Thomas Kaiser
Nov 14, 2015, 9:18:49 AM11/14/15
to
Iwan schrieb in <news:op.x73d6...@macbook-pro.fritz.box>
mit Backup nix zu tun.
> (z.B. mit CCC) von einer anderen bootfaehigen Platte starte, sollte
> ich dann nicht von der (dann ruhenden) Rechner-Festplatte ein
> komplettes Backup schaffen?
Ja, nur wozu der Zirkus? Wenn ich sichergehen will, einen 1:1-Klon zu
erzeugen, dann starte ich den Mac per [cmr]-[r] aus der Recovery
Partition, starte das Festplatten-Dienstprogramm und erstelle dort über
die "Wiederherstellen"-Funktion einen blockweisen Klon auf ein zweites
Medium (inkl. aller Dateisystemfehler, etc. pp. -- das ist dann wirklich
das, wovon die "ein Klon ist toller als ein Backup"-Fraktion immer und
ausschließlich sabbernd träumt: Eine 1:1-Kopie, die anschl. wirklich
identisch ist)
Wenn Du den CCC nimmst (oder SuperDuper! oder egal welche andere
Software, die Dir "1:1-Klonerei" verspricht), dann macht der keine
1:1-Kopie, weil er sinnigerweise Zeugs ausläßt -- alle die Macher von
solchen Tools haben schmerzhaft lernen müssen, dass wenn man oberhalb
des Dateisystems in der Gegend herumsynct, dann Sachen weglassen muß,
damit das Ziel -- ein sicher bootbares System -- erreicht werden kann)
Der CCC bzw. das OpenSource-Werkzeug, auf das er aufsetzt, geht halt
effizienter vor. Denn rsync, das die eigentliche Arbeit macht, checkt
anhand Dateisystem-Metadaten, was sich seit dem letzten Sync-Lauf
geändert hat, und synct nur das dann bzw. anhand eines Checksummen-
Algorithmus tatsächlich nur die geänderten Blöcke zwischen Quelle und
Ziel). Kriegt man damit eine 1:1-Kopie? Nein, denn wenn bspw. aus
welchen Gründen auch immer an der Quelle Dateiinhalte geändert wurden,
sich die Dateigröße nicht geändert hat und das Modifikationsdatum gleich
blieb [1], dann erkennt der CCC nicht, dass sich was geändert hat.
Abhilfe: Man muß für das Erkennen von Änderungen schon auf Checksummen
setzen, was das Ganze länger dauern läßt und bedeutet, dass alle Dateien
an Quelle und Ziel gelesen werden müssen (CCC nutzt dann die rsync-
Option "--checksum")
Hat man dann wirklich eine 1:1-Kopie? Nein, weil weiß man ja nicht, ob
Quelle und Ziel nun wirklich identisch sind. Muß man also verifizieren,
d.h. direkt danach den selben Zirkus nochmal, also erneut nochmal alle
Dateien an Quelle und Ziel lesen lassen, Checksummen kalkulieren, und
bei Abweichungen in den "Alarm-Modus" gehen, denn wenn jetzt was
abweichen sollte, dann hat man es bereits mit Datenkorrumption zu tun).
Steht auch alles so im Kleingedruckten:
https://bombich.com/kb/ccc4/advanced-settings
Und wer der CCC- oder SuperDuper!-Anwender und Backup-Verachter macht
das? Richtig, genau niemand, weil sich alle nur im wohlig warmen Gefühl,
"mit 'nem Klon, da biste sicher, mit 'nem Klon biste gut drauf" suhlen
und sich einen Dreck drum scheren, ob das so tut, wie es soll, oder
nicht. Das ist alles nur Bedienen des Bauchgefühls "Jetzt hab' ich genug
zwengs Datensicherheit getan!"
Ein Klon hat mit Backup nix zu tun. Nie! Und ein funktionierendes Backup
definiert sich einzig und alleine aus der Fähigkeit heraus, in einer
definierten Zeitspanne wieder herstellbar zu sein. Es ist der Restore,
der darüber entscheidet, ob das Backup was taugt. Und die simple
Konsequenz daraus ist leider, dass man den Restore halt nunmal auch
testen muß. Sonst hat man keine Ahnung, was mit dem Backup eigentlich
los ist. Wird in Dirks Ohren jetzt schon bisserl zynisch klingen. Aber
vom rein technischen Standpunkt her ist das halt leider so.
Gruss,
Thomas
[1] Wir machen das in ein paar Workflows so, dass wir in Dateien
Änderungen vornehmen aber die Zeitstempel nicht ändern dürfen. Weil
sonst ein "Media Asset Management" System (neudeutsch für Bild-
datenbank) aus dem Tritt kommt zwengs Duplikat-Erkennung. Sowas kann
also durchaus im echten Leben vorkommen. Die ganzen Klonprogramme
laufen dann ins Leere, TM aber würde es sichern, denn das hat die
Änderung über den fsevents-Mechanismus mitgeschnitten.
> Es waere ein bissel mehr Arbeit, aber wenn ich vor dem Backup
Du machst kein Backup. Du erstellst *nur* einen bootbaren Klon. Das hat
mit Backup nix zu tun.
> (z.B. mit CCC) von einer anderen bootfaehigen Platte starte, sollte
> ich dann nicht von der (dann ruhenden) Rechner-Festplatte ein
> komplettes Backup schaffen?
erzeugen, dann starte ich den Mac per [cmr]-[r] aus der Recovery
Partition, starte das Festplatten-Dienstprogramm und erstelle dort über
die "Wiederherstellen"-Funktion einen blockweisen Klon auf ein zweites
Medium (inkl. aller Dateisystemfehler, etc. pp. -- das ist dann wirklich
das, wovon die "ein Klon ist toller als ein Backup"-Fraktion immer und
ausschließlich sabbernd träumt: Eine 1:1-Kopie, die anschl. wirklich
identisch ist)
Wenn Du den CCC nimmst (oder SuperDuper! oder egal welche andere
Software, die Dir "1:1-Klonerei" verspricht), dann macht der keine
1:1-Kopie, weil er sinnigerweise Zeugs ausläßt -- alle die Macher von
solchen Tools haben schmerzhaft lernen müssen, dass wenn man oberhalb
des Dateisystems in der Gegend herumsynct, dann Sachen weglassen muß,
damit das Ziel -- ein sicher bootbares System -- erreicht werden kann)
Der CCC bzw. das OpenSource-Werkzeug, auf das er aufsetzt, geht halt
effizienter vor. Denn rsync, das die eigentliche Arbeit macht, checkt
anhand Dateisystem-Metadaten, was sich seit dem letzten Sync-Lauf
geändert hat, und synct nur das dann bzw. anhand eines Checksummen-
Algorithmus tatsächlich nur die geänderten Blöcke zwischen Quelle und
Ziel). Kriegt man damit eine 1:1-Kopie? Nein, denn wenn bspw. aus
welchen Gründen auch immer an der Quelle Dateiinhalte geändert wurden,
sich die Dateigröße nicht geändert hat und das Modifikationsdatum gleich
blieb [1], dann erkennt der CCC nicht, dass sich was geändert hat.
Abhilfe: Man muß für das Erkennen von Änderungen schon auf Checksummen
setzen, was das Ganze länger dauern läßt und bedeutet, dass alle Dateien
an Quelle und Ziel gelesen werden müssen (CCC nutzt dann die rsync-
Option "--checksum")
Hat man dann wirklich eine 1:1-Kopie? Nein, weil weiß man ja nicht, ob
Quelle und Ziel nun wirklich identisch sind. Muß man also verifizieren,
d.h. direkt danach den selben Zirkus nochmal, also erneut nochmal alle
Dateien an Quelle und Ziel lesen lassen, Checksummen kalkulieren, und
bei Abweichungen in den "Alarm-Modus" gehen, denn wenn jetzt was
abweichen sollte, dann hat man es bereits mit Datenkorrumption zu tun).
Steht auch alles so im Kleingedruckten:
https://bombich.com/kb/ccc4/advanced-settings
Und wer der CCC- oder SuperDuper!-Anwender und Backup-Verachter macht
das? Richtig, genau niemand, weil sich alle nur im wohlig warmen Gefühl,
"mit 'nem Klon, da biste sicher, mit 'nem Klon biste gut drauf" suhlen
und sich einen Dreck drum scheren, ob das so tut, wie es soll, oder
nicht. Das ist alles nur Bedienen des Bauchgefühls "Jetzt hab' ich genug
zwengs Datensicherheit getan!"
Ein Klon hat mit Backup nix zu tun. Nie! Und ein funktionierendes Backup
definiert sich einzig und alleine aus der Fähigkeit heraus, in einer
definierten Zeitspanne wieder herstellbar zu sein. Es ist der Restore,
der darüber entscheidet, ob das Backup was taugt. Und die simple
Konsequenz daraus ist leider, dass man den Restore halt nunmal auch
testen muß. Sonst hat man keine Ahnung, was mit dem Backup eigentlich
los ist. Wird in Dirks Ohren jetzt schon bisserl zynisch klingen. Aber
vom rein technischen Standpunkt her ist das halt leider so.
Gruss,
Thomas
[1] Wir machen das in ein paar Workflows so, dass wir in Dateien
Änderungen vornehmen aber die Zeitstempel nicht ändern dürfen. Weil
sonst ein "Media Asset Management" System (neudeutsch für Bild-
datenbank) aus dem Tritt kommt zwengs Duplikat-Erkennung. Sowas kann
also durchaus im echten Leben vorkommen. Die ganzen Klonprogramme
laufen dann ins Leere, TM aber würde es sichern, denn das hat die
Änderung über den fsevents-Mechanismus mitgeschnitten.
Fritz
Nov 14, 2015, 9:31:22 AM11/14/15
to
Am 14.11.15 um 14:50 schrieb Guenther Fischer:
<http://www.tri-edre.fr/english/clonex.html>
So etwas suche ich auch
<http://www.tri-edre.fr/english/checkupdates.html>
Wie sieht es mit deren Software generell aus, empfehlenswert?
PS: Data Rescue kenne ich auch, aber nur in der Trial Version.
> Clone X 4 vergleicht zwei Volumes (Clone und Original) und legt auch
> ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
> ist bequem und zuverlässig....
Ist das deren Homepage?
> ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
> ist bequem und zuverlässig....
<http://www.tri-edre.fr/english/clonex.html>
So etwas suche ich auch
<http://www.tri-edre.fr/english/checkupdates.html>
Wie sieht es mit deren Software generell aus, empfehlenswert?
PS: Data Rescue kenne ich auch, aber nur in der Trial Version.
Thomas Kaiser
Nov 14, 2015, 10:29:32 AM11/14/15
to
Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
/usr/bin/rsync --version
rsync version 2.6.9 protocol version 29
Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
rsync version 3.0.6 protocol version 30
Man sollte sich daher den CCC schnappen und das da drinnen liegende
rsync nach /usr/local/bin/rsync kopieren. In der 4er-Version liegt es
ausschließlich 64-bittig in
Carbon Copy Cloner.app/Contents/MacOS/rsync
Daher besser die 3er schnappen, denn da liegt es als Universal Binary
(ppc, i386 und x86_64) vor:
Carbon Copy Cloner.app/Contents/MacOS/ccc_helper.app/Contents/MacOS/rsync
Das Ding ist statisch gelinkt, d.h. man sollte damit auch hübsch aus der
Recovery Partition heraus gebootet inkrementell rumsyncen können. Und
immer schön drandenken, auch --acls, --xattrs und --hfs-compression zu
verwenden.
Gruss,
Thomas
> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
> sich das dem CCC beiliegende rsync schnappen.
Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
> sich das dem CCC beiliegende rsync schnappen.
Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
/usr/bin/rsync --version
rsync version 2.6.9 protocol version 29
Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
rsync version 3.0.6 protocol version 30
Man sollte sich daher den CCC schnappen und das da drinnen liegende
rsync nach /usr/local/bin/rsync kopieren. In der 4er-Version liegt es
ausschließlich 64-bittig in
Carbon Copy Cloner.app/Contents/MacOS/rsync
Daher besser die 3er schnappen, denn da liegt es als Universal Binary
(ppc, i386 und x86_64) vor:
Carbon Copy Cloner.app/Contents/MacOS/ccc_helper.app/Contents/MacOS/rsync
Das Ding ist statisch gelinkt, d.h. man sollte damit auch hübsch aus der
Recovery Partition heraus gebootet inkrementell rumsyncen können. Und
immer schön drandenken, auch --acls, --xattrs und --hfs-compression zu
verwenden.
Gruss,
Thomas
Dirk Wagner
Nov 14, 2015, 11:18:35 AM11/14/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Schlimmer: Das bedeutet, dass bei Dir gar kein aktuelles Backup gemacht
> wurde. Und das auf allen drei Platten. Versuch mal, in den inProgress
> reinzuwandern (rechter Mausklick und gucken, ob da was geht, ansonssten
> gleich in der Shell als root reinhüpfen), stell den Inhalt der da drin
> liegenden Log-Datei auf pastebin.com und schieb den Link dazu hierher.
OK,
> Schlimmer: Das bedeutet, dass bei Dir gar kein aktuelles Backup gemacht
> wurde. Und das auf allen drei Platten. Versuch mal, in den inProgress
> reinzuwandern (rechter Mausklick und gucken, ob da was geht, ansonssten
> gleich in der Shell als root reinhüpfen), stell den Inhalt der da drin
> liegenden Log-Datei auf pastebin.com und schieb den Link dazu hierher.
Ich denke, die relevanten Teile sind diese hier:
>2015-10-22-15:48:16 - Starting backup
>Previous snapshot:
> /Volumes/TM_Backup_3TB_2/Backups.backupdb/g5/2015-10-22-144738
>Date of Previous snapshot: 1445518058560782
>Will use FS events for "Macintosh HD" (device: /dev/disk2 mount: '/'
fsUUID: DC83A54B-6A84-3D03-9E83-1619B1C3D79F eventDBUUID:
C5E4B437-63BB-4AA4-A998-BEF77D2B5016)
>Gathering events since 18147469125112632665.
>=== Starting backup loop #1 ===
> Will use IncrementalBackupCopier
>Running preflight for "Macintosh HD" (device: /dev/disk2 mount: '/'
fsUUID: DC83A54B-6A84-3D03-9E83-1619B1C3D79F eventDBUUID:
C5E4B437-63BB-4AA4-A998-BEF77D2B5016)
> Calculating size of changes
> Should copy 2784640 items (2.24 TB) representing 547672951
blocks of size 4096. 58030905 blocks available.
>Preflight complete for "Macintosh HD" (device: /dev/disk2 mount: '/'
fsUUID: DC83A54B-6A84-3D03-9E83-1619B1C3D79F eventDBUUID:
C5E4B437-63BB-4AA4-A998-BEF77D2B5016)
>Time elapsed: 26 minutes, 2.000 seconds
DIESE Platte hing am Rechner, als ich die Rechte auf Macintosh HD
geändert habe.
(siehe <1mcqnbv.r80n6p5kzgdmN%usenet...@diwasoft.de>)
Dateien mit geänderten Rechten möchte TimeMachine sicher - und das wohl
völlig zurecht...
Also habe ich mir mit dieser Aktion doppelt selbst ins Knie
geschossen...
> Die Log-Datei ist aus dem Finder heraus vermutlich nicht zu sehen, weil
> ihr Name mit 'nem Punkt beginnt: .Backup.log -- wenn bei Dir an dem
> Namen aber noch ein Wust aus Zahlen dranhängt (was ich aktuell leider
> vermuten würde), bspw. .Backup.469191863.228403.log dann ist das ein
> Indiz dafür, dass das Backup nie fertig wurde (evtl. weil der backupd
> immer beim Sichern der selben Datei einfach gecrasht ist -- das Log
> hilft da evtl.)
Aber die erste erklärt wohl das Problem...
> Ach ja, der Inhalt von .com.apple.TMCheckpoint wäre auch gleich noch
> interessant, falls die Datei da drinliegt.
Datei nicht.
Die anderen werde ich mir anschauen, wenn die Suche nach gelöschten
Dateien durch ist...
Immerhin zeigt das ganze, das mindestens zwei Backupmedien sinnvoll sind
- WENN man mitbekommt, dass man Mist gebaut hat.
Wenn nicht, wird der Mist auch auf die zweite Platte kopiert...
Und wenn die Kapazität dann nicht wirklich passt...
Nun ja. Hoffen wir, dass ich daraus gelernt habe ;-)
Und dass ich noch ein paar Daten retten kann.
Ciao
dirk
Gerald E:scher
Nov 14, 2015, 1:20:53 PM11/14/15
to
Thomas Kaiser schrieb am 14/11/2015 16:29:
> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
>> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
>> sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
>
> /usr/bin/rsync --version
> rsync version 2.6.9 protocol version 29
>
> Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
> rsync version 3.0.6 protocol version 30
rsync aus den Macports sieht darart aus:
> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
>> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
>> sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
>
> /usr/bin/rsync --version
> rsync version 2.6.9 protocol version 29
>
> Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
> rsync version 3.0.6 protocol version 30
| $ /opt/local/bin/rsync --version
| rsync version 3.1.1 protocol version 31
| Copyright (C) 1996-2014 by Andrew Tridgell, Wayne Davison, and others.
| Web site: http://rsync.samba.org/
| Capabilities:
| 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
| socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
| append, ACLs, xattrs, iconv, symtimes, no prealloc, file-flags,
| HFS-compression
| [...]
Sieht aus, als kann das alles für Klonerei am Mac nötige.
--
Gerald
Goetz Hoffart
Nov 14, 2015, 4:28:03 PM11/14/15
to
Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
> rsync aus den Macports sieht darart aus:
und aus Homebrew:
> rsync aus den Macports sieht darart aus:
gh@molly ~ %/usr/local/Cellar/rsync/3.1.1/bin/rsync --version
[1]
rsync version 3.1.1 protocol version 31
Copyright (C) 1996-2014 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, no prealloc, file-flags
Bis auf HFS-Compression alles bei.
Copyright (C) 1996-2014 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, no prealloc, file-flags
Juergen P. Meier
Nov 15, 2015, 1:46:33 AM11/15/15
to
Dirk Wagner <usenet...@diwasoft.de>:
> Weiterhin auf jeder Platten ein Datei namens (z.B.)
> 2015-10-25-145428.inProgress
>
> und den Link "Latest".
>
> DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
> bereitgehalten wird.
Nicht mal das. .inProgress sagt: noch nicht fertig!
> Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
> 2015-10-22-144738
Hmm. was sagt "df /Volumes/deine-tm-platte" in vollstaendig?
Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
> Eigenartig ist für mich aber nach wie vor die Zusammensetzung der Daten
> in der Sicherung.
> So sind eigentlich alle "alten" Daten gesichert.
> Also alles von vor 2012.
> Danach ist z.B. in Bezug auf REchnungen, Briefen u.ä. auch alles
> verfügbar.
> Ich habe über Nacht mal auf der Backup-Platte nach gelöschten DAteien
> gesucht und auf diese Art ca. 3500 RAW-DAteien gefunden.
> Sowie noch mal deutlich mehr DAteieinträge, die aber auf keine gültigen
> Dateien mehr verwiesen.
Hast du die Platte mal neu formatiert (Disk utility)?
> Im Moment lasse ich die Platte am iMac durchsuchen. Beim
> Wiederherstellen des TM-Backups wurde zwar die Platte gelöscht - aber
> ich gehe mal davon aus, dass hier kein sicheres Löschen stattfand - und
> da im Moment noch ca. die Hälfte der Platte nicht belegt ist, besteht
> zumindest die Chance, da noch was zu finden...
Was willst du wiederherstellen?
Disk Utility: TM-PArtition auf der TM-Platte sicher loeschen (reicht
einmal mit Null-bytes zu ueberschreiben), neu anlegen.
TM Backup starten und nachdem es fertig ist, nochmal schauen.
> Ich habe mir gestern mal die Backupplatten angeschaut:
> Im Ordner
>
> Backups.backupdb gibt es den Ordner
> "g5" - so heißt der zu sichernde Rechner.
> Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
> trägt.
> Also z.B. 2015-10-22-144738
Ein Indiz fuer Zu wenig Platz.
> Im Ordner
>
> Backups.backupdb gibt es den Ordner
> "g5" - so heißt der zu sichernde Rechner.
> Darin git es genau EINEN Ordner, der das Datum der jeweiligen Sicherung
> trägt.
> Also z.B. 2015-10-22-144738
> Weiterhin auf jeder Platten ein Datei namens (z.B.)
> 2015-10-25-145428.inProgress
>
> und den Link "Latest".
>
> DAS würde ich so interpretieren, dass da nur EINE Backupgeneration
> bereitgehalten wird.
> Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
> 2015-10-22-144738
Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
> Eigenartig ist für mich aber nach wie vor die Zusammensetzung der Daten
> in der Sicherung.
> So sind eigentlich alle "alten" Daten gesichert.
> Also alles von vor 2012.
> Danach ist z.B. in Bezug auf REchnungen, Briefen u.ä. auch alles
> verfügbar.
> Das alles ist sehr eigenartig - und folgt keinem Muster, das ich auf
> Anhieb erkennen würde.
Je nach dem wie TM im Detail vorgeht.
> Anhieb erkennen würde.
> Ich habe über Nacht mal auf der Backup-Platte nach gelöschten DAteien
> gesucht und auf diese Art ca. 3500 RAW-DAteien gefunden.
> Sowie noch mal deutlich mehr DAteieinträge, die aber auf keine gültigen
> Dateien mehr verwiesen.
> Im Moment lasse ich die Platte am iMac durchsuchen. Beim
> Wiederherstellen des TM-Backups wurde zwar die Platte gelöscht - aber
> ich gehe mal davon aus, dass hier kein sicheres Löschen stattfand - und
> da im Moment noch ca. die Hälfte der Platte nicht belegt ist, besteht
> zumindest die Chance, da noch was zu finden...
Disk Utility: TM-PArtition auf der TM-Platte sicher loeschen (reicht
einmal mit Null-bytes zu ueberschreiben), neu anlegen.
TM Backup starten und nachdem es fertig ist, nochmal schauen.
Dirk Wagner
Nov 15, 2015, 4:33:15 AM11/15/15
to
Juergen P. Meier <nospa...@jors.net> wrote:
>
> > Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
> > 2015-10-22-144738
>
> Hmm. was sagt "df /Volumes/deine-tm-platte" in vollstaendig?
> Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
An anderer Stelle, schrieb ich, dass TM versucht hat 2.24TB an Daten zu
>
> > Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
> > 2015-10-22-144738
>
> Hmm. was sagt "df /Volumes/deine-tm-platte" in vollstaendig?
> Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
sichern... Da ist klar, dass vorher alles gelöscht wird ;-/
> > Ich habe über Nacht mal auf der Backup-Platte nach gelöschten DAteien
> > gesucht und auf diese Art ca. 3500 RAW-DAteien gefunden.
> > Sowie noch mal deutlich mehr DAteieinträge, die aber auf keine gültigen
> > Dateien mehr verwiesen.
>
> Hast du die Platte mal neu formatiert (Disk utility)?
> > Im Moment lasse ich die Platte am iMac durchsuchen. Beim
> > Wiederherstellen des TM-Backups wurde zwar die Platte gelöscht - aber
> > ich gehe mal davon aus, dass hier kein sicheres Löschen stattfand - und
> > da im Moment noch ca. die Hälfte der Platte nicht belegt ist, besteht
> > zumindest die Chance, da noch was zu finden...
>
> Was willst du wiederherstellen?
gelöscht wurden.
TimeMachine geht sicher nicht her und überschreibt den leeren Platz auf
der Platte mit Nullen.
Ca. 600GB an Bilddateien habe ich bei einer Suche vorgestern gefunden.
> Disk Utility: TM-PArtition auf der TM-Platte sicher loeschen (reicht
> einmal mit Null-bytes zu ueberschreiben), neu anlegen.
> TM Backup starten und nachdem es fertig ist, nochmal schauen.
Damit JEDE Chance perdü ist, evtl auf der Platte noch vorhandene Daten
wieder herzustellen...
Wenn ich meine Daten unwiederholbar vernichten wollte, würde ich sicher
kein TM Backup davon erstellen und mich dann darüber wundern, dass dort
nicht mehr alles zu finden ist...
Ciao
dirk
Thomas Kaiser
Nov 15, 2015, 9:26:23 AM11/15/15
to
Gerald E:scher schrieb am 14.11.2015 in <news:20151114182054...@ID-37099.user.uni-berlin.de>
rsync --help | egrep "decmpfs|hfs-compression"
diesbzgl.?
Gruss,
Thomas
> rsync aus den Macports sieht darart aus:
Und was sagt ein
rsync --help | egrep "decmpfs|hfs-compression"
diesbzgl.?
Gruss,
Thomas
Guenther Fischer
Nov 15, 2015, 12:27:17 PM11/15/15
to
In article <n27gfg$nni$1...@fritzs.eternal-september.org>, Fritz
> So etwas suche ich auch
> <http://www.tri-edre.fr/english/checkupdates.html>
>
> Wie sieht es mit deren Software generell aus, empfehlenswert?
Kann ich wenig zu sagen. Clone X ist aber ok und wird gut gewartet.
<fr...@sea.nomail.invalid> wrote:
> Am 14.11.15 um 14:50 schrieb Guenther Fischer:
> > Clone X 4 vergleicht zwei Volumes (Clone und Original) und legt auch
> > ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
> > ist bequem und zuverlässig....
>
> Ist das deren Homepage?
> <http://www.tri-edre.fr/english/clonex.html>
Ja.
> Am 14.11.15 um 14:50 schrieb Guenther Fischer:
> > Clone X 4 vergleicht zwei Volumes (Clone und Original) und legt auch
> > ein Minimalsystem an, dasfür Servicezwecke hilfreich ist. Ansonsten? Es
> > ist bequem und zuverlässig....
>
> Ist das deren Homepage?
> <http://www.tri-edre.fr/english/clonex.html>
> So etwas suche ich auch
> <http://www.tri-edre.fr/english/checkupdates.html>
>
> Wie sieht es mit deren Software generell aus, empfehlenswert?
Başar Alabay
Nov 15, 2015, 12:42:38 PM11/15/15
to
Thomas Kaiser schrieb:
--hfs-compression preserve HFS compression if supported
--protect-decmpfs preserve HFS compression as xattrs
B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
--protect-decmpfs preserve HFS compression as xattrs
B. Alabay
--
http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
Juergen P. Meier
Nov 16, 2015, 12:56:31 AM11/16/15
to
Dirk Wagner <usenet...@diwasoft.de>:
Was genau willst du? Willst du eine neue Sicherung erstellen, oder
willst du verlorene Daten von der Sicherung wiederherstellen?
Deine Angaben diesbezueglich sind etwas konfus.
Entweder du willst eine Sicherung erstellen, dann solltest du die
offensichtlich problematische Platte komplett neu formatieren damit TM
ein frisches Backupmedium zur Verfuegung hat um eine vollstaendige und
saubere Sicherung zu erstellen - oder aber du willst Daten aus dem
letzten Backup wiederherstellen, die du aus irgendwelchen Gruenden
lokal verloren (geloescht) hast, dann solltest du tunlichst
verhindern, dass Timemachine von deinem System mit geloschten Daten
erneut versucht ein Backup auf die TM-Platte zu schreiben auf der
NICHT GENUG PLATZ* ist fuer zwei vollstaendige Generationen.
In letzterm Fall loescht TM genau dann vorhandene Daten aus deinem
letzten Backup, wenn der Platz fuer das Backup der aktuellen
Installation nicht mehr ausreichend scheint.
Und wenn du jetzt genau diese Daten noch brauchst, dann darfst du eben
*kein* erneutes Backup anstarten.
* TM sollte wegen genau dem Worst Case mindestens doppelt so gross
sein wie die zu sichernden Daten. Bei einem 2,5TB System also 5TB.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Juergen P. Meier <nospa...@jors.net> wrote:
>
>> > Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
>> > 2015-10-22-144738
>>
>> Hmm. was sagt "df /Volumes/deine-tm-platte" in vollstaendig?
>> Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
>
> An anderer Stelle, schrieb ich, dass TM versucht hat 2.24TB an Daten zu
> sichern... Da ist klar, dass vorher alles gelöscht wird ;-/
>
>
>> > Die Platte ist aber zu mehr als der Hälfte frei (1.5 von 2.7TB)
>> > 2015-10-22-144738
>>
>> Hmm. was sagt "df /Volumes/deine-tm-platte" in vollstaendig?
>> Evtl. geht dir statt Speicherplatz eine andere Ressource aus.
>
> An anderer Stelle, schrieb ich, dass TM versucht hat 2.24TB an Daten zu
> sichern... Da ist klar, dass vorher alles gelöscht wird ;-/
>
>> Hast du die Platte mal neu formatiert (Disk utility)?
>
> Nein. Warum sollte ich eine Backupplatte formatieren?
>
>
> Nein. Warum sollte ich eine Backupplatte formatieren?
>
>> Was willst du wiederherstellen?
>
> Dateien, die in Vorbereitung des aktuellen (bzw. des letzten) Backups
> gelöscht wurden.
> TimeMachine geht sicher nicht her und überschreibt den leeren Platz auf
> der Platte mit Nullen.
>
> Ca. 600GB an Bilddateien habe ich bei einer Suche vorgestern gefunden.
>
>> Disk Utility: TM-PArtition auf der TM-Platte sicher loeschen (reicht
>> einmal mit Null-bytes zu ueberschreiben), neu anlegen.
>> TM Backup starten und nachdem es fertig ist, nochmal schauen.
>
> Ganau.
> Damit JEDE Chance perdü ist, evtl auf der Platte noch vorhandene Daten
> wieder herzustellen...
> Wenn ich meine Daten unwiederholbar vernichten wollte, würde ich sicher
> kein TM Backup davon erstellen und mich dann darüber wundern, dass dort
> nicht mehr alles zu finden ist...
Mooooooment.
>
> Dateien, die in Vorbereitung des aktuellen (bzw. des letzten) Backups
> gelöscht wurden.
> TimeMachine geht sicher nicht her und überschreibt den leeren Platz auf
> der Platte mit Nullen.
>
> Ca. 600GB an Bilddateien habe ich bei einer Suche vorgestern gefunden.
>
>> Disk Utility: TM-PArtition auf der TM-Platte sicher loeschen (reicht
>> einmal mit Null-bytes zu ueberschreiben), neu anlegen.
>> TM Backup starten und nachdem es fertig ist, nochmal schauen.
>
> Ganau.
> Damit JEDE Chance perdü ist, evtl auf der Platte noch vorhandene Daten
> wieder herzustellen...
> Wenn ich meine Daten unwiederholbar vernichten wollte, würde ich sicher
> kein TM Backup davon erstellen und mich dann darüber wundern, dass dort
> nicht mehr alles zu finden ist...
Was genau willst du? Willst du eine neue Sicherung erstellen, oder
willst du verlorene Daten von der Sicherung wiederherstellen?
Deine Angaben diesbezueglich sind etwas konfus.
Entweder du willst eine Sicherung erstellen, dann solltest du die
offensichtlich problematische Platte komplett neu formatieren damit TM
ein frisches Backupmedium zur Verfuegung hat um eine vollstaendige und
saubere Sicherung zu erstellen - oder aber du willst Daten aus dem
letzten Backup wiederherstellen, die du aus irgendwelchen Gruenden
lokal verloren (geloescht) hast, dann solltest du tunlichst
verhindern, dass Timemachine von deinem System mit geloschten Daten
erneut versucht ein Backup auf die TM-Platte zu schreiben auf der
NICHT GENUG PLATZ* ist fuer zwei vollstaendige Generationen.
In letzterm Fall loescht TM genau dann vorhandene Daten aus deinem
letzten Backup, wenn der Platz fuer das Backup der aktuellen
Installation nicht mehr ausreichend scheint.
Und wenn du jetzt genau diese Daten noch brauchst, dann darfst du eben
*kein* erneutes Backup anstarten.
* TM sollte wegen genau dem Worst Case mindestens doppelt so gross
sein wie die zu sichernden Daten. Bei einem 2,5TB System also 5TB.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Joe Kotroczo
Nov 16, 2015, 4:11:30 AM11/16/15
to
On 14/11/2015 15:29, Thomas Kaiser wrote:
> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
>> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
>> sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
Willst Du damit sagen ein Klon mit Disk Utility aus der Recovery
> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
>> Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
>> sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
Partition heraus ist keiner?
Dirk Wagner
Nov 16, 2015, 4:30:43 AM11/16/15
to
Juergen P. Meier <nospa...@jors.net> wrote:
> Was genau willst du? Willst du eine neue Sicherung erstellen, oder
> willst du verlorene Daten von der Sicherung wiederherstellen?
>
> Deine Angaben diesbezueglich sind etwas konfus.
Ich habe Daten aus einer Sicherung wieder hergestellt (genauer gesagt,
> Was genau willst du? Willst du eine neue Sicherung erstellen, oder
> willst du verlorene Daten von der Sicherung wiederherstellen?
>
> Deine Angaben diesbezueglich sind etwas konfus.
ein System aus der Sicherung komplett neu aufgesetzt) und im Anschluss
daran festgestellt, dass Daten fehlen.
Dank Thomas Hinweis auf die Logdateien im Backup, weiß ich jetzt aber,
dass das daran liegt, dass TM vor dem Versuch ein neues Backup zu
erstellen alle Backups bis auf das letzte gelöscht hat...
Und nun versuche ich, die NICHT im Backup enthaltenene Dateien wieder
herzustellen.
Größtenteils dürfte mir das aber inzwischen gelungen sein...
Zumindest wurde eine größere Zahl an JPG- und CR2-Dateien auf der Platte
gefunden.
Die darf ich jetzt sichten ;-)
Was mir aber mit der Fragestellung und der Lösung auch wichtig war: Gibt
es ein prinzipielles Problem, dass TM willkürlich Daten nicht sichert...
Und hier gibt es wohl Entwarnung. Die Probleme haben ihre Ursache im
konkreten Fehlerfall und sollten durch zwei ausreichend große rotierende
Backupmedien vermeidbar sein.
Ciao
dirk
Joe Kotroczo
Nov 16, 2015, 5:29:02 AM11/16/15
to
On 13/11/2015 20:12, Goetz Hoffart wrote:
> Joe Kotroczo <kotr...@mac.com> wrote:
>
>> daß TimeMachine Nutzdaten die man eigentlich sichern wollte nicht sichert
>
> Ja, in Mac OS X 10.5 Server wurden die Mailserver-Daten-Verzeichnisse
> nicht gesichert. Aber sowas ist lang her.
Sicher? Beim OP ging es ja auch nicht um Mailserver-Ordner...
> Joe Kotroczo <kotr...@mac.com> wrote:
>
>> daß TimeMachine Nutzdaten die man eigentlich sichern wollte nicht sichert
>
> Ja, in Mac OS X 10.5 Server wurden die Mailserver-Daten-Verzeichnisse
> nicht gesichert. Aber sowas ist lang her.
Thomas Kaiser
Nov 16, 2015, 5:44:45 AM11/16/15
to
Joe Kotroczo schrieb in <news:datktv...@mid.individual.net>
Was hat das mit rsync zu tun? Disk Utility benutzt nicht rsync sondern
asr, das in dem Modus, in dem man es dann nutzt, _unterhalb_ des
Dateisystems agiert:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/asr.8.html
Das Festplatten Dienstprogramm bzw. asr klonen zur Abwechselung mal
wirklich 1:1 inkl. aller evtl. schon im Dateisystem vorhandenen Fehler.
Lustige Konsequenz: Wenn Du kurz nachher feststellt, dass Dein Mac nicht
mehr wegen zerschossenem HFS+ von seiner internen Platte startet, wird
er genau das auch nicht mehr vom Klon, weil der ist ja "1:1 inkl. aller
Probleme".
Der rsync-Ansatz werkelt oberhalb des Dateisystems und guckt in einzelne
Dateien rein (und wenn man das wirklich so macht, dass Quelle und Ziel
komplett gegengeprüft werden, dann häßlich langsam [1]). Bei rsync
würden Dir mit der Zeit defekte Dateien angemault werden oder rsync
würde wegen Dateisystemfehlern gleich ganz abbrechen. Eine Kombination
beider Ansätze ist daher sinnvoll. Was aber viel sinniger ist, ist
Prävention. Alle paar Wochen mal mit gedrückter [shift]-Taste starten,
damit das rootfs einen fsck abbekommt.
Gruss,
Thomas
[1] Ich hab gestern mal nach einem "schnellen" Komplettsync mit rsync
den lahmen Vollvergleich angestubst (mit --checksum, also wirklich
alle Daten am Ziel und an der Sync-Quelle einlesen, Checksummen
bilden, vergleichen. Dauert bei einer per USB 3.0 angebundenen
Seagate Barracuda, die sequenziell ihre 150 MByte/sek schaffen würde,
für lächerliche 170 GByte knappe 40 Minuten. Die SSD, wo die zu
syncenden 170 GByte drauf liegen, ist dabei sicherlich nicht der
Flaschenhals, weil so was Flinkes wie das Ding hatte ich noch nie.
asr, das in dem Modus, in dem man es dann nutzt, _unterhalb_ des
Dateisystems agiert:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/asr.8.html
Das Festplatten Dienstprogramm bzw. asr klonen zur Abwechselung mal
wirklich 1:1 inkl. aller evtl. schon im Dateisystem vorhandenen Fehler.
Lustige Konsequenz: Wenn Du kurz nachher feststellt, dass Dein Mac nicht
mehr wegen zerschossenem HFS+ von seiner internen Platte startet, wird
er genau das auch nicht mehr vom Klon, weil der ist ja "1:1 inkl. aller
Probleme".
Der rsync-Ansatz werkelt oberhalb des Dateisystems und guckt in einzelne
Dateien rein (und wenn man das wirklich so macht, dass Quelle und Ziel
komplett gegengeprüft werden, dann häßlich langsam [1]). Bei rsync
würden Dir mit der Zeit defekte Dateien angemault werden oder rsync
würde wegen Dateisystemfehlern gleich ganz abbrechen. Eine Kombination
beider Ansätze ist daher sinnvoll. Was aber viel sinniger ist, ist
Prävention. Alle paar Wochen mal mit gedrückter [shift]-Taste starten,
damit das rootfs einen fsck abbekommt.
Gruss,
Thomas
[1] Ich hab gestern mal nach einem "schnellen" Komplettsync mit rsync
den lahmen Vollvergleich angestubst (mit --checksum, also wirklich
alle Daten am Ziel und an der Sync-Quelle einlesen, Checksummen
bilden, vergleichen. Dauert bei einer per USB 3.0 angebundenen
Seagate Barracuda, die sequenziell ihre 150 MByte/sek schaffen würde,
für lächerliche 170 GByte knappe 40 Minuten. Die SSD, wo die zu
syncenden 170 GByte drauf liegen, ist dabei sicherlich nicht der
Flaschenhals, weil so was Flinkes wie das Ding hatte ich noch nie.
Thomas Kaiser
Nov 16, 2015, 5:47:49 AM11/16/15
to
Joe Kotroczo schrieb in <news:datpfd...@mid.individual.net>
Das hat sich ja inzwischen aufgeklärt. Zu wenig Platz auf dem TM-Medium,
daher hat TM versucht, alle alten Backups auszudünnen, um alles erneut
zu sichern. Und das ging eben gründlich schief. IMO ist das eine
Situation, die abgefangen werden müsste (weil definitiv kontraproduktiv)
aber damit sich an der Stelle was tun müsste, hätten wir wenn dann auf
discussions.apple.com herumsülzen müssen und ausreichend mediales
Interesse erzeugen müssen, damit sich das ein Entwickler bei Apple
anschaut und in so einem Fall in Zukunft einen Warndialog hochpoppen
läßt.
Und ja, leider hat Jürgen auch recht. Im Prinzip müsste man Stand jetzt,
um so ein Malheur abfangen zu können, die TM-Medien mit mindestens 200%
des zu sichernden Platzes dimensionieren.
Gruss,
Thomas
daher hat TM versucht, alle alten Backups auszudünnen, um alles erneut
zu sichern. Und das ging eben gründlich schief. IMO ist das eine
Situation, die abgefangen werden müsste (weil definitiv kontraproduktiv)
aber damit sich an der Stelle was tun müsste, hätten wir wenn dann auf
discussions.apple.com herumsülzen müssen und ausreichend mediales
Interesse erzeugen müssen, damit sich das ein Entwickler bei Apple
anschaut und in so einem Fall in Zukunft einen Warndialog hochpoppen
läßt.
Und ja, leider hat Jürgen auch recht. Im Prinzip müsste man Stand jetzt,
um so ein Malheur abfangen zu können, die TM-Medien mit mindestens 200%
des zu sichernden Platzes dimensionieren.
Gruss,
Thomas
Joe Kotroczo
Nov 16, 2015, 5:55:48 AM11/16/15
to
On 16/11/2015 10:44, Thomas Kaiser wrote:
> Joe Kotroczo schrieb in <news:datktv...@mid.individual.net>
>> On 14/11/2015 15:29, Thomas Kaiser wrote:
>>> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>>>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert,
>>>> alle Apple-Besonderheiten an Bord hat. In älteren OS X Versionen
>>>> müsste man sich das dem CCC beiliegende rsync schnappen.
>>>
>>> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
>>> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
>>> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-
>>> Kompression)
>>
>> Willst Du damit sagen ein Klon mit Disk Utility aus der Recovery
>> Partition heraus ist keiner?
>
> Was hat das mit rsync zu tun? Disk Utility benutzt nicht rsync sondern
> asr, das in dem Modus, in dem man es dann nutzt, _unterhalb_ des
> Dateisystems agiert:
Danke, das wollte ich wissen.
> Joe Kotroczo schrieb in <news:datktv...@mid.individual.net>
>> On 14/11/2015 15:29, Thomas Kaiser wrote:
>>> Ingrid Kaiser schrieb am 13.11.2015 in <news:slrnn4bqg7.1qt...@phg-online.de>
>>>> das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert,
>>>> alle Apple-Besonderheiten an Bord hat. In älteren OS X Versionen
>>>> müsste man sich das dem CCC beiliegende rsync schnappen.
>>>
>>> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
>>> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
>>> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-
>>> Kompression)
>>
>> Willst Du damit sagen ein Klon mit Disk Utility aus der Recovery
>> Partition heraus ist keiner?
>
> Was hat das mit rsync zu tun? Disk Utility benutzt nicht rsync sondern
> asr, das in dem Modus, in dem man es dann nutzt, _unterhalb_ des
> Dateisystems agiert:
>
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/asr.8.html
>
> Das Festplatten Dienstprogramm bzw. asr klonen zur Abwechselung mal
> wirklich 1:1 inkl. aller evtl. schon im Dateisystem vorhandenen Fehler.
> Lustige Konsequenz: Wenn Du kurz nachher feststellt, dass Dein Mac nicht
> mehr wegen zerschossenem HFS+ von seiner internen Platte startet, wird
> er genau das auch nicht mehr vom Klon, weil der ist ja "1:1 inkl. aller
> Probleme".
Thomas Kaiser
Nov 16, 2015, 9:33:08 AM11/16/15
to
Joe Kotroczo schrieb in <news:datr1h...@mid.individual.net>
Damit bist Du aber eher in der Minderheit. Also bzgl. Verständnis, was
der Unterschied zwischen Klon, Sync und Backup ist (von Archiv reden wir
mal lieber besser gar nicht). Das hat natürlich alles auch mit der
Unsitte seitens der Hersteller irgendwelcher kommerzieller Sync- und
Klon-Tools zu tun, ihren Kram als Backuplösung anzupreisen.
Die Unterschiede zwischen Klon, Sync und Backup könnte man natürlich als
theoretisierende Wortklauberei abtun. Aber leider fangen halt die
diversen Varianten verschiedene Gefährdungsszenarien verschieden ab. Das
sollte man eben bedenken, bevor man sich für eine der Varianten bzw.
sinnigerweise für eine Kombination mehrerer entscheidet, die den eigenen
Bedürfnissen am ehesten entspricht.
Gruss,
Thomas
der Unterschied zwischen Klon, Sync und Backup ist (von Archiv reden wir
mal lieber besser gar nicht). Das hat natürlich alles auch mit der
Unsitte seitens der Hersteller irgendwelcher kommerzieller Sync- und
Klon-Tools zu tun, ihren Kram als Backuplösung anzupreisen.
Die Unterschiede zwischen Klon, Sync und Backup könnte man natürlich als
theoretisierende Wortklauberei abtun. Aber leider fangen halt die
diversen Varianten verschiedene Gefährdungsszenarien verschieden ab. Das
sollte man eben bedenken, bevor man sich für eine der Varianten bzw.
sinnigerweise für eine Kombination mehrerer entscheidet, die den eigenen
Bedürfnissen am ehesten entspricht.
Gruss,
Thomas
Gerald E:scher
Nov 16, 2015, 11:27:40 AM11/16/15
to
| --hfs-compression preserve HFS compression if supported
| --protect-decmpfs preserve HFS compression as xattrs
man rsync liefert nähere Erläuterungen dazu.
| --protect-decmpfs preserve HFS compression as xattrs
--
Gerald
Gerald E:scher
Nov 16, 2015, 11:48:21 AM11/16/15
to
Thomas Kaiser schrieb am 16/11/2015 11:47:
> Und ja, leider hat Jürgen auch recht. Im Prinzip müsste man Stand jetzt,
> um so ein Malheur abfangen zu können, die TM-Medien mit mindestens 200%
> des zu sichernden Platzes dimensionieren.
Das Problem von zuwenig Platz auf der TM-Partition läst sich recht
> Und ja, leider hat Jürgen auch recht. Im Prinzip müsste man Stand jetzt,
> um so ein Malheur abfangen zu können, die TM-Medien mit mindestens 200%
> des zu sichernden Platzes dimensionieren.
einfach in den Griff kriegen:
- auf den Desktop klicken
- Propeller-J
- "Objektinfo einblenden" anhaken
Und schon wird mit dem Icon der TM-Partition der freie Platz angezeigt.
Ja, meine TM-Partition ist kleiner als das zu sicherende Laufwerk, aber
noch immer zu mehr als der Hälfte unbelegt. Weshalb also eine größere
Platte für TM anschaffen?
--
Gerald
Thomas Kaiser
Nov 16, 2015, 12:23:55 PM11/16/15
to
Gerald E:scher schrieb in <news:20151116164819...@ID-37099.user.uni-berlin.de>
weißt Du's. Alternativ den Thread nochmal lesen.
Und es geht nicht um die absolute Größe von Quelle und Ziel sondern
darum, dass das TM-Medium mindestens doppelt so groß sein sollte wie der
belegte Platz an der Quelle. Könnte also sein, dass Du in Deiner
Situation ungeschoren davonkommst.
Gruss,
Thomas
> Ja, meine TM-Partition ist kleiner als das zu sicherende Laufwerk,
> aber noch immer zu mehr als der Hälfte unbelegt. Weshalb also eine
> größere Platte für TM anschaffen?
Probier doch einfach aus, was Dirk seine Daten gekostet hat -- dann
> aber noch immer zu mehr als der Hälfte unbelegt. Weshalb also eine
> größere Platte für TM anschaffen?
weißt Du's. Alternativ den Thread nochmal lesen.
Und es geht nicht um die absolute Größe von Quelle und Ziel sondern
darum, dass das TM-Medium mindestens doppelt so groß sein sollte wie der
belegte Platz an der Quelle. Könnte also sein, dass Du in Deiner
Situation ungeschoren davonkommst.
Gruss,
Thomas
Thomas Kaiser
Nov 16, 2015, 12:26:52 PM11/16/15
to
Gerald E:scher schrieb in <news:20151116162737...@ID-37099.user.uni-berlin.de>
Und zu diesem ominösen decmpfs liefert auch die Suche im Archiv noch
Erhellendes, unter anderem den Verweis auf afsctool, mit dem man HFS+-
Kompression applizieren kann:
https://groups.google.com/forum/#!searchin/de.comp.sys.mac.misc/decmpfs
Gruss,
Thomas
Erhellendes, unter anderem den Verweis auf afsctool, mit dem man HFS+-
Kompression applizieren kann:
https://groups.google.com/forum/#!searchin/de.comp.sys.mac.misc/decmpfs
Gruss,
Thomas
Dirk Wagner
Nov 16, 2015, 12:43:06 PM11/16/15
to
Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
> Und schon wird mit dem Icon der TM-Partition der freie Platz angezeigt.
Das nutzt aber nur was, wenn der Desktop so leer ist, dass man das icon
für die Platte auch schnell findet.
Und wenn man gleichzeitig WEISS wie gross das nächste Backup sein wird.
Wenn TM vor dem Aufräumen gesagt hätte, dass nicht genügend Platz ist,
und dass es nun 2.3 TB freischaufeln muss, wäre ich wahrscheinlich
hellhörig geworden ;-)
Auch ohne, dass mir vorher der Platz auf der Platte am Desktop angezeigt
wird.
Ich meine mich erinnern zu können, dass TM früher mal gefragt hat, wenn
es ältere Versionen löscht.
Ciao
dirk
Gerald E:scher
Nov 16, 2015, 1:08:23 PM11/16/15
to
Dirk Wagner schrieb am 16/11/2015 18:43:
> Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Und schon wird mit dem Icon der TM-Partition der freie Platz angezeigt.
>
> Das nutzt aber nur was, wenn der Desktop so leer ist, dass man das icon
> für die Platte auch schnell findet.
Das muss man ja nicht ständig im Auge behalten. Ein gelegentliches
> Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Und schon wird mit dem Icon der TM-Partition der freie Platz angezeigt.
>
> Das nutzt aber nur was, wenn der Desktop so leer ist, dass man das icon
> für die Platte auch schnell findet.
$ df -h
erfüllt selbstverständlich den gleichen Zweck.
> Und wenn man gleichzeitig WEISS wie gross das nächste Backup sein wird.
>
> Wenn TM vor dem Aufräumen gesagt hätte, dass nicht genügend Platz ist,
> und dass es nun 2.3 TB freischaufeln muss, wäre ich wahrscheinlich
> hellhörig geworden ;-)
ich nicht so bald kommen, schon gar nicht, ohne dass mir dies bewusst
wäre. Das einzige, was bei mir wirklich Platz benötigt, sind virtuelle
Maschinen und die sichere ich nicht mit TM.
> Ich meine mich erinnern zu können, dass TM früher mal gefragt hat, wenn
> es ältere Versionen löscht.
Capitan. Aber wenn man das halt entfernt...
--
Gerald
Joe Kotroczo
Nov 16, 2015, 1:15:29 PM11/16/15
to
entsprechen. Wie groß das /Laufwerk/ ist eigentlich irrelevant, man
sichert ja nicht das Laufwerk sondern die sich darauf befindlichen
Daten. D.h. wenn auf einer 4TB Platte nur 100GB an Daten liegen dann
sollte auch eine 200GB Platte als TM-Medium reichen. Man muß halt dann
nur im Hinterkopf behalten daß das TM-Backup fehlschlägt sobald man dann
doch mal mehr Daten auf das Laufwerk schaufelt.
Dirk Wagner
Nov 16, 2015, 1:25:09 PM11/16/15
to
Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
> Das entsprechende Häkchen existiert auch in den TM-Einstellungen von El
> Capitan. Aber wenn man das halt entfernt...
Ich habe nur 10.9.5 - und dort heißt das Häkchen "Benachritigung nach
> Das entsprechende Häkchen existiert auch in den TM-Einstellungen von El
> Capitan. Aber wenn man das halt entfernt...
(!) dem Löschen von alten Backups"
Ciao
dirk
Joe Kotroczo
Nov 16, 2015, 1:44:32 PM11/16/15
to
backups are deleted". Laut Google ist das wohl schon seit 10.6 so, davor
hieß es wohl "Warn before old backups are deleted"... Hmpf.
Gerald E:scher
Nov 16, 2015, 1:58:29 PM11/16/15
to
Thomas Kaiser schrieb am 16/11/2015 18:23:
> Und es geht nicht um die absolute Größe von Quelle und Ziel sondern
> darum, dass das TM-Medium mindestens doppelt so groß sein sollte wie der
> belegte Platz an der Quelle.
Mindestens doppelt so groß, wie die zu sichernden Daten. Virtuelle
> Und es geht nicht um die absolute Größe von Quelle und Ziel sondern
> darum, dass das TM-Medium mindestens doppelt so groß sein sollte wie der
> belegte Platz an der Quelle.
Maschinen sichere ich nicht mit TM, dazu ist TM nur bedingt geeignet.
--
Gerald
Gerald E:scher
Nov 16, 2015, 2:02:30 PM11/16/15
to
Dirk Wagner schrieb am 16/11/2015 19:25:
> Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Das entsprechende Häkchen existiert auch in den TM-Einstellungen von El
>> Capitan. Aber wenn man das halt entfernt...
>
> Ich habe nur 10.9.5
Ich auch, El Capitan nur probehalber auf einer externen Platte.
> Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Das entsprechende Häkchen existiert auch in den TM-Einstellungen von El
>> Capitan. Aber wenn man das halt entfernt...
>
> Ich habe nur 10.9.5
> - und dort heißt das Häkchen "Benachritigung nach
> (!) dem Löschen von alten Backups"
anders.
--
Gerald
Dirk Wagner
Nov 16, 2015, 4:14:49 PM11/16/15
to
Joe Kotroczo <kotr...@mac.com> wrote:
> Lustigerweise heißt es auch auf 10.10.5 in unübersetzt "Notify after old
> backups are deleted". Laut Google ist das wohl schon seit 10.6 so, davor
> hieß es wohl "Warn before old backups are deleted"... Hmpf.
Hmmm...
> Lustigerweise heißt es auch auf 10.10.5 in unübersetzt "Notify after old
> backups are deleted". Laut Google ist das wohl schon seit 10.6 so, davor
> hieß es wohl "Warn before old backups are deleted"... Hmpf.
ich kann mich noch daran erinnern, die warnen-vor-dem-Löschen Nachricht
gesehen zu haben.
Und da ich erst im letzten Sommer von 10.6 auf 10.9 gewechselt habe,
wird das wohl unter 10.6 gewesen sein.
Ciao
dirk
Dirk Wagner
Nov 16, 2015, 4:17:40 PM11/16/15
to
Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
> Klick einmal auf das Fragezeichen, in der Hilfe liest es sich etwas
> anders.
"Sie können veranlassen, dass Sie benachrichtigt werden, wenn Ihr
>
> Klick einmal auf das Fragezeichen, in der Hilfe liest es sich etwas
> anders.
Backup-Volume voll ist und Time Machine damit beginnt, ältere
Sicherungskopien zu löschen, um Speicherplatz für neue Sicherungskopien
bereitzustellen."
OK - jetzt wäre nur die Frage, on die Erläuterung oder die Bezeichnung
des Hakens dem tatsächlichen Verhalten inhaltlich entspricht...
Der Haken war übrigens gesetzt - von daher vermute ich, dass das vom
gesicherten System übernommen wurde.
Ciao
dirk
Andre Igler
Nov 17, 2015, 2:51:19 AM11/17/15
to
Am 16.11.15 um 22:17 schrieb Dirk Wagner:
und teilt Dir das dann mit. Welche, teilt es nicht mit.
So geschehen bei mir vor vier Tagen. 10.10.5
Ein sudo tmutil delete [pfadangabe] greift dem vor. Mehr scheint nicht
zu gehen.
addio
--
pm <mein vorname> bei <mein nachname> punkt at
—>Mein neues Buch! Jetzt auf www.oluschka.com
www.albinschwarz.com http://weblog.igler.at
> Gerald E:scher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Klick einmal auf das Fragezeichen, in der Hilfe liest es sich etwas
>> anders.
>
> "Sie können veranlassen, dass Sie benachrichtigt werden, wenn Ihr
> Backup-Volume voll ist und Time Machine damit beginnt, ältere
> Sicherungskopien zu löschen, um Speicherplatz für neue Sicherungskopien
> bereitzustellen."
Was immer sie Dir sagen - de facto löscht TM die ältesten Sicherungen
>
>> Klick einmal auf das Fragezeichen, in der Hilfe liest es sich etwas
>> anders.
>
> "Sie können veranlassen, dass Sie benachrichtigt werden, wenn Ihr
> Backup-Volume voll ist und Time Machine damit beginnt, ältere
> Sicherungskopien zu löschen, um Speicherplatz für neue Sicherungskopien
> bereitzustellen."
und teilt Dir das dann mit. Welche, teilt es nicht mit.
So geschehen bei mir vor vier Tagen. 10.10.5
Ein sudo tmutil delete [pfadangabe] greift dem vor. Mehr scheint nicht
zu gehen.
addio
--
pm <mein vorname> bei <mein nachname> punkt at
—>Mein neues Buch! Jetzt auf www.oluschka.com
www.albinschwarz.com http://weblog.igler.at
MartinC
Nov 17, 2015, 4:31:34 AM11/17/15
to
Am 17.11.15 um 08:51 schrieb Andre Igler:
> Was immer sie Dir sagen - de facto löscht TM die ältesten Sicherungen
> und teilt Dir das dann mit. Welche, teilt es nicht mit.
Ich bin eigentlich immer davon ausgegangen, daß die älteste Version
(Datum) komplett gelöscht wird und danach ggf. die weiteren ältesten bis
genug Platz für die nächste neue Sicherung frei ist - so daß am Ende
grundsätzlich jeder verbleibende "Snapshot" vollständig ist.
Die aktuelle Debatte scheint aber zu implizieren, als würden quasi
einzelne Dateien verschwinden, also bei den ältesten Sicherungen
plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
kann, daß dies so implementiert wurde).
Ist das korrekt, bzw. welche Variante ist es denn?
> Was immer sie Dir sagen - de facto löscht TM die ältesten Sicherungen
> und teilt Dir das dann mit. Welche, teilt es nicht mit.
(Datum) komplett gelöscht wird und danach ggf. die weiteren ältesten bis
genug Platz für die nächste neue Sicherung frei ist - so daß am Ende
grundsätzlich jeder verbleibende "Snapshot" vollständig ist.
Die aktuelle Debatte scheint aber zu implizieren, als würden quasi
einzelne Dateien verschwinden, also bei den ältesten Sicherungen
plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
kann, daß dies so implementiert wurde).
Ist das korrekt, bzw. welche Variante ist es denn?
Juergen P. Meier
Nov 17, 2015, 5:01:43 AM11/17/15
to
MartinC <nor...@nospam.invalid>:
Systemen ohne Auffaelligkeiten sowohl auf USB2, USB3 als auch per
Firewire angebundenen externen Laufwerken. Ueber NEtz mache ich kein
TM, dafuer sind mir meine Fuesse zu schade.
> Die aktuelle Debatte scheint aber zu implizieren, als würden quasi
> einzelne Dateien verschwinden, also bei den ältesten Sicherungen
> plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
> kann, daß dies so implementiert wurde).
Ich halte das fuer eine Folge eines anderen Problems.
Wenn die durch Hardlinks realisierten Snapshots nicht frei von
Inkonsistenzen sind, kann das Loeschen eines alten Snapshots
natuerlich Daten loeschen die nicht nur in diesem Snapshot haetten
referenziert sein sollen. Das ist aber IMO in jedem Fall nur eine
Folge eines anderen Problems. Und solange das nicht identifiziert und
beseitigt werde kann, wird der OP immer wieder Daten verlieren, bzw.
kann und darf sich auf TM in seiner Umgebung einfach nicht verlassen..
> Ist das korrekt, bzw. welche Variante ist es denn?
Ein inkonsistentes Backup (egal aus welchen Gruenden) ist halt einfach
kein Backup.
> Am 17.11.15 um 08:51 schrieb Andre Igler:
>
>> Was immer sie Dir sagen - de facto löscht TM die ältesten Sicherungen
>> und teilt Dir das dann mit. Welche, teilt es nicht mit.
>
> Ich bin eigentlich immer davon ausgegangen, daß die älteste Version
> (Datum) komplett gelöscht wird und danach ggf. die weiteren ältesten bis
> genug Platz für die nächste neue Sicherung frei ist - so daß am Ende
> grundsätzlich jeder verbleibende "Snapshot" vollständig ist.
So die IDee. So funktioniert das bei mir auch mit verschiedenen
>
>> Was immer sie Dir sagen - de facto löscht TM die ältesten Sicherungen
>> und teilt Dir das dann mit. Welche, teilt es nicht mit.
>
> Ich bin eigentlich immer davon ausgegangen, daß die älteste Version
> (Datum) komplett gelöscht wird und danach ggf. die weiteren ältesten bis
> genug Platz für die nächste neue Sicherung frei ist - so daß am Ende
> grundsätzlich jeder verbleibende "Snapshot" vollständig ist.
Systemen ohne Auffaelligkeiten sowohl auf USB2, USB3 als auch per
Firewire angebundenen externen Laufwerken. Ueber NEtz mache ich kein
TM, dafuer sind mir meine Fuesse zu schade.
> Die aktuelle Debatte scheint aber zu implizieren, als würden quasi
> einzelne Dateien verschwinden, also bei den ältesten Sicherungen
> plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
> kann, daß dies so implementiert wurde).
Wenn die durch Hardlinks realisierten Snapshots nicht frei von
Inkonsistenzen sind, kann das Loeschen eines alten Snapshots
natuerlich Daten loeschen die nicht nur in diesem Snapshot haetten
referenziert sein sollen. Das ist aber IMO in jedem Fall nur eine
Folge eines anderen Problems. Und solange das nicht identifiziert und
beseitigt werde kann, wird der OP immer wieder Daten verlieren, bzw.
kann und darf sich auf TM in seiner Umgebung einfach nicht verlassen..
> Ist das korrekt, bzw. welche Variante ist es denn?
kein Backup.
Thomas Kaiser
Nov 17, 2015, 5:18:54 AM11/17/15
to
MartinC schrieb in <news:n2es1a$f06$1...@dont-email.me>
stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
immer sofort rapide).
Bei Dirk flackte eine alte inkonsistente Sicherung und eine, an der noch
.inProgress am Verzeichnisnamen klebte. Für mich evtl. Indiz für einen
Bug bzw. in jedem Fall klares Indiz, dass TM die letzte Sicherung nicht
fertigstellen konnte (hätte Dirk das Log auf pastebin.com gestellt,
würde es sich lohnen, weiter drüber nachzudenken. So ist das nur völlig
sinnlos)
Gruss,
Thomas
> Die aktuelle Debatte scheint aber zu implizieren, als würden quasi
> einzelne Dateien verschwinden, also bei den ältesten Sicherungen
> plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
> kann, daß dies so implementiert wurde).
>
> Ist das korrekt, bzw. welche Variante ist es denn?
Weiß so recht keiner (ich bat Dirk, das/die Log(s) auf pastebin.com zu
> einzelne Dateien verschwinden, also bei den ältesten Sicherungen
> plötzlich selektiv Objekte fehlen (was ich mir nicht wirklich vorstellen
> kann, daß dies so implementiert wurde).
>
> Ist das korrekt, bzw. welche Variante ist es denn?
stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
immer sofort rapide).
Bei Dirk flackte eine alte inkonsistente Sicherung und eine, an der noch
.inProgress am Verzeichnisnamen klebte. Für mich evtl. Indiz für einen
Bug bzw. in jedem Fall klares Indiz, dass TM die letzte Sicherung nicht
fertigstellen konnte (hätte Dirk das Log auf pastebin.com gestellt,
würde es sich lohnen, weiter drüber nachzudenken. So ist das nur völlig
sinnlos)
Gruss,
Thomas
Dirk Wagner
Nov 17, 2015, 5:47:01 AM11/17/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
> Weiß so recht keiner (ich bat Dirk, das/die Log(s) auf pastebin.com zu
> stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
> schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
> immer sofort rapide).
>
Sorry,
>
> Weiß so recht keiner (ich bat Dirk, das/die Log(s) auf pastebin.com zu
> stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
> schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
> immer sofort rapide).
>
ich hatte das hochgeladen, den Link dann aber nicht gepostet, weil ich
meinte die (vermeindliche?) Ursache gefunden zu haben.
http://pastebin.com/nRKrwqvn
Die vorletzte Logdatei in "in Progress"
http://pastebin.com/3R1TWjEh
Die letzte Logdatei in "in Progress"
Ciao
dirk
Thomas Kaiser
Nov 17, 2015, 6:36:42 AM11/17/15
to
Dirk Wagner schrieb in <news:1me14hf.mkrx1d1sfemd7N%usenet...@diwasoft.de>
vorletzten Backup-Versuch ja bekanntlich den kleinen aber folgenschweren
Versuch gemacht, Berechtigungen anzupassen. Da TimeMachines kleinste
Einheit Dateien sind und sowas wie Berechtigungen an den Dateien selbst
im Backup drankleben müssen, kam TM dann in Folge zum Schluß, "2784640
items (2.24 TB)" neu sichern zu müssen. Zeitstempel: 15:48:16
Backup-Medium hatte nur "3TB", was in Wirklichkeit aber ein Eckchen
weniger ist. Jedenfalls ist auf der Platte kein Platz, um die vollen
2,24 TByte zu sichern:
Should copy 2784640 items (2.24 TB) representing 547672951 blocks of
size 4096. 58030905 blocks available.
In Folge <http://pastebin.com/nRKrwqvn> löscht TM daher logischerweise
*alle* bereits existenten Snapshots bzw. versucht es, weil es am Ende
mit "Backup failed with error:7." auf die Fresse fällt. Warum auch
immer.
Jedenfalls nimmt es um 17:13:45 wieder die Arbeit auf und stellt fest,
dass immer noch zu wenig Platz vorhanden ist:
Should copy 2784690 items (2.24 TB) representing 547125793 blocks of
size 4096. 367682716 blocks available.
Wie rechnet Apple: Wie die letzten Deppen. Intern wird mit 4K Blocks,
also Vielfachen von 4096 Byte gerechnet und die größeren Maßeinheiten
werden nicht mehr mit Faktor 1024 sondern 1000 "errechnet" (seit 10.6
machen sie das so):
547125793 * 4096 / 1000 / 1000 / 1000 / 1000 = 2,24 TB benötigt
367682716 * 4096 / 1000 / 1000 / 1000 / 1000 = 1,5 TB verfügbar
Der aktuelle Backupordner heißt nun "2015-10-22-171345.inProgress". Und
im Log <http://pastebin.com/3R1TWjEh> taucht nun auf:
Preserving last snapshot
/Volumes/TM_Backup_3TB_2/Backups.backupdb/g5/2015-10-22-144738
Und
Deleting old snapshot at '/Volumes/TM_Backup_3TB_2/Backups.backupdb/g5/ \
2015-10-22-171345.inProgress/621C8297-62AB-4327-B83D-C0481CDF9140'
Löscht sich also selbst den Sicherungsordner weg, was schon mal nach Bug
riecht. Wenn das letzte Backup "2015-10-22-144738" vollständig gewesen
sein soll, 2,24 TByte erneut gesichert werden und 1,5 TByte verfügbar
sind, dann muß das Backup-Medium mindestens 3,74 TByte groß sein. Was es
ja angeblich nicht ist, weil's sich um 'ne 3TB-Platte handelt. Also
stimmt entweder Letzteres nicht und es ist ein Medium mit 4 TByte (Bitte
Ausgabe von "df -h", wenn die Platte am Mac hängt) oder das letzte
Backup war schon unvollständig, worauf ja Dirks Symptome auch hinweisen
würden.
Eine mögliche Variante: TimeMachine ermittelt ja immer, welche Elemente
sich zwischen zwei Läufen _nicht_ geändert haben und legt für diese im
neuen Backup-Ordner stumpf Hardlinks auf den letzten "Snapshot" an. Das
Backup, das um 17:13:45 gestartet ist, meinte laut Log es brauchte für
das Ermitteln der Änderungen "3 hours, 12 minutes, 13.000 seconds".
_Wenn_ es während dieses Checks für alles, was sich _nicht_ geändert
hatte, bereits Hardlinks vom letzten Snapshot aus angelegt hatte, dann
ist klar, warum die Aktion im Anschluß, nämlich Löschen des aktuellen
Snapshot "2015-10-22-171345.inProgress" auf einmal auch anfängt, ältere
Daten auszudünnen.
Eine andere Variante: Als Dirk das Malheur passierte (rekursive Rechte-
Änderung am laufenden System auf "707"), lief evtl. grad die Sicherung
"2015-10-22-144738" und hier lief schon alles schief bzw. der backupd
Amok. Da Dirk angeblich 3 rotierende Platten hat, ließe sich das simpel
klären.
Nächste Variante: TM kann per se nicht mit der Situation umgehen, dass
in so einer Situation, wo _quasi alles_ gesichert werden soll, der zur
Verfügung stehende Platz auf dem Backup-Medium nicht ausreicht, weil es
immer den letzten Snapshot aufheben will. In der Situation würde
wirklich nur helfen, Backup-Platz mehr als doppelt zu groß wie den zu
sichernden zu dimensionieren.
Und dann stehen die Fragen im Raum, was "Backup failed with error:7."
(da findet Frollein Google nämlich exakt gar nix dazu) und ob TM aktiv
drauf hingewiesen hat, dass die letzte Sicherung schiefgegangen ist?
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Weiß so recht keiner (ich bat Dirk, das/die Log(s) auf pastebin.com zu
>> stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
>> schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
>> immer sofort rapide).
>>
>
>> Weiß so recht keiner (ich bat Dirk, das/die Log(s) auf pastebin.com zu
>> stellen -- hat er nicht gemacht. Und bei solchen Ausgangsbedingungen
>> schwindet meine Lust, mich mit anderer Leute Problemen zu beschäftigen,
>> immer sofort rapide).
>>
> http://pastebin.com/nRKrwqvn
> Die vorletzte Logdatei in "in Progress"
>
> http://pastebin.com/3R1TWjEh
> Die letzte Logdatei in "in Progress"
Danke, so wird ein Schuh draus. Am fraglichen 22. 10. hast Du vor dem
> Die vorletzte Logdatei in "in Progress"
>
> http://pastebin.com/3R1TWjEh
> Die letzte Logdatei in "in Progress"
vorletzten Backup-Versuch ja bekanntlich den kleinen aber folgenschweren
Versuch gemacht, Berechtigungen anzupassen. Da TimeMachines kleinste
Einheit Dateien sind und sowas wie Berechtigungen an den Dateien selbst
im Backup drankleben müssen, kam TM dann in Folge zum Schluß, "2784640
items (2.24 TB)" neu sichern zu müssen. Zeitstempel: 15:48:16
Backup-Medium hatte nur "3TB", was in Wirklichkeit aber ein Eckchen
weniger ist. Jedenfalls ist auf der Platte kein Platz, um die vollen
2,24 TByte zu sichern:
Should copy 2784640 items (2.24 TB) representing 547672951 blocks of
size 4096. 58030905 blocks available.
In Folge <http://pastebin.com/nRKrwqvn> löscht TM daher logischerweise
*alle* bereits existenten Snapshots bzw. versucht es, weil es am Ende
mit "Backup failed with error:7." auf die Fresse fällt. Warum auch
immer.
Jedenfalls nimmt es um 17:13:45 wieder die Arbeit auf und stellt fest,
dass immer noch zu wenig Platz vorhanden ist:
Should copy 2784690 items (2.24 TB) representing 547125793 blocks of
size 4096. 367682716 blocks available.
Wie rechnet Apple: Wie die letzten Deppen. Intern wird mit 4K Blocks,
also Vielfachen von 4096 Byte gerechnet und die größeren Maßeinheiten
werden nicht mehr mit Faktor 1024 sondern 1000 "errechnet" (seit 10.6
machen sie das so):
547125793 * 4096 / 1000 / 1000 / 1000 / 1000 = 2,24 TB benötigt
367682716 * 4096 / 1000 / 1000 / 1000 / 1000 = 1,5 TB verfügbar
Der aktuelle Backupordner heißt nun "2015-10-22-171345.inProgress". Und
im Log <http://pastebin.com/3R1TWjEh> taucht nun auf:
Preserving last snapshot
/Volumes/TM_Backup_3TB_2/Backups.backupdb/g5/2015-10-22-144738
Und
Deleting old snapshot at '/Volumes/TM_Backup_3TB_2/Backups.backupdb/g5/ \
2015-10-22-171345.inProgress/621C8297-62AB-4327-B83D-C0481CDF9140'
Löscht sich also selbst den Sicherungsordner weg, was schon mal nach Bug
riecht. Wenn das letzte Backup "2015-10-22-144738" vollständig gewesen
sein soll, 2,24 TByte erneut gesichert werden und 1,5 TByte verfügbar
sind, dann muß das Backup-Medium mindestens 3,74 TByte groß sein. Was es
ja angeblich nicht ist, weil's sich um 'ne 3TB-Platte handelt. Also
stimmt entweder Letzteres nicht und es ist ein Medium mit 4 TByte (Bitte
Ausgabe von "df -h", wenn die Platte am Mac hängt) oder das letzte
Backup war schon unvollständig, worauf ja Dirks Symptome auch hinweisen
würden.
Eine mögliche Variante: TimeMachine ermittelt ja immer, welche Elemente
sich zwischen zwei Läufen _nicht_ geändert haben und legt für diese im
neuen Backup-Ordner stumpf Hardlinks auf den letzten "Snapshot" an. Das
Backup, das um 17:13:45 gestartet ist, meinte laut Log es brauchte für
das Ermitteln der Änderungen "3 hours, 12 minutes, 13.000 seconds".
_Wenn_ es während dieses Checks für alles, was sich _nicht_ geändert
hatte, bereits Hardlinks vom letzten Snapshot aus angelegt hatte, dann
ist klar, warum die Aktion im Anschluß, nämlich Löschen des aktuellen
Snapshot "2015-10-22-171345.inProgress" auf einmal auch anfängt, ältere
Daten auszudünnen.
Eine andere Variante: Als Dirk das Malheur passierte (rekursive Rechte-
Änderung am laufenden System auf "707"), lief evtl. grad die Sicherung
"2015-10-22-144738" und hier lief schon alles schief bzw. der backupd
Amok. Da Dirk angeblich 3 rotierende Platten hat, ließe sich das simpel
klären.
Nächste Variante: TM kann per se nicht mit der Situation umgehen, dass
in so einer Situation, wo _quasi alles_ gesichert werden soll, der zur
Verfügung stehende Platz auf dem Backup-Medium nicht ausreicht, weil es
immer den letzten Snapshot aufheben will. In der Situation würde
wirklich nur helfen, Backup-Platz mehr als doppelt zu groß wie den zu
sichernden zu dimensionieren.
Und dann stehen die Fragen im Raum, was "Backup failed with error:7."
(da findet Frollein Google nämlich exakt gar nix dazu) und ob TM aktiv
drauf hingewiesen hat, dass die letzte Sicherung schiefgegangen ist?
Dirk Wagner
Nov 17, 2015, 8:08:14 AM11/17/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Bitte Ausgabe von "df -h", wenn die Platte am Mac hängt
/dev/disk7s2 2.7Ti 1.4Ti 1.4Ti 50% 364799507 367683158 50%
> Bitte Ausgabe von "df -h", wenn die Platte am Mac hängt
/Volumes/TM_Backup_3TB_2
> Und dann stehen die Fragen im Raum, was "Backup failed with error:7."
> (da findet Frollein Google nämlich exakt gar nix dazu) und ob TM aktiv
> drauf hingewiesen hat, dass die letzte Sicherung schiefgegangen ist?
Ciao
dirk
Thomas Kaiser
Nov 17, 2015, 8:49:21 AM11/17/15
to
Dirk Wagner schrieb in <news:1me1a1q.46jik01wgr3olN%usenet...@diwasoft.de>
dass anhand der Block-Differenz (367682716 blocks available == 1,5 TB)
zum Zeitpunkt des zweiten Backup-Versuchs nach Malheur nur 1,2 TB auf
dem TM-Medium belegt waren, obwohl es 2,24 TB hätten sein müssen.
Als das erste Backup nach dem Malheur anfing, meckerte TM an, es würden
237 GByte fehlen, also war zu dem Zeitpunkt das TM-Volume noch mit ca.
2,5 TB belegt. Und Du hattest 19 Snapshots, die bis zum 14. 10. zurück-
reichten -- klingt also plausibel angesichts einer zu sichernden Menge
von 2,24 TB, dass in über eine Woche ein Änderungsdelta von insg. paar
hundert GByte angefallen ist.
Aber wann und wo nun TM angefangen hat, im Backup das Falsche
auszudünnen, wird sich jetzt nicht mehr rekonstruieren lassen. Es ist
nur auffällig, dass beim ersten Backup nach dem Malheur das Ganze schon
seltsam startete (siehe <http://pastebin.com/nRKrwqvn>):
TM versucht alte Snapshots von hinten weg zu löschen, schnappt sich als
Erstes aber einen Snapshot vom Vortag (2015-10-21-144647), um dann erst
von hinten bzw. von "2015-10-14-102223" aus weiterzumachen. Das ist
genauso eindeutig ein Fehlverhalten wie dann beim nächsten Backup-
Versuch, dass TM den aktuellen Snapshot, den es grad anzulegen versucht,
für älter hält als den von vor dem Malheur. Da steckt der Wurm drin.
Wenn mich nicht alles täuscht, sichert TM /var/log nicht mit (grad
nachgeschaut -- leider wahr), also kann man es leider auch vergessen, in
/var/log/system.log* was zu finden. Flackt denn in
/Library/Logs/DiagnosticReports/
noch irgendwas mit Datum 22. 10.?
Danke und Gruss,
Thomas
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Bitte Ausgabe von "df -h", wenn die Platte am Mac hängt
>
> /dev/disk7s2 2.7Ti 1.4Ti 1.4Ti 50% 364799507 367683158 50%
> /Volumes/TM_Backup_3TB_2
Danke. Das heißt dann indirekt auch laut http://pastebin.com/3R1TWjEh
>
>> Bitte Ausgabe von "df -h", wenn die Platte am Mac hängt
>
> /dev/disk7s2 2.7Ti 1.4Ti 1.4Ti 50% 364799507 367683158 50%
> /Volumes/TM_Backup_3TB_2
dass anhand der Block-Differenz (367682716 blocks available == 1,5 TB)
zum Zeitpunkt des zweiten Backup-Versuchs nach Malheur nur 1,2 TB auf
dem TM-Medium belegt waren, obwohl es 2,24 TB hätten sein müssen.
Als das erste Backup nach dem Malheur anfing, meckerte TM an, es würden
237 GByte fehlen, also war zu dem Zeitpunkt das TM-Volume noch mit ca.
2,5 TB belegt. Und Du hattest 19 Snapshots, die bis zum 14. 10. zurück-
reichten -- klingt also plausibel angesichts einer zu sichernden Menge
von 2,24 TB, dass in über eine Woche ein Änderungsdelta von insg. paar
hundert GByte angefallen ist.
Aber wann und wo nun TM angefangen hat, im Backup das Falsche
auszudünnen, wird sich jetzt nicht mehr rekonstruieren lassen. Es ist
nur auffällig, dass beim ersten Backup nach dem Malheur das Ganze schon
seltsam startete (siehe <http://pastebin.com/nRKrwqvn>):
TM versucht alte Snapshots von hinten weg zu löschen, schnappt sich als
Erstes aber einen Snapshot vom Vortag (2015-10-21-144647), um dann erst
von hinten bzw. von "2015-10-14-102223" aus weiterzumachen. Das ist
genauso eindeutig ein Fehlverhalten wie dann beim nächsten Backup-
Versuch, dass TM den aktuellen Snapshot, den es grad anzulegen versucht,
für älter hält als den von vor dem Malheur. Da steckt der Wurm drin.
Wenn mich nicht alles täuscht, sichert TM /var/log nicht mit (grad
nachgeschaut -- leider wahr), also kann man es leider auch vergessen, in
/var/log/system.log* was zu finden. Flackt denn in
/Library/Logs/DiagnosticReports/
noch irgendwas mit Datum 22. 10.?
Danke und Gruss,
Thomas
Dirk Wagner
Nov 17, 2015, 9:35:55 AM11/17/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Flackt denn in
>
> /Library/Logs/DiagnosticReports/
>
> noch irgendwas mit Datum 22. 10.?
Nein.
> Flackt denn in
>
> /Library/Logs/DiagnosticReports/
>
> noch irgendwas mit Datum 22. 10.?
Dort fängt es erst am 24. Oktober an...
ciao
dirk
Thomas Kaiser
Nov 17, 2015, 9:52:00 AM11/17/15
to
Dirk Wagner schrieb in <news:1me1fb4.1hk77yr1vn278eN%usenet...@diwasoft.de>
Danke, dann kann man weitere Analyse wohl vergessen. Ich hab jetzt auch
keinerlei Muße, das Ganze irgendwie zu provozieren. Jedenfalls werden in
k-sync in jedem Fall die Verzeichnisse mit Log-Dateien nicht vom Sync
ausgeschlossen, obwohl sie TimeMachine nicht mitsichert (was irgendwie
doof ist, weil sooo groß werden die Verzeichnisse auch nicht [1])
Gruss,
Thomas
[1] haha, /var/log ist hier grad 6,4 GByte groß, weil "VMware Fusion
Start Menu" mehrmals pro Sekunde ins Log hustet und der newsyslog
mit der Logfile-Rotation kaum mehr nachkommt...
keinerlei Muße, das Ganze irgendwie zu provozieren. Jedenfalls werden in
k-sync in jedem Fall die Verzeichnisse mit Log-Dateien nicht vom Sync
ausgeschlossen, obwohl sie TimeMachine nicht mitsichert (was irgendwie
doof ist, weil sooo groß werden die Verzeichnisse auch nicht [1])
Gruss,
Thomas
[1] haha, /var/log ist hier grad 6,4 GByte groß, weil "VMware Fusion
Start Menu" mehrmals pro Sekunde ins Log hustet und der newsyslog
mit der Logfile-Rotation kaum mehr nachkommt...
Dirk Wagner
Nov 17, 2015, 10:21:05 AM11/17/15
to
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Danke, dann kann man weitere Analyse wohl vergessen. Ich hab jetzt auch
> keinerlei Muße, das Ganze irgendwie zu provozieren.
Ich auch nicht ;-)
> Danke, dann kann man weitere Analyse wohl vergessen. Ich hab jetzt auch
> keinerlei Muße, das Ganze irgendwie zu provozieren.
DAS brauche ich nicht öfters...
Ciao
dirk
Michael Jaeger
Nov 21, 2015, 12:08:58 PM11/21/15
to
In article <1me032e.142n6dz9cg5z3N%usenet...@diwasoft.de>,
Habe eben gerade geguckt. Auf 10.6.8 wird erst nach dem Löschen gewarnt.
Viele Grüße
Michael
--
Macintosh. Was sonst?
Viele Grüße
Michael
--
Macintosh. Was sonst?
Michael Jaeger
Nov 21, 2015, 12:37:51 PM11/21/15
to
In article <slrnn4ekqr.21e...@phg-online.de>,
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ingrid Kaiser schrieb am 13.11.2015 in
> <news:slrnn4bqg7.1qt...@phg-online.de>
> > das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
> > Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
> > sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
>
> /usr/bin/rsync --version
> rsync version 2.6.9 protocol version 29
>
> Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
> rsync version 3.0.6 protocol version 30
>
> Man sollte sich daher den CCC schnappen und das da drinnen liegende
> rsync nach /usr/local/bin/rsync kopieren. In der 4er-Version liegt es
> ausschließlich 64-bittig in
>
> Carbon Copy Cloner.app/Contents/MacOS/rsync
>
> Daher besser die 3er schnappen, denn da liegt es als Universal Binary
> (ppc, i386 und x86_64) vor:
>
> Carbon Copy Cloner.app/Contents/MacOS/ccc_helper.app/Contents/MacOS/rsync
>
> Das Ding ist statisch gelinkt, d.h. man sollte damit auch hübsch aus der
> Recovery Partition heraus gebootet inkrementell rumsyncen können. Und
> immer schön drandenken, auch --acls, --xattrs und --hfs-compression zu
> verwenden.
>
> Gruss,
>
> Thomas
Hi Thomas,
danke für die Tips. Habe eben mal das rsync ausgetauscht. Im CCC 3.5.7
und im CCC 403 liegen aber genau die gleichen Dateien drin (beides mal
die 306 und beides mal 1,1 MByte groß). Und rsync ist bei mir in
/usr/bin/ (da habe ich auch die neue Version aus dem CCC hinkopiert).
System 10.6.8
Wird das von irgendeiner Apple-Software jetzt auch genutzt und
verbessert sich da was? Sorry, wenn ich so komisch frage, aber ich
verstehe da nicht wirklich viel von, versuche aber möglichst viel zu
lernen. Kann nie schaden.
Viele Grüße
Michael
PS: Nein, ich brauche das vermutlich nicht wirklich. Aber da ich mit
meinem Mac kein Geld verdienen muss und ich gerne rumfummle und es
wahrscheinlich auch nix schadet, habe ich es gemacht.
--
Macintosh. Was sonst?
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ingrid Kaiser schrieb am 13.11.2015 in
> <news:slrnn4bqg7.1qt...@phg-online.de>
> > das rsync, das Apple seit 10.10 (oder gar schon 10.9) mitliefert, alle
> > Apple-Besonderheiten an Bord hat. In älteren OS X Versionen müsste man
> > sich das dem CCC beiliegende rsync schnappen.
>
> Das da oben war leider ein Trugschluß, Apple liefert nach wie vor nur
> Schrott aus (also ein rsync, das nicht vollwertig Mac-Dateien sichern
> kann -- keine EAs/ACLs, keine Finder-Metadaten, keine HFS+-Kompression)
>
> /usr/bin/rsync --version
> rsync version 2.6.9 protocol version 29
>
> Carbon\ Copy\ Cloner.app/Contents/MacOS/rsync --version
> rsync version 3.0.6 protocol version 30
>
> Man sollte sich daher den CCC schnappen und das da drinnen liegende
> rsync nach /usr/local/bin/rsync kopieren. In der 4er-Version liegt es
> ausschließlich 64-bittig in
>
> Carbon Copy Cloner.app/Contents/MacOS/rsync
>
> Daher besser die 3er schnappen, denn da liegt es als Universal Binary
> (ppc, i386 und x86_64) vor:
>
> Carbon Copy Cloner.app/Contents/MacOS/ccc_helper.app/Contents/MacOS/rsync
>
> Das Ding ist statisch gelinkt, d.h. man sollte damit auch hübsch aus der
> Recovery Partition heraus gebootet inkrementell rumsyncen können. Und
> immer schön drandenken, auch --acls, --xattrs und --hfs-compression zu
> verwenden.
>
> Gruss,
>
> Thomas
Hi Thomas,
danke für die Tips. Habe eben mal das rsync ausgetauscht. Im CCC 3.5.7
und im CCC 403 liegen aber genau die gleichen Dateien drin (beides mal
die 306 und beides mal 1,1 MByte groß). Und rsync ist bei mir in
/usr/bin/ (da habe ich auch die neue Version aus dem CCC hinkopiert).
System 10.6.8
Wird das von irgendeiner Apple-Software jetzt auch genutzt und
verbessert sich da was? Sorry, wenn ich so komisch frage, aber ich
verstehe da nicht wirklich viel von, versuche aber möglichst viel zu
lernen. Kann nie schaden.
Viele Grüße
Michael
PS: Nein, ich brauche das vermutlich nicht wirklich. Aber da ich mit
meinem Mac kein Geld verdienen muss und ich gerne rumfummle und es
wahrscheinlich auch nix schadet, habe ich es gemacht.
--
Macintosh. Was sonst?
Dirk Wagner
Nov 21, 2015, 1:10:26 PM11/21/15
to
Michael Jaeger <nospam...@online-wahn.de> wrote:
> Habe eben gerade geguckt. Auf 10.6.8 wird erst nach dem Löschen gewarnt.
;-(
> Habe eben gerade geguckt. Auf 10.6.8 wird erst nach dem Löschen gewarnt.
Ich konnte mich auch nur an eine Warnung erinnern.
Dann hat sich aber wenigstens nichts am Verhalten geändert und es schon
immer widersinnig...
Ciao
dirk
Thomas Kaiser
Nov 21, 2015, 1:18:33 PM11/21/15
to
Michael Jaeger schrieb in <news:5650abed$0$4543$426a...@news.free.fr>
> Und rsync ist bei mir in /usr/bin/ (da habe ich auch die neue Version
> aus dem CCC hinkopiert).
Da sollte man "eigentlich" nie hinlangen, weil /usr/bin gehört dem
System und /usr/local/bin dem User (völlig falsche Herleitung aber
darauf läuft's irgendwie raus).
> Wird das von irgendeiner Apple-Software jetzt auch genutzt und
> verbessert sich da was?
Weder noch. Apple liefert halt bloß einfach eine grottige Uralt-Version
mit, der absurderweise alle Features fehlen, um Apple-Spezialitäten
richtig syncen zu können.
> PS: Nein, ich brauche das vermutlich nicht wirklich. Aber da ich mit
> meinem Mac kein Geld verdienen muss und ich gerne rumfummle und es
> wahrscheinlich auch nix schadet, habe ich es gemacht.
Schaden wird das kaum, da rsync eigentlich immer halbe Ewigkeiten abwärts-
kompatibel zu früheren Aufruf-Syntaxes bleibt. Du könntest gaudihalber
mal permanent
sudo execsnoop | grep rsync
mitlaufen zu lassen, um eine Idee davon zu bekommen, ob irgendeine
Software bei Dir rsync je aufruft. Prognose: Nein außer Du nutzt den CCC
oder andere Tools, die sinnigerweise auf ein gepatchtes rsync setzen.
Gruss,
Thomas
> danke für die Tips. Habe eben mal das rsync ausgetauscht. Im CCC 3.5.7
> und im CCC 403 liegen aber genau die gleichen Dateien drin (beides mal
> die 306 und beides mal 1,1 MByte groß).
Aha, dann hab ich das aus einer noch älteren Version geprokelt.
> und im CCC 403 liegen aber genau die gleichen Dateien drin (beides mal
> die 306 und beides mal 1,1 MByte groß).
> Und rsync ist bei mir in /usr/bin/ (da habe ich auch die neue Version
> aus dem CCC hinkopiert).
System und /usr/local/bin dem User (völlig falsche Herleitung aber
darauf läuft's irgendwie raus).
> Wird das von irgendeiner Apple-Software jetzt auch genutzt und
> verbessert sich da was?
mit, der absurderweise alle Features fehlen, um Apple-Spezialitäten
richtig syncen zu können.
> PS: Nein, ich brauche das vermutlich nicht wirklich. Aber da ich mit
> meinem Mac kein Geld verdienen muss und ich gerne rumfummle und es
> wahrscheinlich auch nix schadet, habe ich es gemacht.
kompatibel zu früheren Aufruf-Syntaxes bleibt. Du könntest gaudihalber
mal permanent
sudo execsnoop | grep rsync
mitlaufen zu lassen, um eine Idee davon zu bekommen, ob irgendeine
Software bei Dir rsync je aufruft. Prognose: Nein außer Du nutzt den CCC
oder andere Tools, die sinnigerweise auf ein gepatchtes rsync setzen.
Gruss,
Thomas
Michael Jaeger
Nov 27, 2015, 10:06:13 AM11/27/15
to
In article <slrnn51dbp.2io...@phg-online.de>,
Vielen Dank für die Ausführungen.
Wenn ich rsync in den usr/local/bin reinkopiere, soll oder muss ich die
alte Version im usr/bin drinlassen oder löschen?
Wenn ich rsync in den usr/local/bin reinkopiere, soll oder muss ich die
alte Version im usr/bin drinlassen oder löschen?
Thomas Kaiser
Nov 27, 2015, 11:07:43 AM11/27/15
to
Michael Jaeger schrieb in <news:56587164$0$4082$426a...@news.free.fr>
tipperst, hängt von der PATH-Definition ab. Systemweit kannst Du das
bspw. in der /etc/profile definieren. Oder in einer der Startdateien in
Deinem Homedir aber da krieg ich immer Kopfweh von, wann dort was in
welchem Kontext ausgeführt wird, dass ich meinen Quatsch in die globale
/etc/profile klatsche und fertig.
Bei mir steht da bspw.:
PATH="/bin:/usr/local/bin:/usr/bin:/usr/local/helios/bin:/opt/local/bin:/usr/X11/bin"
export PATH
Aber auch so Zeugs, um Terminal-Fenster auseinanderhalten zu können:
declare -x PROMPT_COMMAND='echo -n -e "\033]0;$HOSTNAME (${USER}): $PWD\007"'
Oder sowas, um bspw. Photoshop aus der Shell raus starten zu können:
alias photoshop="open -b com.adobe.Photoshop"
Alles reine Bequemlichkeits-Features, weil man könnte ja auch Pfade
immer komplett tippen, wenn man zu viel Zeit hat :-)
Gruss,
Thomas
> Wenn ich rsync in den usr/local/bin reinkopiere, soll oder muss ich
> die alte Version im usr/bin drinlassen oder löschen?
Drin lassen. Und welcher dann in Zukunft gewinnt, wenn Du nur "rsync"
> die alte Version im usr/bin drinlassen oder löschen?
tipperst, hängt von der PATH-Definition ab. Systemweit kannst Du das
bspw. in der /etc/profile definieren. Oder in einer der Startdateien in
Deinem Homedir aber da krieg ich immer Kopfweh von, wann dort was in
welchem Kontext ausgeführt wird, dass ich meinen Quatsch in die globale
/etc/profile klatsche und fertig.
Bei mir steht da bspw.:
PATH="/bin:/usr/local/bin:/usr/bin:/usr/local/helios/bin:/opt/local/bin:/usr/X11/bin"
export PATH
Aber auch so Zeugs, um Terminal-Fenster auseinanderhalten zu können:
declare -x PROMPT_COMMAND='echo -n -e "\033]0;$HOSTNAME (${USER}): $PWD\007"'
Oder sowas, um bspw. Photoshop aus der Shell raus starten zu können:
alias photoshop="open -b com.adobe.Photoshop"
Alles reine Bequemlichkeits-Features, weil man könnte ja auch Pfade
immer komplett tippen, wenn man zu viel Zeit hat :-)
Gruss,
Thomas
0 new messages