Ich habe am Wochenende meine interne Platte (10.8.5; ca. 700 GB Daten) auf eine neue Platte mithilfe des Festplattendienstprogrammes geklont. Die neue Platte (Seagate 1TB mit 8GB-Flash, leiser und wohl schneller als die alte WD) ist jetzt zur internen Platte geworden.
Jetzt möchte ich die neue Platte wieder regelmäßig klonen. Wie funktioniert jetzt ein erster Durchlauf von CCC oder SuperDuper? Werden in jedem Falle wieder 700 GB Daten geschrieben, was dann ca. 10-15h dauert oder:
1) Merken die Programme irgendwie, was denn jetzt anders ist?
2) Wenn letzteres, anhand welcher Information merken die das?
3) Läuft das ähnlich wie TimeMachine?
4) Wie müsste ich das Festplattendienstprogramm bedienen, dass nur die Änderungen geklont werden?

Wer weiß da was?

Wozu?

Zum Rest:

Das Festplattendienstprogramm bietet sich nur für komplette Syncs/Klone an, das kann keinen differentiellen Modus. Mit TimeMachine hat das Ganze überhaupt nichts zu tun, denn mit TimeMachine kriegst Du ein echtes Backup, bei dem alte Versionen und Gelöschtes am Ziel aufgehoben werden, was essentiell für eine Wiederherstellung ist.

SuperDuper als auch CCC haben zig verschiedene Modi und Optionen, da wirst Du Dich schon in deren Doku einlesen müssen, um am Ende das zu bekommen, was Dir vorschwebt. Ich würd mich damit nicht aufhalten und einfach TimeMachine nutzen

Ich nutze seit Jahren SuperDuper und bin sehr zufrieden damit. Das erste Mal dauert das BU logischerweise einige Stunden, dann aber werden nur die geänderten Dateien geändert. Ich mache da auch gar nicht mit irgendwelchen "Experten"-Einstellungen rum - wüsste auch nicht wieso ich das sollte. Wie gesagt, bisher hat das alles gut funktioniert.
SuperDuper kopiert die Dateien 1:1 zur HD einschließlich OS. Einzelne Dateien werden nicht in verschiedenen Varianten gesichert, wie das bei der Time Machine geschieht. Man kann also nicht die Version von vor drei Tagen zurückholen. TimeMachine ist für mich unverzichtbar, aber alle paar Wochen oder vor größeren Veränderungen aktualisiere ich auf einer Extra-HD mein SuperDuper-Backup. Das hat auch den Vorteil, dass ich an diese Daten unkompliziert rankommen, wenn ich meine Daten mal irgendwo anders brauche
Du musst nur vor dem ersten Backup mit SuperDuper darauf achten, dass die Platte richtig formatiert ist und die Partitionstabellen das richtige Format haben (> Festplattendienstprogramm), sonst kannst du nicht von der Backup-HD booten.

genauso geht es mit CCC auch, da werden nur die Änderungen geschrieben.
Man kann auch einstellen das die "alten/geänderten" Daten erst einmal in einen Archiv-Ordner geschoben werden.
Das Anlegen der Recovery-HD macht CCC auf Wunsch automatisch und aktualisiert diese beim Update vom BS. (z.b. von ML auf Mavericks)

@Thomas

Ich will die regelmäßig klonen, um im Fall der Fälle, entscheiden zu können, ob die Restauration über TimeMachine erforderlich ist, oder ich erst mal mit dem Klon weiterarbeiten kann. Die TimeMachine-Restauration wird mich nämlich 10-15h kosten; wenn das also früh morgens passiert, bin ich auch mit einem nicht so aktuellen Klon eventuell besser bedient.
TimeMachine nutze ich sowieso; exzessiv
Festplattendienstprogramm ist also dafür keine Option. Gut zu wissen!


@applejuice

Ich klone auch einen Datenzurverfügungsteller (Server wäre zuviel gesagt , ist ein iMac mit 10.5.8, an dem ein USB-Drive hängt ) jede Nacht mit Superduper auf zwei weitere Platten und weiterhin wird der auf 3 verschiedene getimemachined.
Zuhause arbeite ich mit CCC. Ich weiß also, wie sich sowohl SuperDuper als auch CCC prinzipiell verhalten, nur weiß ich nicht, ob es bspw. CCC blickt, wenn eine Platte bereits kurz zuvor mit dem Festplattendienstprogramm geklont wurde und es (CCC) dann nur das geänderte schreibt.
Ab dem zweiten Mal tut es das; das ist mir klar.

...und ich dachte, ich bin schon paranoid. hammer.

Nun ja, möglicherweise hast Du die richtigen Antworten nur falsch verstanden. Die Terminologie ist üblicherweise so, dass man als Klonen nur einen jeweils vollständigen Kopiervorgang bezeichnet. Von daher würde sich genaugenommen Klonen und "Sichern von Änderungen" gegenseitig ausschließen.

Das Festplattendienstprogramm kann nur klonen. Aber es ist schon richtig, dass die anderen Programme einen zusätzlichen Synchronisierungsmodus haben, um einen erstmaligen Klon immer wieder nachzukorrigieren.

So habe ich das nie probiert, aber eigentlich sind alle Dateien auf der neuen internen Platte neu, weshalb CCC diese beim ersten Clon komplett auf die externe schreiben sollte obwohl dort schon alles liegt.
TM macht es definitiv so, wenn die Daten vorher mit CCC auf eine neue Platte geklont wurden.

Hör' mal, nicht, dass Du mich mißverstehst. Ich habe mit keiner Silbe gesagt, dass Du nicht paranoid bist.

TimeMachine können aber auch nur Nutzer ernsthaft empfehlen, die noch nicht etliche "zerschossene" und somit nahezu nutzloseTM-Backups gesehen haben …

Für 1:1-Clones habe ich bisher immer SuperDuper! empfohlen, mittlerweile ist Carbon Copy Cloner aber etwas fortschrittlicher (archivieren älterer Daten + Clone der Recovery-Partiton).

Für "echte Backups" (Archivierung) empfehle ich als Alternative zu TimeMachine mittlerweile ChronoSync. Der Support ist sehr gut und bisher hatte ich wie auch dutzende meiner Klienten keine Probleme damit.

ChronoSync gibt es hier:

Einen temporären key zum testen gibt es auf Anfrage, dieser ist (wenn ich mich recht entsinne) für 30 Tage lauffähig.

@Marcel_75@work

Von welchen zerschossenen TimeMachine-Backups sprichst Du? Ich hoffe, Du meinst nur solche Backups, die auf einem image über's Netzwerk erstellt worden sind. So etwas als Backup zu bezeichnen, wäre auch für mich eine völlig verrückte Idee.
Wir arbeiten hier im Büro seit Jahren mit TimeMachine und es ist einfach nur geil: Wir hatten noch nie ein Problem, welches wir (ich Hobby-Macianer, ansonsten Maschinenbauer) nicht (mit Eurer Hilfe) lösen konnte. Gerade noch eine Excel-Datei zurückgeholt, die ein Kollege etwas verwurschtelt hatte.
Lange Rede, kurzer Sinn: Ich würde niemals TimeMachine über's Netzwerk machen, solange die Technik so bleibt und in ein image geschrieben wird. Mich schüttelt's da, wenn ich nur dran denke (Hobby-Macianer, aber mich schüttelt's trotzdem oder gerade deswegen )
Ansonsten ist es das beste, was ich bislang in den Fingern hatte. Nichts desto trotz praktiziere ich aber auch den paranoiden "Auf 'zig verschiedene Medien-Sichern-Wahnsinn", aber da bin ich wohl nicht alleine… Sei gegrüßt, acuacosxx!

ich trau dem ja auch nicht so (paranoid , lass die tm neben supidupi aber immer mitlaufen. gibts denn eine möglichkeit, ein tm backup auf funktionsfähigkeit zu prüfen? .... ich hatte die situation, das beim letzten hd tausch das tm backup nicht funktionierte und ich heil froh um den supidupi clon war.

virk: Stimmt schon, >90% der Fälle betreffen TimeMachine-Backups auf TimeCapsules oder auch "nicht offiziell unterstützten" NAS.

Aber es ist auch schon vorgekommen, dass ein einfaches TimeMachine-Backup auf einer externen HD (USB oder FW oder Thunderbolt ist dabei irrelevant) "defekt" war und man ein komplett neues Backup anlegen musste (oder aber mühselig "von Hand" retten musste, was noch zu retten ist).

IMHO das größte Manko von OS X bzw. um genau zu sein von HFS+ ist die fehlende Unterstützung von Prüfsummen im Dateisystem!

Dies bieten nur extra Tools wie CCC oder ChronoSync.

Naja, das HFS+ nicht das beste ist, das habe ich mittlerweile mitbekommen. Und dass Dateien mal im Arsch gehen können, auch. Aber bei TimeMachine komme ich halt dann, wie Du so schön schreibst, noch "von Hand" an die Daten. Für mich war das bislang ausreichend.
Naja, vielleicht gucke ich mir ChronoSync mal an. Obschon, das wird nicht viel anders sein als Synchronize(Pro), welches ich bislang vergab, als Backup-Software, die hier läuft zu erwähnen Mit dem Tool schreibe ich unregelmäßig das sich auf dem "Server" geändert habende auf meine interne Platte.

Wie schrieb mal einer so schön: Es gibt zwei Arten von usern: Die, die schon mal Daten verloren haben und die, denen das noch bevorsteht. Zum Glück gehöre ich zur ersten Gruppe.

virk: Synchronize Pro ist mir mit einem wirklich schlechten Support in weniger guter Erinnerung (insbesondere nach der Umstellung von Mac OS 9 auf X), da zeigte sich mal, dass "alteingesessene" Mac-Entwickler leider nicht immer die Besten sind ...

Eventuell hat sich das mittlerweile geändert, aber meine Geduld war mit denen irgendwann am Ende.

Wie gesagt ist der Support von ChronoSync wirklich schnell und sehr bemüht - das ist heutzutage oft Gold wert.

Wenn ersteres einen doch bloß dazu qualifizieren würde das es einen nicht erneut trift

Das kann einem auch mit "offiziell unterstützten" NAS (die die korrekten AFP-Erweiterungen implementieren) geschehen. Das Hauptproblem sind dabei zwei Sachen: TM übers Netzwerk findet nie direkt aufs Dateisystem des Servers statt sondern immer über die Zwischenschicht eines gemounteten SparseBundles. Richtig fragil wird die Geschichte sobald der Platz auf der Servershare bzw. im SparseBundle zu knapp wird. Ich zitier mich der Faulheit halber selbst bzgl. des Unterschieds des Ganzen im Vergleich zum Backup auf direkt angeschlossene Platten:

Es soll sogar schon vorgekommen sein, dass eine HD (USB oder FW oder Thunderbolt ist dabei irrelevant) "defekt" war

Ganz im Ernst: Das kann die furchtbar triviale Ursache gewesen sein, eine andere, dass Leute externe HDs nicht sauber auswerfen (und wenn man das paarmal macht und Murphy's Law zuschlägt, dann schreddert das auch nachhaltig das Dateisystem).

Und dann kommt's immer wieder vor, dass Leute A machen und auf B schließen. Wenn sich bspw. UUID von Rechner oder Volumes ändern dann kippt TimeMachine aus der Kurve, weil es diese UUIDs braucht, um eine eindeutige Zuordnung zwischen Quelle und Ziel herzustellen. In solchen Situationen muß man dann entweder Hand anlegen, um im TimeMachine-Backup UUIDs anzupassen. Oder man fängt halt mit dem Backup von vorne an. Trotzdem wird sowas dann in Foren gerne als "der TM-Scheiß ist auf einmal kaputt gegangen" wiedergegeben (nicht auf Dich bezogen, simple Zusammenfassung einiger Threads hier und dort)

Also wer Letzteres vorhat, mißbraucht ein Backup als Archivierung und dem kann man dann auch nicht mehr helfen. Archivierung ist eine Langzeitsicherung, Backup das Gegenteil davon.

Nein, wie denn? Die bieten auch keine Prüfsummen "im Dateisystem" sondern nur Funktionen, die oberhalb des Dateisystems Checksummen vorher/nachher prüfen können. Wenn man diese Funktionen falsch einsetzt, taugen sie noch nicht mal irgendwas, weil man nicht das, was am Ziel auf Platte geschrieben wurde, mit dem an der Quelle vergleicht, sondern Dank des exzessiven Cachings in OS S und asynchronem I/O de facto nur testet, was geschrieben hätte werden sollen (weil die Daten noch im RAM stecken und von dort gelesen werden)

Nein, warum denn? Der CCC hat kein "Netz und doppelten Boden" bzgl. Zuordnung von Quelle und Ziel. Der CCC nutzt für das inkrementelle Gedöns unter der Haube rsync und das wiederum kennt schon mal zig Varianten, Quelle und Ziel zu vergleichen ("billige" wie bspw. nur modifizierter Zeitstempel für eine Erstselektion der zu syncenden Dateien oder "teure", die gleich auf Prüfsummen beruhen). Dann hat er noch zig Varianten, wie mit Konflikten umgegangen werden soll (bspw. "Ziel -- ggf nur vermeintlich -- neuer als Quelle") oder was überhaupt gesynct werden soll.

Keine Ahnung, welche Parameter Mike Bombich in welcher Version des CCC bei welchen gesetzten Hakerl im GUI verwendet. Aber grundsätzlich guckt rsync/CCC nur auf Dateiinhalte und dateiexterne Metadaten wie bspw. Zeitstempel oder Berechtigungen, Eigentümer, Gruppe. Und korrigiert auch ggf. nur diese: Ich hab erst neulich wieder rsync dazu "mißbraucht", Eigentümer- und Gruppenmapping auf einem neuen Server anzupassen: Die Daten wurden 1:1 geklont, am Ziel wurden dann neue UIDs/GIDs vergeben und rsync anschl. darauf losgelassen. Und das hat blitzschnell nur die externen Metadaten, also Eigentümer/Gruppe angepaßt, weil die Dateien vom Inhalt her identisch waren.

Und genau davon wird man ausgehen können. Bzw. andersherum: Wenn CCC/rsync alle Dateien erneut syncen will, dann hat man entweder was bei der Bestimmung des Zielpfads falsch gemacht (hab ich erst wieder letzte Woche geschafft und blöderweise 70 GByte Daten völlig unnötigerweise ans andere Ende der Welt gesynct, weil ich in einen Unterordner des Zielordners gezielt habe) oder die Dateiinhalte waren auch wirklich alle anders (rsync benutzt einen Modus mit Checksummen über einzelne Dateiblöcke und synct dann nur die sich geändert habenden)

Und das ist was völlig anderes, denn TimeMachine nutzt die sog. UUID des Quelllaufwerks, um sicherzustellen, dass nicht unvorsichtige Anwender sich ihre Backups schrotten. "Neue Platte" (genauer neue Partition) bedeutet auch immer neue UUID und damit bricht die Zuordnung von Quelle und Ziel völlig zurecht auf. Abhilfe mit folgenden Suchbegriffen simpel möglich: time machine uuid of disk change

Soweit ich weiß, nutzen CCC wie auch ChronoSync (und wahrscheinlich aus SuperSuper!) eine Mischung aus asr, rsync und "eigenen Routinen" zum clonen/syncen.

Und dass diese Tools Prüfsummen auf Dateisystemebene unterstützen, habe ich ja gar nicht behauptet. Aber mir ist eine einfache Möglichkeit von checksum-Kontrolle immer noch lieber als das, was der OS X Finder und HFS+ "out of the box" bieten.

Danke Thomas.

Womit man ziemlich aufpassen sollte, wenn man nicht vollständig zu OS X kompatible Storage-Systeme, konkret die der Firma Data Robotics, nutzt. Die Drobos bzw. die Daten des Drobo-Users überleben gerne mal den simplen Aufruf der OS X Funktionalität, die der CCC dafür nutzt, nicht:

http://help.bombich.com/discussions/problems/23911-6tb-of-data-loss-on-my-drobo-on-setting-up-recovery-drive-on-initial-back-up

ChronoSync null Ahnung (ich find die Syncerei völlig überbewertet, steh dafür aber total auf richtiges Backup).

SuperDuper und CCC sind diesbzgl. meines Wissens nach (das bzgl. SuperDuper evtl. schon total veraltet ist) genaue Gegenpole. Ich find übrigens beide Tools nicht schlecht, wenn man weiß, wie und warum man sie einsetzt und wenn man sich nicht konzeptionell aufs Glatteis führen läßt bzgl. Sicherungsstrategie.

SuperDuper macht soweit ich weiß alles selbst, d.h. die ganze Funktionalität steckt im Programm selbst (und war ja vor paar Jahren mal das einzige Programm, das wirklich vollwertig Mac-Dateien von A nach B bekommen hat).

Der CCC macht wiederum gar nichts selbst sondern ist reines GUI für Kommandozeilen-Tools unter der Haube bzw. im System (diskutil, asr, bless, rsync, etc.). Für mich ist Letzteres ein Vorteil, weil ich als Kommandozeilen-Zampano auf dem Weg auch Sachen komplett per CLI automatisieren kann bzw. auch ohne GUI Herumsyncen kann. Und angenehmer Nebeneffekt: Mike Bombich sorgte damit direkt und auch indirekt für Bugfixes in zahlreichen solchen CLI-Tools (seien sie von Apple oder Drittanbietern), bei rsync stammen viele Patches, die das im CCC enthaltene vollwertig machen, auch direkt von ihm.

Dann hab ich "Prüfsummen im Dateisystem" falsch verstanden

Aber letztlich geht es genau darum und warum man ggf. verdammt nah an Themaverfehlung bzw. im "Meer der falschen Sicherheit "segelt, wenn man blind auf Prüfsummen oberhalb des Dateisystems vertraut. Zum Beispiel ist ein direkter Schreibverify durch erneutes Lesen und Prüfsummenbildung in nahezu 100% der Fälle witzlos, wenn sofort durchgeführt. Einfach weil asynchroner I/O zum Tragen kommt und die Antwort nicht vom Zieldateisystem sondern allerhöchstwahrscheinlich direkt aus dem Disk-Cache kommt.

Wenn dann muß man also Sync-Vorgänge und Prüfsummengeprüfe trennen bzw. zeitlich ausreichend weit auseinanderlegen (Zeit ist eigentlich weniger das Kriterium als vielmehr sicherzustellen, dass OS X Disk-Cache inzwischen mit anderen Dateien geflutet ist, damit Lesen von Dateisystem auch wirklich auf dem Dateisystem stattfindet).

Wenn man sich jetzt vor Augen führt, dass es nur ein einziges Mac-Modell mit ECC-RAM gibt, dann kann man die Wirksamkeit von Prüfsummen auch schon wieder fundierter bezweifeln

Usw. usf. -- man sollte halt wirklich das ganzen Datendilemma aus der Perspektive Wiederherstellung angehen. Die für mich sinnigste Antwort liegt in TimeMachine auf 2 wechselweise verwendeten Medien (je Standort, einmal Büro und einmal daheim. Und noch einen Sync zwischen beiden Standorten) gepaart mit bei Bedarf durchgeführten bootbaren Klonen, die vor wichtigen Ereignissen angefertigt werden, so ich nicht zu faul bin.

na dann liege ich mit meiner strategie ja nicht so falsch. timemachine + clon mit superduper. ... trotzdem noch mal zu meiner frage, wie kann ich denn erkennen, das mein tm backup noch ok ist, außer in dem moment, wenn ich es brauche.

Also ich kenne nur die Funktion "Backups überprüfen", die durch Klick auf das TimeMachine-Symbol und gedrückter "alt"-Taste aufzurufen ist. Was die Funktion genau macht, kann ich allerdings nicht sagen.

Die häßliche Antwort: gar nicht. Absolute Sicherheit gibt es eben nicht. Bzw. schlägt auch an der Stelle die alte Güterabwägung "Komfort vs. Sicherheit" zu

Vorab: Das mit "Backups überprüfen" im Menü funktioniert meines Wissens nur, wenn Backup übers Netz gemacht wird, weil man in der Situation vor der Schwierigkeit steht, es mit einem Sandwich aus zwei Dateisystemen zu tun zu haben: Das FS des Servers bzw. Airport-E*/TimeCapsule und obendrauf das im SparseBundle, in das immer übers Netz gesichert wird. Diese Funktionalität Im TM-Menuitem ist der Versuch seitens Apple Dateisystem-Reparaturen in so einer Situation auf den Apple-eigenen TimeCapsules (wo man ja ansonsten schwer oder gar nicht rankommt) zu ermöglichen/erleichtern.

Die Überprüferei reduziert sich also darauf, sicherzustellen, dass das Zieldateisystem intakt ist. Letztlich auch logo, weil TM halt "alles im Dateisystem" sichert (inkl. soz. Backup-Index). Insofern kommt der Integrität des Dateisystems, auf das gesichert wird, eine zentrale Bedeutung für die Integrität des Backups an sich zu.

Jetzt sagt eine alte Bauernregel: "Ein gutes Backup definiert sich einzig und alleine durch die Möglichkeit, Restore und Desaster Recovery ausreichend simpel und in akzeptablem Zeitrahmen hinzubekommen". Das einzig Spannende an Backup ist eben nicht Backup sondern der andere bzw. gegenteilige Vorgang, weswegen man Backup macht.

Und jetzt kann man dem ganzen mehr oder weniger vertrauen bzw. sich durch beliebige Methodik oder das Definieren von Randbedingungen, die für einen gelten sollen, in falscher Sicherheit wiegen.Oder man testet. Und das bedeutet: Restore testen, Desaster Recovery testen. Und das regelmäßig. Eine Antwort, die niemand hören will

Erzähl' nich' so'n Scheiß!

Ich empfehle den Backup Klon neu aufzusetzen, egal ob mit Supersuper oder CCC. kann doch über Nacht laufen.

Ob ein schon vorhandener Klon von SuperDuper oder CCC erkannt wird wenn er mit dem FDP gemacht wurde, weiss ich nicht, ich würde mich nicht drauf verlassen.

Mit dem ZFS Dateisystem ginge das, aber das will Apple ja nicht.

Mit welchem Programm ursprünglich geklont wurde, ist letztlich egal.

SuperDuper! hatte als erstes Programm seiner Art die beim Hersteller Shirt Pocket als "SmartUpdate" bezeichnete Funktionalität implementiert: Einen aktuellen Clone zu schreiben, bei dem noch "alles dazu kommt", was beim ursprünglichen Clone fehlt.

Das dauert dann im Idealfall nur 10-15 Minuten (natürlich nur, wenn sich so gut wie nichts geändert hat).

CCC kann das (und sogar noch mehr) mittlerweile aber auch.

Beide (SuperDuper! wie auch CCC) können auch Clones von gerade laufenden, also gerade aktiven Systemen erstellen.

Das FDP von Apple kann das alles leider noch nicht, dafür ist ein Clone damit aber auch sehr verlässlich (konnte schon immer mit vielen Besonderheiten von HFS+ umgehen, bei dem so einige Backup-Tools scheiterten ... es gab dazu mal einen sehr ausführlichen Test vor ein paar Jahren).

Apple wollte schon aber konnte nicht, da Sun zu dem Zeitpunkt schon in totalem Chaos wegen der Übernahme durch Oracle versunken war (und deren Idee bzgl. Geschäftsmodellen "ein wenig" von denen Suns abwiechen): . Und die andere Aussage ist ähnlich "präzise"

Macht aber nix, hier am Stammtisch geht's ja eh nicht um eine seriöse Betrachtung von Dateisystem- und Backup-Integrität. Und erst recht nicht um das eigentlich Wichtige dabei...

Wenn ich Virk richtig verstanden habe, fragte er, ob er mit Supersuper oder CCC einen mit dem FDP gemachten Klon weiter nutzen kann für ein inkrementielles Backup, oder ob er das neu aufsetzen muss (was ich bevorzugen würde). Dazu hat noch niemand geantwortet.

Naja, doch. Außerdem beantwortet sich die Frage nach der Dauer des ersten Syncs automatisch von selbst. Bzw. ist die Antwort völlig nutzlos, denn ob ich jetzt erstmal wieder aufwändig einen Komplettklon anlege (10-15 Std.) um dann inkrementell hinterherzusyncen oder der erste Sync alles erneut überträgt (10-15 Std.) ist bzgl. der Frage, wie lange der ganze Quatsch dauert, völlig irrelevant.

Wenn man sich mal überlegt, was da bei welcher Variante genau geschieht, dann ist es auch offensichtlich, dass es völlig egal ist, ob man mittels des CCC oder Festplatten Dienstprogramm klont oder differentiell mittels CCC oder SuperDuper! hinterher synce. Das Ergebnis ist entweder anschl. identisch... und wenn es das nicht ist, dann hat man ein Problem und sollte tunlichst auf Werkzeuge, die inkrementell syncen bzw. viel wahrscheinlicher untaugliche Methoden, inkrementell zu syncen (im laufenden Betrieb) verzichten.

ich hab jetzt übrigens mal Marcel Bresinks Definition von Klon vs. Sync verwendet. Normalerweise nutz ich die anders:

- Klon: blockbasiert, d.h. unterhalb des Dateisystems. Kann daher alles transportieren, was egal welches Dateisystem beherrscht (geht ja gar nicht anders, wenn einfach komplette Blöcke von A nach B wandern ohne dass die Struktur innerhalb der Blöcke irgendeine Rolle spielt) und klont daher auch evtl. Fehler im Dateisystem 1:1 mit. Man kann mit speziellen Algorithmen ("delta difference" funktioniert ja auch auf Block- und nicht nur Datei-Ebene) auch inkrementell klonen. Ich kenn kein User-freundliches Werkzeug am Mac, das das anbieten würde

- Sync: passiert auf Dateiebene, d.h. an Quelle und Ziel werden nicht Blöcke sondern Dateien gelesen. Dieser Modus erlaubt ein inkrementelles Vorgehen bzgl. einzelner Dateien und erlaubt es, den Fehler zu machen, ein laufendes System zu klonen

Nach der Definition kann SuperDuper! nur Sync, der CCC beides (nutzt unter der Haube dafür entweder asr oder rsync) und das Festplatten-Dienstprogramm nur Kloning.

Naja, eher nicht:

Da waren nicht nur rsync-Leute schneller und das zugrundeliegende Verfahren beschäftigt in der IT kluge Köpfe durchaus schon deutlich länger.

SuperDuper! wird jetzt grad mal 10 Jahre alt. Mit dem ollen Unix-tar gehen inkrementelle Syncs schon deutlich länger und lange bevor die ShirtPocket-Leute am Start waren, gab's schon angepaßte tar-Versionen für den Mac (genauso wie angepaßte rsync-Versionen für den Mac inklusive GUI), die genau das, was sich SuperDuper! auf die Fahnen schreibt, also das Marketing-Lala "SmartUpdate" (inkl. all der Mac-Spezialitäten wie Finder-Metadaten, Ressource Forks und dem ganzen Unix-Zeugs wie Permissions, BSD-Flags, etc. pp.) ebenso beherrschten.

ShirtPocket hat prima Marketing gemacht, bei den gebräuchlichsten GUI-Tools für "Backup" (in Wirklichkeit stumpfes Gesynce) kamen sie irgendwann vor paar Jahren mal in irgendeinem Review als einzige gut weg bzgl. der Vollwertigkeit des Syncergebnisses. Und davon zehren sie bis heute weitestgehend ohne konkreten Grund. Legendenbildung as usual.

Der CCC war das erste Tool für Laien (weil mit GUI), der überhaupt vollwertig Mac-Dateien unter OS X syncen konnte. Er benutzte dazu ditto (das damals noch einige Fehler hatte -- einen hab ich damals direkt bei Apple gemeldet, die anderen der Bequemlichkeit halber über Mike, den CCC-Autor). Apple selbst hat erst mit 10.2.2 irgendeine Funktionalität in OS X eingebaut, um Dateien vollwertig zu replizieren. In Form von asr, einem CLI-Tool, das dann in Folge von Mike für den CCC aufgegriffen wurde.

Mike hat dann in der Zwischenzeit noch psync eingebaut und ist dann auf rsync umgesattelt, das nun unter der Haube die eigentliche Arbeit beim inkrementellen Syncen erledigt. Viele Patches für rsync im Mac-Umfeld, um neuere HFS+-Funktionalität nachzurüsten, stammen dabei auch von ihm selbst. Mein Dank zumindest für all das, was er für die Mac-Community getan hat, wird ihm eh ewig nachschleichen

Was einerseits eine Scheißidee ist und andererseits solche Mythen wie den folgenden nährt:

Weil das Festplatten Dienstprogramm meist im "block-copy"-Modus läuft und man damit nur ein ruhendes System klonen kann. Und das ist auch gut so. Warum, kann man sich eigentlich ganz prima selbst überlegen, wenn man weiß, wie viele offene -- auch Datenbank- -- Dateien ein OS X so hat. Als erste Übung einfach mal im laufenden System nur die Liste der gerade offenen Dateien ausgeben lassen, bspw. im Terminal per

Ist alles richtig was Du sagst, trotzdem ist es für 99% der Endanwender völlig unproblematisch, einen 1:1-Clone auch aus einem laufenden System heraus zu erstellen, mit SuperDuper! wie auch mit CCC.

Schon hunderte male gemacht und noch nie Probleme damit gehabt, persönlich wie auch etliche Kollegen und auch Klienten.

Welches damalige rsync- Tool inkl. GUI Du meinst, das tatsächlich schon verlässlich all die Eigenheiten von HFS+ beherrschte, würde mich übrigens auch mal interessieren (ich kenne da nämlich keins, aber ich bin ganz Ohr) ...

Hier ein Riesenfass aufmachen und die Leute von Shirt Pocket als werbepalavernde Typen dastehen lassen, ist ja wohl ganz schlechte Erziehung, oder? Immerhin hatte David Nanian (der Chef von Shirt Pocket) schon vor 10 Jahren satte 20 Jahre Erfahrung im professionellen Softwareentwicklungsumfeld gesammelt ... da können wir beide sicher nicht mithalten.

Fakt ist, dass SuperDuper! seit nunmehr 10 Jahren verlässlich seinen Dienst verrichtet und selbst CCC damals (noch zu 10.4 Zeiten und früher) bei weitem nicht so zuverlässig lief wie SD. Mittlerweile hat CCC da wieder gut aufgeholt, aber es gibt nach wie vor jede Menge "Backup-Tools", die mehr versprechen, als sie letztlich einhalten können (ganz vorn mit dabei die mitgelieferten Tools diverser Festplattenhersteller).

Bzw. korrekt ausgedrückt: Weder Dir noch Kollegen oder Klienten sind bislang Probleme aufgefallen bzw. habt Ihr die dadurch entstandenen Probleme dem falschen Vorgehen zuordnen können

Es geht halt nicht unfallfrei!. Wenn man das Ganze im Detail betrachtet, wird man verstehen, dass man sich dadurch am Ziel Probleme erzeugt, die man in der Regel erst sehr viel später bemerkt (nämlich nachdem man auf einen partiell inkonsisteten Klon aufsetzt, um davon zu booten) wenn denn überhaupt, weil man sich meist nicht vorstellen will oder kann, dass etwas, das einem seitens Softwarehersteller als supertoll angedient wird (und wer will es ihnen übelnehmen, die wollen ja schließlich einen Kaufreiz triggern), dann doch nicht so supertoll ist?

Apple und Softwarehersteller haben mit der Zeit gelernt, dass es müßig ist, die Ursachen zu bekämpfen und sind daher im Workaround-Modus unterwegs. Wenn Dich interessieren sollte, was da für Probleme zu lösen sind und warum das bei "echtem Backup" witzigerweise einigermaßen egal ist, kannst Du hier weiterlesen. Mir ist die Zeit grad zu schad, weiterzutippen oder altermative Beschreibungen des Problems zu suchen, daher nur konservierter Senf: und

Ich schrieb, dass sie gutes Marketing gemacht haben und dass die Bewertung der Lösung "in der Community" dann so 'ne Art Selbstläufer war, von dem sie immer noch zehren -- aber egal

Der CCC hatte auch schon in seiner frühen Form (ditto nutzend und damit bei Dateien mit sehr langen Dateinamen versagend) seine Berechtigung. Heute und mit der ganzen neuen und verbesserten Funktionalität selbstredend auch.

SuperDuper! hatte und hat dito seine Berechtigung (wenn man weiß, wofür man es einsetzt). Aber hat und hatte nie wirklich irgendein Alleinstellungsmerkmal.

Die Welt dreht sich und es gibt inzwischen seit 10.5 eine ziemlich und ab 10.8 eine nahezu perfekte Backup-für-Einzelkämpfer-Lösung (weil man ab 10.8 ohne Geschissel mit rotierenden Backup-Medien umgehen kann), die gratis beiliegt und die man -- mit ein klein wenig Wille und Adaption von Grundlagen, was bei welchem Verfahren passiert und gegen welches Verfahren konkret nicht schützt -- bevorzugt nutzen sollte.

Eine 1:1-Kopie des Systems vorrätig bzw. aktuell zu halten, kann flankierend für manche Zwecke nützlich sein. Diese 1:1-Kopie aus dem aktuell produktiven System im laufenden Zustand zu erzeugen, kann Probleme nach sich ziehen, die man ohne Analyse nicht gleich oder gar nie bemerkt.

Alleinig auf eine 1:1-Kopie ohne Versionierung zu vertrauen ist aber salopp gesagt doof. Zumindest seit es in Form von TimeMachine was viel Besseres gibt. Die ganze reichlich akademische Betrachtung bzgl. Backup vs. Sync vs. Klon läßt sich von der anderen Seite her viel sinniger angehen (also vor was will ich mich schützen und was erwarte ich in welcher Situation, wenn der GAU oder auch nur der kleine Datenverlust zwischendurch eintritt?). Weil sich dann automatisch die Anforderungen an den Mechanismus, der meine Daten sichern soll, ergeben. Dito bzgl. Kombination mehrere Ansätze

Das war's dann mal von meiner Seite

Ja, das hatte mich interessiert und zwar ehrlich gesagt, aus dem Grunde, dass ich meiner Platte einen solchen Stress nicht unnötig öfter als nötig antun möchte
Wenn eine solche Session läuft, die ja ca. 10-15h dauert, und man dann mal öfter ins Bürochen geht, um mal zu sehen, wie lange es denn noch dauert, dann fragt man sich:"Mann, wie halten diese kleinen Dinger das aus? Klackerklackerklackerklackerklackerklackerklacker…….., die ganze Zeit."

Aber zurück zu meiner Ausgangsfrage, ob CCC/SuperDuper beim seinem ersten Klon bereits inkrementell klont, das weiß ich tatsächlich noch nicht, werde mich da aber mal in der Anleitung schlau machen, obschon ich befürchte, dass ich nicht fündig werde, da ein solches feature wohl kaum vom user gefragt ist, und somit wohl auch nicht "zugesichert" und beschrieben wird.
Ich werde berichten!

Der Vorgang, der Dir vorschwebt, ist exakt dasselbe wie ein stinknormaler inkrementeller Sync (oder "SmartUpdate", wenn die Marketingabteilung spricht, um sich von dem branchenweit bekannten Ausdruck abzusetzen).

Jedes Tool, das Dir sowas anbietet, kann nicht anders, als innerhalb der Volumes an Quelle und Ziel die kompletten Verzeichnisstrukturen abzuklappern, zu vergleichen und -- wenn es denn wirklich inkrementell, d.h. nur das Datendelta transportierend agiert -- dann die Änderungen zu syncen.

Ergo: Hat sich nichts geändert, wird nichts gesynct, hat sich wenig geändert, wird wenig gesynct (das im CCC zum Einsatz kommende rsync kann dabei sogar auf einen Modus zurückgreifen, bei dem es zwischen Dateien nur die zwischen Quelle und Ziel geänderten Blöcke synct, was sich gerade bei fetten Dateien, deren Inhalt sich nur bisserl aber das auf bestimmte Weise -- append -- geändert hat, positiv auswirkt). SuperDuper! kann das evtl. auch -- keine Ahnung.

Wenn Du die Tools im imkrementellen Modus nutzt und sich wenig geändert hat, dann wird auch wenig gesynct.

Der von der völlig anderen Funktionalität bzgl. des TimeMachine-Verhaltens nach irgendeinem Gesynce herrrührende Irrglaube beruht auf der Ausblendung der Tatsache, dass TimeMachine einen anderen Zweck hat. TimeMachine will Backups anfertigen und muß sich daher um Datenintegrität sorgen. Und das permanent. Deshalb guckt TM nicht nur den Inhalt von Volumes an, sondern auch außen auf die Volumes, konkret die UUID, um Volumes immer eindeutig identifizieren zu können (UUID kann man im Festplatten-Dienstprogramm nachgucken).

Wenn ich -- wie auch immer, der konkrete technische Vorgang dabei ist völlig egal -- den Inhalt eines Volumes auf ein anderes kopiere/synce/klone, dann sind das eben immer noch zwei völlig verschiedene Volumes. Dass Du das eine Volume nicht mehr brauchst und dafür das andere in Zukunft hernehmen willst, ist das eine. Aber das kann eine Backup-Software nicht riechen. Für die sind das einfach zwei unterschiedliche Volumes, denn die hat keinen Hellseher an Bord, der weiß, dass Du eine bewußte Entscheidung bzgl. Ersatz eines Volumes getroffen und in Zukunft das neue anstatt des alten nutzen willst.

Und da das für TM zwei Platten sind, mußt Du einen neuen Backup-Zyklus für die neue anfangen (das ist nichts weiter als ein Sicherheitsnetz, um Dich als User davor zu schützen, dass Du bspw. irgendwann eine gleichlautende Quellplatte anschließt, dann das Backup diese als identisch zu der anderen gleichlautenden ansieht und aus Versehen ältere Sicherungen aus dem Backup schmeißt, wenn am Ziel der Platz knapp wird. Backup ist darauf ausgelegt, ohne User-Eingriffe sicher im Hintergrund richtig zu funktionieren. Das kann nie solche Entscheidungen selbst treffen und muß den User im Zweifel schützen)

Oder -- wenn Du um die Vorgänge weißt und das mit den UUIDs verinnerlicht hast -- kannst Du durch simple Anpassung eben der UUID innerhalb des TM-Backups TM einfach weitermachen lassen. (schrub ich hier aber alles schon im Thread )

Einem Sync-Tool ist Datenintegrität naturgemäß egal (ggf. kaputte Daten an der Quelle rein, kaputte Daten am Ziel raus), das schaut nicht außen auf die Volumes (vielleicht hat das aber das ein oder andere Tool inzwischen nachgerüstet -- dass es schlauer ist, auf UUIDs anstatt Volume-Namen zu setzen, spricht sich ja grad so langsam rum) sondern nur die Struktur und den Inhalt innerhalb der Volumes an. Zumindest, wenn Du es richtig einstellst. Aber können tun das beide. Ich zumindest hab in den letzten Jahren kaputtgesyncte Systeme "forensisch" untersuchen dürfen, die sowohl von dem einen als auch dem anderen Werkzeug lädiert wurden.

So! Ich habe am 31.01.2014 zurück von der neuen Seagate-Platte auf die alte WD-Platte geklont. Wie hier schon angedeutet/berichtet, hat der Klon nicht lange gedauert: 38 Minuten für lediglich 13,38GB. Das war genau das Verhalten, was ich mir mangels Wissen lediglich erhoffen konnte.
Schönen Sonntag noch!

Gruss Heiner