Budgets, Netzwerke und Runner

Diese Seite ist für Provider-Administratoren. Sie behandelt die drei Dinge, die eine Installation für Freigaben festlegt: wie viel Speicher sie belegen dürfen, auf welche Server ein Mandant Restow zeigen lassen darf und wie viele Runner mit wie viel Arbeitsspeicher gleichzeitig laufen. Die Einstellungen stehen unter Installation → Standard-Repository & Netzlaufwerke, im Bereich Runner für Freigaben, und im Tab Einstellungen jeder Freigabe.

Budgets

Ein Budget begrenzt, wie viel Speicher die restic-Repositories von Freigaben belegen dürfen. Budgets sind standardmäßig aus, und nur Provider-Administratoren legen sie fest. Ein Mandanten-Administrator sieht das Budget einer Freigabe und wie viel belegt ist, kann es aber nicht ändern.

Wo	Was es begrenzt
Tab Einstellungen einer Freigabe, Budget (Speicher begrenzen, Budget in GB)	Das Repository dieser Freigabe.
Runner für Freigaben, Budget je Freigabe (GB, 0 = keines)	Das Budget, das eine neue Freigabe bekommt. Bestehende Freigaben behalten ihres.
Runner für Freigaben, Budget der Freigaben eines Mandanten (GB, 0 = keines)	Alle Freigaben eines Mandanten zusammen. Der Wert gilt für jeden Mandanten.

Die Felder tragen die Einheit GB, der Wert wird in GiB (1024³ Byte) gezählt. Das Budget eines einzelnen Mandanten kann sich nur über die API vom Wert der Installation unterscheiden, im Feld tenantShareQuotaGibByTenant von PUT /api/v1/file-shares/installation-settings (die Weboberfläche hat dafür in 0.4.7 kein Feld). Hat eine Freigabe ein Budget und ihr Mandant ebenfalls eines, zählt das vollere von beiden.

Was die Größe ist: die Größe des restic-Repositorys der Freigabe. Restow zählt sie bei jedem Upload und jeder Löschung mit und misst sie bei jedem Lauf der Aufbewahrung neu.

• Bei 80 % eines Budgets warnt die Freigabe, einmal: das Ereignis Speicherbudget der Freigaben (file_share.storage_quota), in der Glocke, in Regeln und in Webhooks. Die Warnung ist wieder scharf, wenn die Belegung unter 70 % gefallen ist.
• Bei 100 % werden neue Sicherungen abgelehnt: Der Lauf scheitert sofort mit share.quota_exceeded („Das Speicherbudget für Freigabe-Sicherungen ist aufgebraucht“). Eine Sicherung, die läuft, wenn sie die Grenze überschreitet, bekommt ihre Uploads abgelehnt und endet als fehlgeschlagen mit derselben Ursache. Die Seite der Freigabe zeigt „Budget aufgebraucht: neue Sicherungen werden abgelehnt“.
• Wiederherstellungen, Kopien in die Freigabe, Aufbewahrung und die Prüfungen funktionieren weiter, Sie können also Platz schaffen, indem Sie die Aufbewahrung verkürzen (Tägliche/Wöchentliche/Monatliche Sicherungsstände des Jobs). Der Platz kommt zurück, wenn die Aufbewahrung Sicherungsstände entfernt hat und restic prune gelaufen ist. Bei einem Repository mit unveränderbaren Backups kommt er erst zurück, wenn die Sperre abgelaufen ist.

Ein Budget ist keine Quota auf dem Dateiserver: Es begrenzt, was Restow von einer Freigabe speichert, nicht, was die Freigabe enthält.

Private Netze

Der Docker-Host bindet die Freigabe aus seiner eigenen Netzposition ein. Könnte ein Mandanten-Administrator jede Adresse eintragen, könnte ein Mandant Restow einen internen Server des Providers oder eines anderen Kunden im selben Netz in die eigenen Sicherungen lesen lassen. Für Freigaben gilt daher dieselbe Regel wie für IMAP-Server, und Restow beurteilt die Adresse beim Speichern einer Freigabe und bei jedem Lauf und Test:

Adresse des Servers	Wer sie nutzen darf
Öffentlich	Alle.
Link-lokal, Multicast, reserviert, unspezifiziert (auch Cloud-Metadaten-Adressen)	Niemand.
Privat (RFC 1918, 100.64.0.0/10, Unique-Local-IPv6 und ein Name, der darauf auflöst) und Loopback	Provider-Administratoren immer: Das Speichern der Freigabe genehmigt sie, und die Genehmigung hält fest, wer, wann und welche Adresse. Mandanten-Administratoren nur, wenn ein Provider-Administrator diese Freigabe genehmigt hat oder der Schalter der Installation an ist (unten).

Ein Name wird aufgelöst und jede Adresse beurteilt; ist eine davon verboten, wird die Freigabe abgelehnt, weil der Name auf sie umgebogen werden könnte. Der Runner verbindet sich dann mit der einen Adresse, die beurteilt wurde, der Name kann sich unter ihm also nicht ändern.

• Genehmigung. Im Tab Einstellungen der Freigabe wählt ein Provider-Administrator unter Privates Netz Genehmigen oder Genehmigung zurückziehen („Genehmigt für 10.0.5.0/24 von Name, Zeit“). Eine Genehmigung gilt für die genehmigte Adresse und ihr /24 (IPv4) oder /64 (IPv6), damit eine DHCP-Erneuerung die Sicherungen nicht bricht. Löst ein Name plötzlich auf eine Adresse außerhalb dieses Bereichs auf, scheitert die Sicherung mit share.address_blocked („Die Adresse des Servers ist nicht erlaubt“), bis ein Provider-Administrator die Freigabe erneut speichert.
• Der Schalter der Installation. Mandanten dürfen Freigaben in privaten Netzen hinzufügen (unter Runner für Freigaben, standardmäßig aus) erlaubt jedem Mandanten-Administrator, Freigaben mit privaten Adressen ohne Genehmigung hinzuzufügen. Nur der Provider-Inhaber kann ihn ändern. Er passt zu einer Installation, in der eine Organisation alles in ihrem eigenen Netz betreibt. Ohne ihn sagt der Dialog einem Mandanten-Administrator, dass „ein Administrator des Anbieters diese Freigabe genehmigen muss, bevor sie gesichert werden kann.“
• Service Provider. Der Dateiserver des Kunden ist vom Restow-Host meist gar nicht erreichbar. Es braucht ein Site-to-Site-VPN, das der Provider betreibt, und dann genehmigt der Provider-Administrator die Freigabe. Link-lokale und reservierte Adressen bleiben abgelehnt, was Sie auch einstellen.

Einstellungen der Runner

Jeder Lauf (eine Sicherung, eine Wiederherstellung oder eine Kopie) läuft in einem Runner: einem kurzlebigen Container, den der Mounter startet. Runner für Freigaben zeigt, ob Läufe starten können („Bereit: 0 von 2 laufen“, „Kann keine Läufe starten“, „Netzlaufwerke sind aus“), und legt fest, wie sie dimensioniert sind. Eine Änderung gilt für Läufe, die danach starten.

Einstellung	Standard	Grenzen	Was sie tut
Gleichzeitige Läufe	2	1 bis zur Obergrenze RESTOW_MOUNTER_MAX_RUNNERS	Weitere Läufe warten, bis einer fertig ist. Wiederherstellungen gehen zuerst, dann der älteste.
Arbeitsspeicher je Runner (MiB)	2048	512 bis zur Obergrenze RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB	Das Speicherlimit des Runner-Containers. Große Freigaben mit Millionen von Dateien brauchen mehr.
Weiche Speichergrenze (%)	80	50 bis 90	Der Anteil des Arbeitsspeichers, ab dem der Runner Speicher eifriger freigibt (GOMEMLIMIT von Go).
Längster Lauf (Stunden)	72	1 bis 336	Ein Lauf, der länger dauert, wird beendet und scheitert mit share.timeout.
Parallele Lesevorgänge (Standard)	4	1 bis 16	Die Zahl paralleler Lesevorgänge von Jobs, die keine festlegen. Ein Job kann eine eigene festlegen.
Dateikatalog	an	an, aus	Hält die Namen aller gesicherten Dateien für die Suche vor. Belegt Platz in der Datenbank. Eine Freigabe mit mehr als 20 Millionen Dateien bekommt keinen Katalog.

Die Obergrenzen. Der Mounter begrenzt, was die Einstellungen verlangen können, mit zwei Variablen in der .env, die die docker-compose.yml des Releases an Mounter und Worker durchreicht:

Variable	Standard	Bedeutung
RESTOW_MOUNTER_MAX_RUNNERS	8	Harte Obergrenze gleichzeitiger Runner-Container (1 bis 64). Gleichzeitige Läufe kann sie nicht überschreiten.
RESTOW_MOUNTER_RUNNER_MAX_MEMORY_MIB	16384	Obergrenze für Arbeitsspeicher je Runner (mindestens 512).

Erstellen Sie nach einer Änderung Mounter und Worker neu. Ein Wert über der Obergrenze wird in den Einstellungen auf die Obergrenze gekürzt. Der Arbeitsspeicher aller gleichzeitigen Runner muss in den RAM des Docker-Hosts passen: Mit den Standardwerten belegen zwei Runner mit je 2048 MiB bis zu 4 GiB neben allem anderen.

Speicher und große Freigaben

restic hält den Index eines Repositorys im Arbeitsspeicher, grob proportional zur Zahl der Dateien und Blöcke, der Speicherbedarf eines Laufs wächst also mit der Zahl der Dateien der Freigabe. Ein Lauf, der sein Limit überschreitet, wird vom Kernel beendet und scheitert mit share.out_of_memory („Dem Runner ging der Speicher aus“): Erhöhen Sie Arbeitsspeicher je Runner (und die Obergrenze, falls nötig) oder geben Sie dem Job weniger Ordner.

Bei SMB nutzt ein Lauf außerdem die Berechtigungen des vorigen Laufs für jede Datei wieder, deren Änderungszeit und Größe gleich blieben, statt alle erneut vom Server zu lesen. Das hält inkrementelle Läufe großer Freigaben schnell, und es kostet Speicher: Der Code rechnet mit etwa 100 Byte je Datei (die Release Notes sagen etwa 50 Byte). Hat die vorige Berechtigungsdatei mehr Einträge, als ein Drittel der weichen Speichergrenze fasst, liest der Lauf stattdessen alle Berechtigungen neu, was langsamer ist, aber keinen zusätzlichen Speicher braucht. Mit den Standardwerten (2048 MiB, 80 %) liegt diese Grenze bei etwa 5,7 Millionen Dateien. Jeder 30. Lauf liest ohnehin alle Berechtigungen, und Alle Berechtigungen neu lesen unter Einstellungen einer Freigabe tut es bei der nächsten Sicherung.

Die Release Notes von 0.4.0 nennen RESTOW_SHARE_REUSE_MAX_ENTRIES als Möglichkeit, diese Grenze zu überschreiben. Der Runner liest sie aus seiner eigenen Umgebung, und der Mounter startet den Runner-Container mit einer festen Umgebung, die sie nicht enthält, sodass eine Zeile in der .env in 0.4.7 keine Wirkung hat. Erhöhen Sie stattdessen den Arbeitsspeicher der Runner.

Der erste Katalog einer Freigabe (und einer nach einer Lücke) wird in Stapeln von 5.000 Dateien gelesen, sodass auch der Suchindex bei großen Freigaben nicht mehr Speicher braucht.

Wie es weitergeht

• Überblick und Voraussetzungen zu Mounter, Docker-Host und Ports.
• Fehlerbehebung und Grenzen zu den Ursachen share.address_blocked, share.quota_exceeded, share.out_of_memory und share.timeout.
• Mounter und NFS-Speicher dazu, was der Mounter tun darf.