Restic: Reduzieren Sie den Speicherverbrauch mit der Befehlszeilenoption

Hey, danke für dein Interesse an restic. Die im Vortrag erwähnte Anzahl von etwa 300 MiB RAM wird (hauptsächlich) für zwei Dinge verwendet:

• scrypt(password) berechnen: Die Konstanten für scrypt sind im Moment hartcodiert, und es gibt #17 zum Hinzufügen von Code, der automatisch herausfindet, wie hart scrypt für das aktuelle System sein sollte
• mehrere Puffer von Blobs/Packs zum Sichern im Arbeitsspeicher zu haben: Dies ist eng mit der maximal zulässigen Parallelität verbunden. Dafür hätte ich auch gerne Auto-Tuning-Code, aber eine Befehlszeilenoption ist auch wahrscheinlich.

Um meine obigen Punkte zusammenzufassen: Es ist geplant und wird irgendwann umgesetzt.

Klingt gut für mich. Ich möchte dieses Problem offen halten, um diese Funktion zu verfolgen.

Einverstanden.

Mich würde dieses Thema auch aus Serversicht interessieren, also nicht unbedingt wenig Speicher aber "noch nicht genug". :) Zum Beispiel habe ich einen Mailserver mit ~950GB Daten ( scanned 64173 directories, 2147728 files in 2:41 ) und mit 2GB RAM bin ich mit restic in OOM gelaufen (unter ionice -c 3 nice -n 19 ). Gibt es bekannte Zahlen zur Berechnung des Speicherbedarfs für Restic (pro Datei/pro GB/....)? (Ich bin auf OOM mit Restic in allen möglichen verschiedenen VMs gestoßen, da ich wusste, dass diese Anforderungen im Voraus das Leben einfacher machen würden, und wenn es eine Möglichkeit gäbe, den Speicherverbrauch zu reduzieren, wäre das großartig.)

Vielen Dank!

Meine Erfahrung ist ungefähr 4 GB RAM für 1,5 TB Repo-Größe (für Backup). prune braucht noch mehr (~9-10 GB RAM).

Die Speichernutzung hängt hauptsächlich nicht von der Datengröße auf einem bestimmten Computer ab, sondern hauptsächlich von der Repository-Größe. Daher ist es unmöglich, eine 100-KB-Datei auf einem Computer mit 2 GB RAM (kein Swap) zu sichern, wenn das restliche Repository selbst ~ 1 TB groß ist.

Hier:

• Bauen:
  restic 0.8.3 (v0.8.3-11-gda77f4a2) compiled with go1.9.4 on linux/amd64
• Dimensionen (aber ich glaube tatsächlich, dass die Mehrheit dieser Dateien - viele Repository-Klone, Metadaten-Caches, Build-Verzeichnisse usw. - tatsächlich ausgeschlossen sind und die von restic gemeldeten Zahlen die Gesamtmenge widerspiegeln):
  118775 directories 829113 files 129.220 GiB
• Speichernutzung: ca. 3,8 G pro täglichem Lauf

Gibt es diesbezüglich Fortschritte? Ich liebe Restic, aber meine Backups werden aufgrund von Speichererschöpfung nicht mehr abgeschlossen (1,5 TB Repository, verwendet ~ 23 G RAM, b2-Backend). Afaik, derzeit kann die Parallelität nur geändert werden, indem die Quelle selbst geändert wird (https://github.com/restic/restic/issues/979#issuecomment-374359647), aber das ist nicht wirklich wartbar.

Hat sich etwas in Bezug auf die Anforderungen an die Speichernutzung geändert?

Ich beschäftige mich auch mit diesem Problem. 2 GB System 250 GB Restic Repo. Laufen:

ionice -c 3 nice -n 19 ~/local/bin/restic -r /mnt/restic -p rk check --read-data-subset 3/7

(auch mit 4/14, um zu versuchen, die Speichernutzung von 3/7) zu reduzieren, dauert 1,7 GB. Es kann 10 oder 12 Stunden dauern, bis der Befehl abgeschlossen ist, weil das arme System sein Gehirn austauscht. Außerdem ist das System wegen des Austauschens für alles andere so gut wie nutzlos.

Ich mag Restic, aber das ist nicht nachhaltig.

Kann jemand erklären, was der eigentliche Vorschlag in dieser Ausgabe ist? Ich meine, wenn der Speicherverbrauch/die Anforderungen verringert werden können, warum sollten wir dann nicht einfach das tun und stattdessen einen Befehlszeilenschalter verwenden, um weniger Speicher zu verwenden?

Ich gehe davon aus, dass die Zuweisung von weniger Speicherplatz, wenn möglich, dazu führen würde, dass der Prozess langsamer ist. Dies würde also rechtfertigen, dies nicht standardmäßig zu tun?

Hinsichtlich der Speicherauslastung hat es bereits Verbesserungen gegeben und einige weitere sind in Vorbereitung.
Im Prinzip schließe ich mich der Argumentation von @rawtaz an, dass die Reduzierung der Speichernutzung es ermöglicht, dass restic auf einem viel breiteren Feld von Geräten verwendet werden kann.

Trotzdem gibt es natürlich Möglichkeiten, den Speicherverbrauch weiter zu reduzieren, insbesondere gegen Geschwindigkeit. Ich habe in #2794 angefangen, an indexbezogenen Möglichkeiten zu arbeiten

Eine geeignete Lösung hierfür wird höchstwahrscheinlich einen Repository-Index auf der Festplatte verwenden oder Clients erlauben, nur Teile des Indexes zu laden, wie in #1988 beschrieben.