Ausgabe von restic version

Rest 0.8.2

Wie bist du restic genau gelaufen?

% restic -r /tmp/restictest backup $SSHFSMOUNT/directory

Das Backup-Verzeichnis ist ein mit sshfs gemountetes Dateisystem.
Der Befehl wird mehrmals ausgeführt, um mehrere Snapshots zu erstellen.
In meinem Fall befindet sich eine riesige Datenmenge (1 TB+) im Remote-Verzeichnis.

Welches Backend/Server/Dienst haben Sie zum Speichern des Repositorys verwendet?

Lokales ext4-Dateisystem.

Erwartetes Verhalten

Ich erwarte, dass das erste Backup langsam ist und viele Daten über LAN überträgt, während die nächsten Backups ziemlich schnell sein und nicht viel Bandbreite verbrauchen sollten.

Tatsächliches Verhalten

Alle Backups dauern Stunden (wenn nicht sogar Tage), selbst wenn sich keine Dateien geändert haben.

Schritte zum Reproduzieren des Verhaltens

• ein Backup ausführen
• sshfs-Dateisystem aushängen
• sshfs-Dateisystem neu mounten
• ein neues Backup ausführen

Es ist nicht 100% reproduzierbar, aber selbst mit einer kleinen Datenmenge konnte ich es reproduzieren.

Die SFTP-Serverprotokolle zeigen, dass Dateien vollständig abgerufen werden, auch wenn sie sich nicht geändert haben.

Hast du eine Idee, was das verursacht haben könnte?

Ja: restic vergleicht Inodes, um zu überprüfen, ob Dateien geändert wurden (Debugging-Meldung "Zeitstempel, Größe oder Inode geändert", restic/node.go:551restic.(*Node).IsNewer11node ).

Inodes können sich jedoch bei Dateisystem-Mounts mit sshfs (und wahrscheinlich auch bei einigen anderen Dateisystemen) ändern.

Haben Sie eine Idee, wie Sie das Problem lösen können?

Das Auskommentieren des Inode-Checks hat das Problem für mich gelöst.

Ich hätte gerne eine Möglichkeit, diese Prüfung zu deaktivieren; vielleicht ein Kommandozeilen-Flag?

Hat dir Restic in irgendeiner Weise geholfen oder glücklich gemacht?

Sicher, es ist eine schöne Software! Ich freue mich umso mehr, da ich einen Workaround gefunden habe...
Mach weiter so!