Restic: Langsam, obwohl nur Zeitstempel geprüft werden
Ich muss 164809 Dateien regelmäßig sichern (ca. 60 GB) ... Jedes Mal, wenn ich "restic backup" ausführe, geht der Bericht nicht über 33 MB / s hinaus und überprüft mit strace, dass nur lstat () -Aufrufe ausgeführt werden.
Das macht etwa 20 Minuten pro Sicherung. Ich frage mich, was restic macht, denn da fast alle Dateien unverändert sind, zeigt es die konstanten 33 MB/s und ich verstehe, dass es sie nur lstat() machen muss, was genau das ist, was restic bereits im ersten Schritt des Backups tut, nur um es zu zeigen die Gesamtgröße in 6 oder 7 Sekunden.
Ist es nur die CPU-Zeit, die für die Überprüfung des Inhalts darauf verwendet wird, dass dieselbe Datei / dieser Zeitstempel bereits in einem restic vorherigen Snapshot vorhanden ist?
viric
Alle 5 Kommentare
Im Moment werden die Metadaten für die Dateien und Verzeichnisse nicht zwischengespeichert, sondern aus dem Repository geladen (und entschlüsselt). Dies geschieht einmal pro Verzeichnis. Ich plane, Metadaten lokal zwischenzuspeichern, was noch nicht implementiert ist, aber "inkrementelle" Sicherungen erheblich beschleunigen sollte.
fd0
am 19. Feb. 2016
Hallo
Könnte dies auch zu einer schlechten Leistung bei inkrementellen Sicherungen über eine langsame WAN-Verbindung führen?
Ich habe gerade einen Ordner mit etwas über 9000 Dateien und 250 MB auf einem Remote-S3-Server gesichert. Beide Rechner sind mit einer asymmetrischen Internetverbindung von 50/5 Mbit/s down und up verbunden.
Die anfängliche Sicherung dauerte ungefähr 5 Minuten und schien ziemlich vernünftig zu sein. Aber ein zweites Backup kurz danach dauerte fast doppelt so lange! Ein Ordner mit weniger Dateien scheint viel schneller zu sein.
Kidswiss
am 13. Aug. 2016
Ja, das wird höchstwahrscheinlich der Grund sein. Für diesen speziellen Anwendungsfall gibt es eine Problemumgehung: Verwenden Sie die Option -f ( --force ) für den Befehl backup , der alle Dateien erneut lokal liest und keine Metadaten aus dem Repo lädt . Das sollte schnell gehen.
fd0
am 13. Aug. 2016
Danke sehr! Klappt wunderbar!
Kidswiss
am 13. Aug. 2016
Wir haben einen lokalen Metadaten-Cache (siehe #1040) im Master-Zweig hinzugefügt, ich denke, dieses Problem ist behoben und deshalb schließe ich ihn. Danke!
fd0
am 26. Sept. 2017
Verwandte Themen
McKael
·
4Kommentare
rakor
·
5Kommentare
mholt
·
4Kommentare
christian-vent
·
3Kommentare
dionorgua
·
5Kommentare
Hilfreichster Kommentar
Ja, das wird höchstwahrscheinlich der Grund sein. Für diesen speziellen Anwendungsfall gibt es eine Problemumgehung: Verwenden Sie die Option
-f(--force) für den Befehlbackup, der alle Dateien erneut lokal liest und keine Metadaten aus dem Repo lädt . Das sollte schnell gehen.