Moin Moin

Um ein Backup meines Benutzerordners zu machen, habe ich mich für die Lösung mittels rsync entschieden.
Die Ordner
~/Library/Caches/com.apple.helpd
~/Library/Metadata/CoreSpotlight
.Trash*
habe ich vom Backup ausgeschlossen, die ersten beiden konnten sowieso nicht gesichert werden (permission denied) - um die Fehlermeldungen zu vermeiden, habe ich sie also ausgeschlossen.

Diesen Befehl habe ich dann zum sichern auf eine leere externe Festplatte benutzt:

Die Größe meines Benutzerordners wird mit 384,17 GB angezeigt. Der Papierkorb ist leer, CoreSpotlight hat 114,8 MB und com.apple.helpd 39,7 MB.
Der gesicherte Benutzerordner auf der externen Festplatte ist 334,74 GB groß.

Jetzt meine Frage:
Sollte der gesicherte Ordner nicht eigentlich von der Größe her dem originalen Benutzerordner abzüglich der ausgeschlossenen Ordner entsprechen?
Woran kann es liegen, dass das Backup fast 50 GB kleiner ist?

rsync version 3.2.7, Ventura 13.0.1

Möglicherweise "Sparse Files"?

Vergleiche mal die Anzahl der Dateien, da sollte der Unterschied gering sein.

Eventuell hast du auf dem APFS-Volume auch Dateien mit Versionierung gespeichert, also mit einem Diff zur letzten Version - rsync sieht dann aber nur die zuletzt gespeicherte Version.

Dann kann es sein, dass Metadaten zu den Dateien nicht in der Datei selbst sondern in den extended attributes gespeichert sind, die möglicherweise von rsync nicht mitgenommen werden. Die Datei selbst hat die gleiche Größe aber der Verzeichniseintrag ist größer und wenn du dir die Größe des Verzeichnisbaumes anzeigen lässt, zählt der Platz für die Verzeichniseinträge mit. SOlche Metadaten werden zum Beispiel für Downloads mit Safari angelegt, aber beispielsweise auch, wenn man verschiedene Dateitypen mit codesign signiert - und solche können dann wieder im Downloads-Verzeichnis liegen (heruntergeladenen Apps).
In dem Fall könnte ditto helfen zuerst ein tgz mit den extended attributes zu erzeugen und dann dieses mit rsync zu übertragen.

Auch Resource-Forks könnten unter den Tisch gefallen sein. rsync kopiert möglicherweise nur die Data-Fork von Dateien und Resource-Forks werden leider noch immer bei bestimmten Vorgängen verwendet.

Dazu können noch Dateien gehören, die klein genug sind, um nicht physikalisch als Datei abgelegt zu sein sondern deren Inhalt in extended attributes des Verzeichniseintrags abgelegt werden - aber die sollte rsync eigentlich kopieren können.

Okay, warum ich erst nach verfassen des Beitrages darauf gekommen bin, die einzelnen Ordner mal durchzuchecken um zu sehen wo die Differenz liegt, kann ich nicht sagen...

Aber dabei ist mir aufgefallen, dass die Fotos Mediathek nicht richtig gesichert wurde.
Die Mediathek hat im original 47,68 GB, das Backup lediglich 31,6 MB. Hier scheint also das Problem zu liegen... warum auch immer.

Jedoch gibt es bei anderen Ordnern auch Unterschiede, wenn auch nur "recht" kleine:
Ein Ordner, in dem sich viele Fotos und Videos befinden z. B., das Original hat 219,64 GB und die Sicherung 219,52 GB. Das sind zumindest auch 120 MB Unterschied - muss ich mir da jetzt Gedanken machen, dass einige evtl. für mich wichtige Daten nicht gesichert wurden?

Testweise habe ich den Ordner nun auch noch einmal einzeln mit rsync gesichert, ganz ohne --exclude. Das Ergebnis ist jedoch dasselbe, 129,52 GB.

Kann es sein das die beiden Systeme andere Datenblockgrössen brauchen? Das kann bei vielen kleinen Dateien natürlich einen Unterschied machen.

Welches Dateiensystem benutzt der Mac und welches die externe Festplatte?

Vielleicht handelt es sich da im Quicklook-Metadaten, also den kleinen Vorschauen für Finder und anderen. Je nachdem wo diese gespeichert werden, werden diese nicht per rsync erreicht. Schau mal ob auch "hidden" Files drin sind als zB Dateien und Ordner deren Namen mit einem "." (Punkt) beginnen. Eigentlich sollte rsync diese mit auch kopieren, aber vielleicht klappt das nicht. Ich hatte mal ein Git-Repository mit rsync zu einer Linux VM synchron gehalten und Git enthält viele solcher Dateien oder Verzeichnisse. Das hat immer geklappt.

Vergleiche mal diese Verzeichnisse im Terminal mit "ls -al" um sowohl extended attributes (@ am Ende der Zugriffsrechte) und versteckte Dateien/Verzeichnisse (. am Anfang) prüfen zu können. Der Finder zeigt ja nicht alles an.

Füge mal die Option "-E" deinem Befehl und probiere es erneut.
Laut manpage sorgt -E dafür dass extended attributes und resource forks mit kopiert werden.

Bei gleichem Ergebnis, liegt es wenigstens nicht daran

So eine Funktion gibt es bei APFS überhaupt nicht.

Es kann aber an folgenden Dingen liegen:
- Du hast dem Programm rsync keine Datenschutzbefugnis für Festplattenvollzugriff erteilt. Es darf dann keinerlei Dateien sehen, die die Privatsphäre von Benutzern betreffen, wie z.B. Fotos, Dokumente, Datensicherungen, Safari-Einstellungen, etc.
- Du arbeitest mit Programmen, die sogenannte "Data Vaults" benutzen. Das sind Ordner, die generell tabu sind und nur von Time Machine, von Apple genehmigten Datensicherungsprogrammen und vom Originalprogramm, das diese Daten angelegt hat, gelesen werden können.
- Erweiterte Attribute wurden möglicherweise nicht gesichert.
- Quell- und Ziel-Volume haben unterschiedliche Vorgaben bezüglich "transparenter Datenkompression im Dateisystem" oder Behandlung "dünn besetzter" Dateien.
- Quell- und Ziel-Volume verwenden extrem unterschiedliche Blockgrößen.

Doch, nennt sich Snapshots - ist gerade dafür ausgelegt, dass Datensicherungen effizienter sind.

Ich denke, er sollte es auf jeden Fall erst einmal mit der -E Option versuchen. Extended Attributes und Resource-Forks können schon mal größer werden.

Nein, Snapshots gibt es nur auf Volume-Ebene, nicht auf Dateiebene. Wenn man dateiweise mit rsync sichert und dann Quell- und Zielordner vergleicht, können Snapshots überhaupt keine Rolle spielen.

Es wäre aber möglich, dass der Finder die Größe der Dateien innerhalb des Ordners inklusive der in Snapshots gespeicherten Versionen mitzählt, da der Finder ja den belegten Speicherplatz anzeigt - und der Speicherplatz ist dadurch belegt. Finder benimmt sich ja in mancherlei Hinsicht auch mal etwas seltsam, gerade was die Anzeige des belegten Speichers angeht. Kommandozeilen-Tools hingegen werden davon nicht alles sehen.

Aber zugegeben, ich habe mich bislang noch nicht damit beschäftigt zum Beispiel die Angaben vom Finder mit "du" zu vergleichen.

Wäre für den TE vielleicht auch mal eine Variante - mal die Finderangabe zur Größe des Verzeichnisses mit den Ergebnissen von du zu vergleichen. Die müssen nicht übereinstimmen - je nachdem, wie der APFS-Treiber Snapshots etc. behandelt.

Bei solchen Diskussionen kommt mir immer die Frage: geht es nur mir so?

Die Annnehmlichkeiten des heutigen Systems – solange es funktioniert – sind 1A. Wenn aber Probleme/Fragen aufkommen, konnte man früher alles einfacher erklären/verstehen/beseitigen…

Nein, das ist unmöglich, da sich diese Dateien aus Sicht des Finders in Virtuellen Volumes befinden, die normalerweise nicht gemountet sind.

Nein, der Finder zeigt den von Dateien belegten Speicherplatz in gemounteten Volumes an. Die Snapshots befinden sich wie gesagt auf anderen Volumes, die hier keine Rolle spielen.

Nein, es gibt immer nur damit Verwirrung, dass der Finder nicht den freien Speicher, sondern die Summe aus freiem und löschbarem Speicher als verfügbaren Speicher anzeigt. Ein Teil des löschbaren Speichers kann auch aus Snapshots bestehen.

Dann mag dem so sein. Es war auch eher spekulativ und wenn du es genauer weißt als ich, dann ist das in Ordnung.

Vielleicht erhellt uns der TE dann bald damit, ob -E als Option bei seinem rsync Aufrufs sein Problem löst. Ich kann mir schon vorstellen, dass Resource-Forks und Extended Attributes. Ob es so viel ausmacht (ca. 13%), kann ich nicht abschätzen - aber es kann schon was zusammen kommen.

Vielen Dank für die vielen Antworten hier - über das Wochenende war ich (ohne Mac) weg und kam die Tage nicht dazu, hier auf die vielen Kommentare zu Antworten.


Danke, -E hat zwar die Datengröße insgesamt verändert, aber es gab dennoch einige differenzen. Dein Beitrag hat mich allerdings am Ende auf die richtige Spur geführt: Mit den Optionen -abEXUNH haben zumindest meine Dokumente, Medienordner etc. eine Identische Größe.


Danke, aber mir hilft ja nicht, wenn die Anzahl der Dateien stimmt, aber die Größe sich dermaßen unterscheidet... wie z. B. die Fotos-Mediathek, wo nur wenige MB gespeichert wurden. Recht hattest du mit den Metadaten etc., siehe den Fettgedruckten Teil meiner Antwort.


Danke, aber ist beides APFS (verschlüsselt).

Du siehst schon, wie riesig die Differenz ist? Quicklook-Metadaten sind ja nicht um ein vielfaches größer als die Originaldateien...

Mit den o. g. Optionen stimmt auch die Größe der Fotos-Mediathek - wobei mich wirklich wundert, warum mit den Optionen -ab nur 31,6 MB von 47,68 GB gespeichert wurden...

Zudem hatte ich damit manchmal völlig andere Ergebnisse als mit dem selben Optionen zuvor.
Backup gemacht, Größe verglichen (Backup ca. 336 GB). Backup gelöscht, mit den selben Optionen erneut durchgeführt, und die Größe betrug ca. 358 GB etc. - für mich nicht nachvollziehbar.


Vielen Dank für eure Mühe, mit den Optionen -abEXUNH ist das Problem für mich behoben und ich habe Backups, die mir ein gutes Gefühl statt mulmigen Gefühlen geben.

Es freut mich, wenn mein Post zumindest Teil der Lösung war.
Die rsync-Version auf meinem Rechner ist allerdings älter und die Optionen -XUN gibt es dort nicht - zumindest nicht in der manpage. Daher konnte ich sie auch nicht erwähnen