Wie erkennen diese Programme so rasend schnell, was sich geändert hat? Was steckt da für eine Technologie oder Prinzip dahinter?

macOS protokolliert alle Änderungen im Dateisystem seit dem letzten Backup.

- Und da wird auch nichts inkonsistent?
- Was also an Änderungen - warum auch immer - nicht aufgeführt ist, wird nicht berücksichtigt?!
- Noch eine Frage: Wie lange bleiben diese Änderungen denn erhalten? Wie groß darf/kann diese "Datei" werden?

CCC scannt alle Verzeichnisse und prüft die Dateien, jedenfalls bei meiner Version - weswegen das recht lange dauert bei großen Festplatten mit vielen eher kleinen Dateien.
TM orientiert sich bei „bestimmungsgemäßem“ Gebrauch an .fseventsd (nehme ich jedenfalls an) - ist der Abstand zur letzten Sicherung aber zu groß, wird auch bei TM die Platte gescannt, das wird dann unter „Backup vorbereiten“ angezeigt und kann auch recht lange dauern.

Falls das weiterhilft: .fseventd ist (bei mir, High Sierra) ein Ordner mit 160 Dateien und zusammen 12 MB, erstellt im Januar (keine Ahnung, warum, da war nichts besonderes), die älteste Datei stammt vom 23. Juli, also vor zwanzig Tagen.

Nein.Es werden alle Änderungen aufgeführt.

Diese Technologie gehört zu den tiefsten Innereien von macOS bzw. des Dateisystems und muss rock-solid sein und ist es auch. Dass es da zu Inkonsistenzen kommt, ist so wahrscheinlich wie ein korrumpiertes Dateisystem.

Ich bin allerdings momentan nicht auf dem aktuellen Stand, was die Details der Materie betrifft. APFS könnte hier Änderungen durch seine Snapshot-Fähigkeiten bewirkt haben.

Ich wüsste aber nicht, dass Carbon Copy Cloner diese Technologie nutzt. Ich kann auch überhaupt nicht nachvollziehen, dass Carbon Copy Cloner „rasend schnell“ zu Werke ginge. Es gab früher mal ein Backup-Programm (Synk Pro), was diese Technologie ebenfalls nutzte, aber ich glaube, das führte ein eigenes Änderungsprotokoll. Wenn die Technologie nur von Time Machine genutzt wird, kann das ja sagen, ab wann es die Daten nicht mehr braucht.

CCC nutzt die APFS-Snapshots:

Das schreibt CCC dazu selbst:
Also bei mir ist CCC seit Version 6 zumindest gefühlt viel schneller ...

Beim Backup von HFS+-Medien dient die FSEvents-Database als Grundlage für der Ermittlung der Änderungen, ausgenommen im Fall, dass backupd sich entscheidet, einen langwierigen Scan durchzuführen, wie von almdudi erwähnt. Beginnend mit der Sicherung von APFS-Medien diente der Vergleich von Snapshots die Grundlage. Seit macOS Big Sur wird wieder die FSEvents-Database genutzt, sagt jedenfalls Howard Oakley: .

Geht es Dir hier vor allem um die Datenintegrität? Da helfen dir möglicherweise die Tools Dintch und Fintch von Howard Oakley

Aber nicht im Zusammenhang mit der (für ein Backup auf ein externes Medium erforderlichen) Feststellung, welche Dateien sich geändert haben.

Danke! Ich nutze Carbon Copy Cloner ganz ganz selten, meinte mich zunächst auch zu erinnern, dass sich in der neuesten Version was geändert hat, fand dann aber auf die Schnelle nichts dazu und verwarf die Erinnerung daher als eingebildet.

Du hast Recht, danke für die Korrektur meines maroden Hirns!

Für mich liest sich das aber so, daß CCC Snapshots nutzt:und

Ja, sowas hatte ich im Sinne.
Interessant. Danke für den Link zu dem aufschlussreichen Text und für Deine knappe, aber gute Zusammenfassung der Situation!

Wo ist denn der Unterschied zwischen Dintch und Fintch? Ich kann die Erläuterung so oft lesen, wie ich will, ich begreife ihn nicht. 🙄

Fintch = Dintch light. Das macht er bei anderen Programmen auch, z.B. Bailiff = Cirrus mit weniger Funktionen. Ein bißchen seltsam, wenn alle Tools ohnehin kostenlos sind.
Ach ja, und cintch = Dintch für die Kommandozeile.

Ja, natürlich nutzt Carbon Copy Cloner Snapshots, aber als Backup-Option, nicht, um festzustellen, welche Dateien bei einem herkömmlichen Backup auf ein externes Medium (Snapshots sind prinzipbedingt ja immer auf demselben Medium) kopiert werden müssen. Wo in den von Dir zitierten Textstellen meinst Du einen diesbezüglichen Hinweis zu erkennen?Das beschreibt lediglich, warum es problemlos möglich ist, ein Backup von einem Volume zu erstellen, auf dem gerade gearbeitet wird. Das machen, seit es diese Möglichkeit gibt, praktisch alle wichtigen macOS-Backup-Programme (Time Machine, Carbon Copy Cloner, SuperDuper!, …).
Hier geht es um die Wiederherstellbarkeit einer vorangegangenen SafetyNet-Version.

Meintest du noch grundlegendere Unterschiede?

Wo steht das? In der verlinkten Programmbeschreibung steht es nicht …

Im übrigen bestätigt das ja marms Aussage, dass das eine Programm die Light-Version des anderen ist.

So schräg fand ich meine Erklärung nun auch nicht
KarstenM hat schon recht mit seinem Zitat. Demnach ist Fintch eher für Dateien-Checks und Dintch für umfangreiche Verzeichnisse ausgelegt.
Oakley hat einen umfangreichen Text-Output, wo man sich die Infos zusammenlesen/-reimen muss...

Ich hab mir das nie im Detail angesehen, aber ich würde erwarten, daß schlicht "der Snapshot" übertragen wird. Das sind dann die Daten zwischen dem letzten (n) und vorletztem Snapshot (n-1). Falls auf dem Ziel der vorletzte Snapshot (n-1) nicht vorhanden ist, würde ich erwarten, daß dann zwei Snapshots (also die Daten zwischen n-2 und n) gesichert werden.

Aber wie gesagt, nur halbwissen. Bin für eine Korrektur offen.

Der Smiley bezog sich auf das verwirrende Faktum, nicht auf Deine luzide Erklärung desselben.

Nein, so geht das nicht. Der ganze Gag an Snapshots ist ja gerade, dass sie aus API-Sicht das komplette Dateisystem (zu einem bestimmten Zeitpunkt) darstellen; wenn Du „den Snapshot“ kopierst, kopiert Du das komplette Dateisystem. Es gibt in APFS-Snapshots keine Info darüber, was sich gegenüber dem vorangegangen Snapshot geändert hat. Du müsstest also die zwei Snapshots auf Differenzen scannen und das ist letztlich auch nichts anderes, als früher auf Differenzen zwischen letztem Backup und aktuellem Zustand der Quelldisk zu scannen.

Ich war mir diesbezüglich vorhin unsicher, habe aber jetzt nochmal nachgelesen. Selbst Apple, die Zugriff auf Interna hätten, die die API von APFS nicht offenlegt, und wohl irgendwas in der Richtung probiert haben, sind ja eben mittlerweile zu FSEvents zurückgekehrt.

Und Phil Philipp hat doch bereits eingangs zitiert, dass Carbon Copy Cloner selbst explizit angibt, FSEvents zu verwenden:

Wenn du nur EIN Snapshot hast, ist es das gesammte Dateisystem, stimmt. Aber jeder weitere Snapshot ist dein Diff zum vorherigen Snapshot. Deswegen sind Backups via Snapshots ja auch so effizient. Bei ZFS kannst du z.B. deine Snapshots mit zfs send zu einem Rechner schicken und somit deine Backups machen. Such mal nach "zfs backup send receive". Da bekommst du unendlich viele Links.

Die Details kenne ich aber auch nicht mehr. Ich hatte mir das vor Jahren bei ZFS angesehen. Zu der Zeit gab es noch eine OSX-Beta mit ZFS, was aber leider im Release wieder raus war. Danach gab es dann Zevo(?). Ich müsste mich da auch erstmal wieder reinlesen.

Das steht auf der verlinkten Seite (https://eclecticlight.co/dintch/), wenn du zu cintch scrollst, bei den „ Known Issues:“

Nein, eben nicht. Auch wenn es intern natürlich so wie von Dir beschrieben funktioniert, aus Sicht der API ist jeder Snapshot wieder das gesamte Dateisystem, aber zu einem anderen Zeitpunkt. Es gibt keine API, um nur auf das Diff zuzugreifen, jedenfalls kenne ich keine. Wenn es die gäbe, würde Apple selbst sie sicher nutzen. Sie nutzen aber FSEvents.
Das weiß ich alles. APFS ist aber nicht ZFS.

Danke!

Isja auch logisch: Die Unterschiede zwischen Dintch und Fintch stehen natürlich bei cintch … 🙄

@Waia: wenn das wirklich so ist… warum haben die dann die Snapshots gemacht?!? Das ist doch eines DER Features, die man dadurch bekommt?!?

Ein Snapshot umfasst immer genau ein ganzes lokales APFS-Volume. Ein Dateisystem sind ja mittlerweile mehrere Volumes, die wie eins dargestellt werden.

Hat mal jemand einen Link, wo das mit den APFS-Snapshots mal etwas ausführlicher beschrieben steht. So mit Grafiken und so? Das erscheint mir doch sehr schräg, was APFS-Snapshots sein sollen. Das macht irgendwie wenig Sinn?!?

OK, ich meinte das Dateisystem auf einem Volume.

Es gibt ja noch andere wichtige Gründe für Snapshots. Warum sie das nicht so wie bei ZFS implementiert haben – keine Ahnung.

Möglicherweise ist ja FSEvents auch eine konstante opake API, hinter der sich währenddessen auch ein Zugriff auf APFS-Snapshot-Diffs verbirgt? Ich weiß nicht, ob die Implementation von FSEvents zum Open-Source-Teil von macOS gehört – ggf. könnte man da mal nachsehen.

Das ist ein Missverständnis. Ein Snapshot enthält zwar genau die Datenmenge eines Diffs, aber er ist nicht so gespeichert. Vereinfacht gesagt ist ein Snapshot ein zweiter Verzeichnisbaum, der das gesamte Dateisystem zu einem anderen Zeitpunkt zeigt, mit Zeigern auf die gleichen oder – bei Änderungen – auf die früheren Datenblöcke, die ja nicht gelöscht oder überschrieben werden.

Snapshots auf dem Quell-Volume erhöhen nicht die Effizienz, sondern die Konsistenz, da man die Daten sichern kann, während sie sich ändern. Snapshots auf dem Ziel-Volume ermöglichen es, die Datensicherung nur mit dem Speicherverbrauch von Diffs, aber ohne eigentlich verbotene Operationen (wie die früheren Ordner-Hard-Links in der alten HFS-Version von Time Machine) zu speichern.

APFS und ZFS verwenden beide die "Copy-on-Write"-Architektur zum Speichern von Snapshots. Bei "zfs send" kann man auf Wunsch eine inkrementelle Sicherung senden. Aber da wird das Diff durch den Vergleich zweier Snapshots berechnet, es ist nicht so gespeichert.