Ich verwende es rsyncfür inkrementelle Sicherungen und nutze dabei die --link-destOption, auf die vorherige Sicherung zu verweisen, sodass unveränderte Dateien fest mit dieser verknüpft sind.
Das funktioniert, aber nicht für alle Dateien. Ich habe beispielsweise ein Verzeichnis im Backup, das Dateien enthält, die seit über drei Jahren nicht geändert wurden. Aber aus irgendeinem bizarren Grund sind nur einige davon Hardlinks.
Unpraktischerweise sind die größeren Dateien alle Kopien (d. h. es gibt nur einen Link zu der Datei, der über geprüft wird ls -l). Aber das ist auch bei einigen kleineren Dateien der Fall, und tatsächlich sind einige fest verknüpfte Dateien größer als einige kopierte Dateien.
Es scheint kein Muster zu geben, anhand dessen ich vorhersagen kann, welche Kopien und welche Hardlinks sind. Dateinamenlänge und Dateigröße scheinen irrelevant, ebenso wie das Änderungsdatum: Sowohl in den kopierten als auch in den Hardlink-Listen gibt es eine Mischung aus all diesen. Das heißt, die Dateienerscheinenum über mehrere Backups hinweg konsistent zu sein, sodass das, was bei einem Backup passiert ist, auch beim nächsten Backup passiert zu sein scheint.
Gibt es ein Attribut (technisch oder anderweitig) einer Datei, eine Funktion, die dazu führen würde, rsyncdass die Datei kopiert wird, anstatt sie fest zu verknüpfen?
BEARBEITEN 1:Die Erwähnung von „Attribut“ brachte mich auf die Idee, dass es ein Attribut gibt, das ls -lnicht aufgeführt ist, aber einen Einfluss haben könnte. Die Erwähnung lsattrim Quellverzeichnis zeigt jedoch, dass alle Dateien identische Attribute haben.
BEARBEITEN 2:Ich habe zuvor gesagt (inzwischen gelöscht), dass die Berechtigungen alle gleich seien, aber das war falsch. Die Berechtigungen waren im Zielverzeichnis (gesichert) gleich. Ich verwende --perms(um die Berechtigungen beizubehalten), daher weiß ich nicht, warum die Berechtigungen nicht beibehalten werden. Ich habe es zuvor auch als Nicht-Root-Benutzer ausgeführt, versuche es jetzt aber als Root, falls das einen Unterschied macht, aber die Berechtigungen werden immer noch nicht beibehalten, was möglicherweise der Grund dafür sein könnte, dass einige Dateien so aussehen, als hätten sie sich geändert – die Datei hat sich nicht geändert, aber ihre Berechtigungen haben sich anscheinend geändert (zumindest im Vergleich zur vorherigen Sicherung mit ihren falschen Berechtigungen).
BEARBEITEN 3:mount.cifsIch denke jetzt, dass es etwas mit meinem CIFS-Server zu tun hat. Auf der Manpage steht etwas zu der file_modeOption: „Wenn der Server die CIFS-Unix-Erweiterungen nicht unterstützt, überschreibt dies den Standarddateimodus.“ Wenn ich mountden Befehl ohne Argumente ausführe, um die Mounts aufzulisten, enthalten die aufgelisteten Optionen file_mode=0755und dir_mode=0755was mit dem übereinstimmt, was ich sehe. Ich kann keine chmodDatei auf dem Mount haben, daher gelten die Dateien, die ursprünglich keine Berechtigungen hatten, 0755als geändert und werden daher erneut kopiert – und erhalten aufgrund des Mounts erneut die falschen Berechtigungen im Backup.
Antwort1
Eher ein Workaround als eine Lösung. Ich vermeide jetzt die Verwendung von --perms/ -poder allem, was dies impliziert. Natürlich werden dann meine Berechtigungen nicht kopiert, aber zumindest denkt es nicht, dass eine unveränderte Datei geändert wird, nur weil ihre Berechtigungen anders sind.