Fehlerbehebung und Grenzen

Beginnen Sie bei der Freigabe: Server & Clients → Freigaben, die Freigabe wählen. Ein fehlgeschlagener Test, die Übersicht und das Blatt eines fehlgeschlagenen Laufs nennen die Ursache mit dem ersten Schritt, und ein Lauf listet die Dateien mit einer Warnung auf. Die Ursachen sind die Codes unten (share. und ein Name). Bei Problemen mit dem Mounter selbst sehen Sie in sein Protokoll auf dem Docker-Host, im Installationsverzeichnis:

docker compose logs mounter

Ursachen

Verbinden

Ursache	Was sie bedeutet und was Sie tun
share.auth_failed („Der Dateiserver hat das Konto abgelehnt“)	Das Passwort ist falsch oder wurde geändert, das Konto ist gesperrt, abgelaufen oder hat keinen Zugriff auf diese Freigabe. Es wurde nichts gelesen. Tragen Sie das neue Passwort unter Einstellungen der Freigabe ein (die Freigabe muss nicht neu hinzugefügt werden) und prüfen Sie, dass das Konto nicht gesperrt ist. Die Freigabe zeigt „Das Passwort wurde abgelehnt“, bis ein Test oder ein Lauf gelingt.
share.unreachable („Der Dateiserver antwortet nicht“)	Der Docker-Host bekommt keine Antwort: Prüfen Sie die Adresse, die Firewall (445 für SMB, 2049 für NFS), das VPN bei einem entfernten Standort und das Routing vom Host aus, nicht von Ihrem PC.
share.not_found („Freigabe, Export oder Ordner gibt es nicht“)	Der Freigabename, der NFS-Export oder der Unterordner ist falsch oder wurde entfernt. Bei NFS listet showmount -e <Server> auf, was der Server exportiert.
share.version_mismatch („Der Server spricht die gewählte Protokollversion nicht“)	Wählen Sie unter Einstellungen eine andere Version (bei SMB ist 3.0 die verträglichste) oder schalten Sie Verbindung verschlüsseln aus. Bei NFS probieren Sie eine andere Version.
share.permission_denied („Das Konto darf diesen Ordner nicht lesen“)	Die Freigabe wurde eingebunden, aber das Konto darf den Ordner nicht auflisten. Geben Sie ihm Leserechte, am besten über die Sicherungs-Operatoren.
share.client_missing („Dem Docker-Host fehlt der SMB- oder NFS-Client“)	Laden Sie den Kernel-Client auf dem Docker-Host: modprobe cifs (bei Ubuntu-Cloud-Kerneln zuerst linux-modules-extra-$(uname -r) installieren) oder installieren Sie nfs-common oder nfs-utils. Siehe Überblick und Voraussetzungen.
share.mount_failed („Die Freigabe konnte nicht eingebunden werden“)	Das Einbinden ist aus einem Grund fehlgeschlagen, den Restow nicht kennt. Die technischen Details zeigen, was das System gemeldet hat (das Passwort ist daraus entfernt).
share.address_blocked („Die Adresse des Servers ist nicht erlaubt“)	Eine private, Loopback- oder reservierte Adresse, die kein Provider-Administrator für diese Freigabe genehmigt hat, oder eine Adresse außerhalb des genehmigten Bereichs. Genehmigen Sie die Freigabe oder schalten Sie Mandanten dürfen Freigaben in privaten Netzen hinzufügen ein, siehe Budgets, Netzwerke und Runner.
share.wrong_filesystem („Die Freigabe war nicht wie erwartet eingebunden“)	Der Runner hat die Freigabe nicht dort eingebunden gefunden, wo er sie erwartet, und nichts gelesen. Das sollte nicht vorkommen: Eröffnen Sie einen Supportfall.

Sichern

Ursache	Was sie bedeutet und was Sie tun
share.empty_source („Die Freigabe ist leer“)	Die Freigabe oder die Ordner des Jobs sind leer, obwohl der letzte Sicherungsstand Dateien hatte. Es wurde nichts gesichert und nichts entfernt. Prüfen Sie die Freigabe und wählen Sie Die leere Freigabe einmal sichern, wenn sie leer sein soll, siehe Eine leere Freigabe.
share.include_missing („Ein einbezogener Ordner existiert nicht mehr“)	Ein Ordner des Jobs ist weg. Korrigieren Sie die Ordner des Jobs.
share.quota_exceeded („Das Speicherbudget für Freigabe-Sicherungen ist aufgebraucht“)	Erhöhen Sie das Budget oder verkürzen Sie die Aufbewahrung, siehe Budgets.
share.out_of_memory („Dem Runner ging der Speicher aus“)	Erhöhen Sie Arbeitsspeicher je Runner unter Runner für Freigaben, siehe Einstellungen der Runner.
share.timeout („Der Lauf dauerte zu lange“)	Der Lauf wurde nicht innerhalb von Längster Lauf (Stunden) fertig und wurde beendet. Erhöhen Sie den Wert unter Runner für Freigaben oder sichern Sie die Freigabe in kleineren Teilen.

Warnungen

Ein Lauf, der Mit Warnungen endet, hat einen Sicherungsstand von dem gemacht, was er lesen konnte. Die Dateien stehen im Lauf.

Ursache	Was sie bedeutet und was Sie tun
share.locked_files („Einige Dateien waren auf dem Server geöffnet“)	Die Dateien waren mit einer Sperre geöffnet und ließen sich nicht lesen. Der Rest ist vollständig. Sichern Sie nachts. Über SMB gibt es kein VSS.
share.read_errors („Einige Dateien konnten nicht gelesen werden“)	Sonstige Lesefehler pro Datei. Der Rest ist vollständig.
share.files_dropped („Viel weniger Dateien als beim letzten Mal“)	Die Freigabe enthält weniger als die Hälfte der Dateien des vorigen Sicherungsstands. Gesichert wurde, was vorhanden war. Prüfen Sie, ob die Dateien absichtlich gelöscht wurden, bevor die Aufbewahrung die älteren Sicherungsstände entfernt.
share.acl_partial („Berechtigungen wurden nicht für jede Datei gesichert oder wiederhergestellt“)	Dem Konto fehlt das Recht, die Berechtigungen einiger Dateien zu lesen oder zu schreiben. Nutzen Sie die Sicherungs-Operatoren und SeSecurityPrivilege für Überwachungseinträge.
share.offline_skipped („Offline-Dateien wurden übersprungen“)	Dateien, die nur als Platzhalter existieren (in die Cloud oder ein Archiv ausgelagert), wurden wie im Job eingestellt übersprungen. Schalten Sie Offline-Dateien zurückholen ein, um sie zu sichern.

Bestätigen Sie eine Warnung auf der Seite Warnungen, wenn sie erwartet ist. Ein Fehler danach hebt die Bestätigung auf.

Wiederherstellen und Kopieren

Ursache	Was sie bedeutet und was Sie tun
share.restore_not_allowed („Die Ziel-Freigabe erlaubt keine Wiederherstellung“)	Schalten Sie in den Einstellungen des Ziels Wiederherstellung in diese Freigabe erlauben ein oder wählen Sie ein anderes Ziel.
share.restore_partial („Einige Dateien konnten nicht geschrieben werden“)	Ein Name, den das Ziel nicht aufnehmen kann, fehlende Rechte oder kein Platz. Der Lauf endet Mit Warnungen und listet die Dateien.
share.copy_no_verified_point („Noch kein geprüfter Sicherungsstand zum Kopieren“)	Warten Sie auf die Restore-Prüfung des neuesten Sicherungsstands der Quelle oder starten Sie sie bei der Quell-Freigabe.
share.copy_unsafe_target („Das Kopierziel ist nicht sicher“)	Das Ziel verletzt eine Sicherheitsregel: derselbe Ort, das Stammverzeichnis einer Freigabe bei einer Spiegelung, ein Ordner eines anderen Kopierjobs oder ein nicht leerer Ordner, den niemand bestätigt hat. Prüfen Sie den Kopierjob.
share.copy_empty_source („Spiegelkopie abgelehnt: Die Quelle wirkt geleert“)	Der Sicherungsstand ist leer oder hat weniger als die Hälfte der Dateien der letzten Kopie. Prüfen Sie die Quelle. Trotzdem kopieren kopiert den kleineren Stand einmal; ein leerer Sicherungsstand wird nie gespiegelt.

Siehe Kopierjobs.

Mounter und Runner

Ursache	Was sie bedeutet und was Sie tun
share.mounter_unavailable („Der Mounter läuft nicht“)	Der Mounter ist aus, startet neu oder kann gerade keine Runner starten (Netzwerk, Image oder Limit). Geplante Läufe warten. Installation → Standard-Repository & Netzlaufwerke zeigt den Grund und docker compose logs mounter die Einzelheiten.
share.runner_failed („Der Runner endete ohne Ergebnis“)	Der Runner hat aufgehört, bevor er meldete, wie der Lauf ausging (mit seinem Exit-Code). Sehen Sie in das Protokoll des Laufs und des Mounters.
share.runner_lost („Der Runner ist verschwunden“)	Der Mounter kennt den Runner dieses Laufs nicht mehr, zum Beispiel weil der Mounter beendet oder neu gestartet wurde, während der Lauf ging.
share.runner_stalled („Der Runner meldet sich nicht mehr“)	Der Runner hat lange (30 Minuten) keinen Fortschritt gemeldet und wurde beendet.

Läuft der Mounter, aber Läufe für Freigaben können nicht starten, nennt die Seite das Hindernis. runner_network_missing heißt: Die docker-compose.yml ist älter als 0.4.0 und hat kein Netz runners; führen Sie das install.sh von 0.4.0 oder neuer erneut aus, siehe Erneut ausführen. runner_image_unknown heißt: Der Mounter fand keinen Container api des Compose-Projekts, dem er das Runner-Image entnehmen kann. Runner nutzen immer das Image der laufenden API, damit sie dieselbe Version sprechen.

Das Repository

Ursache	Was sie bedeutet und was Sie tun
share.repository_locked („Das restic-Repository der Freigabe blieb gesperrt“)	Ein anderer Lauf oder die Wartung des Servers hielt das Repository gesperrt. Restow versucht es erneut. Sperren beendeter Läufe räumen die Aufbewahrung und die wöchentliche Prüfung auf. Ein Repository, das länger als zwölf Stunden gesperrt bleibt, löst Sicherungsdaten einer Freigabe bleiben gesperrt aus.
share.repository_damaged („Das restic-Repository der Freigabe meldet einen Schaden“)	restic meldet das Repository als beschädigt oder kann es nicht öffnen. Die Freigabe ist Nicht wiederherstellbar. Öffnen Sie das Repository mit seinem Passwort (Passwort anzeigen), führen Sie restic check von Hand aus und holen Sie sich mit der Ausgabe Hilfe.

SELinux

Auf einem Host mit SELinux im Enforcing-Modus kann ein Container einen cifs- oder nfs-Mount nur mit einer Option context= lesen. Das Anzeichen ist ein Test, der einbindet und dann „Permission denied“ meldet. Setzen Sie RESTOW_MOUNTER_SELINUX_CONTEXT=true in der Umgebung des Dienstes mounter und erstellen Sie ihn neu, siehe den Docker-Host. Die Release Notes führen SELinux im Enforcing-Modus als ungetestet auf.

Bekannte Grenzen

Das sind die Grenzen der Sicherung von Freigaben in 0.4.7.

• Kein VSS über SMB. Restow liest die Dateien nacheinander, während Menschen arbeiten. Eine Datei, die exklusiv gesperrt geöffnet ist, wird übersprungen (Von einem anderen Programm gesperrt), und es gibt keinen konsistenten Zustand über Dateien hinweg. Sichern Sie nachts. Für Datenbanken und Mail-Dateien (zum Beispiel PST) nutzen Sie den Endpunkt-Agenten mit VSS auf dem Server.
• Keine alternativen Datenströme. Der Linux-SMB-Client zeigt sie nicht (die Markierung Zone.Identifier, Office-Metadaten, die Resource Forks von macOS). Sie werden nicht gesichert und nicht wiederhergestellt.
• Keine DFS-Namespaces, kein Kerberos, kein SMB 1. DFS-Verweise sind ausgeschaltet, damit der Kernel sich nie mit einem Server verbindet, den Restow nicht beurteilt hat: Fügen Sie die Zielfreigaben eines Namespace direkt hinzu. Die Anmeldung ist NTLMv2, und NFS meldet sich über den Host an.
• Berechtigungen. Zugriffszeiten bleiben nicht erhalten. Besitzer und Modus, die der Linux-SMB-Client zeigt, sind synthetisch und werden nicht wiederhergestellt; die NTFS-Berechtigungen stammen aus den gesicherten Berechtigungen. Die Berechtigungen einer einzelnen Datei werden nur zusammen mit der Datei wiederhergestellt.
• Repositories liegen nur im primären Repository. Restow spiegelt sie nicht in ein Kopie-Repository, wie bei den restic-Repositories von Rechnern und Proxmox-VE-Containern. Sichern Sie das primäre Repository, siehe Restow selbst sichern. Seit 0.4.2 kopiert ein Speicher-Verschieben sie auf das neue primäre Repository, geprüft nach Größe und SHA-256 (vor 0.4.2 tat es das nicht), und Vorhandene Backups dort belassen, wo sie sind wird abgelehnt, solange Freigaben Repositories haben, siehe Das primäre Repository ersetzen.
• Ein fehlendes Repository wird noch nicht geheilt. Fehlt das Repository einer Freigabe nach einem Speicherwechsel auf dem primären, können die Sicherungen der Freigabe fehlschlagen, typischerweise mit der Meldung von restic, dass das Repository nicht existiert: Restow beginnt für sie keine neue Sicherungskette, wie es das bei einem Container tut (Neue Sicherungskette). Das ist ein bekanntes Problem in 0.4.2, und es zu heilen ist geplant. Um es zu vermeiden, wechseln Sie das primäre Repository mit einem Speicher-Verschieben, das das Repository mitnimmt, und nicht mit „Belassen“, das abgelehnt wird, solange Freigaben Repositories haben.
• Ein Mounter je Installation, Runner nur auf dem Docker-Host. Es gibt keinen Runner in der Nähe des Dateiservers: Ein Dateiserver, den nur eine langsame Leitung erreicht, wird über diese Leitung gesichert.
• Ein Kopierjob behält keine Versionen. Siehe Kopierjobs.
• Nutzer eines Mandanten haben keine Selbstbedienungs-Wiederherstellung von Freigaben. Nur Administratoren stellen wieder her, siehe Wiederherstellen und Restore-Prüfung.
• Geplante Berichte haben keinen eigenen Block für Freigaben. Die Zahlen, die ein Bericht nennt (Erfolgsquote der Sicherungen, als wiederherstellbar nachgewiesener Anteil), schließen sie ein.
• Unveränderbare Backups. Eine Freigabe, deren Repository noch gesperrt ist, lässt sich nicht löschen, bevor die Sperre abgelaufen ist, siehe Unveränderbare Backups.
• Speicherzahlen. Seit 0.4.1 schließt Gespeichert (Repositories → Belegung, die Kachel des Dashboards, die Statistik und physicalBytes der API) die restic-Repositories von Freigaben ein. Die Größe eines Repositorys hat keinen Verlauf, Wachstum und Deduplizierungs-Ersparnis bleiben also Zahlen des Chunk-Speichers, und Geschützte Daten zählt nicht die logische Größe von restic-Sicherungen.
• arm64-Hosts werden unterstützt, soweit das Image es ist. Der Kernel braucht das Modul cifs.

Was getestet wurde

Die bekannten Probleme von 0.4.0 sagen es, und sie gelten in 0.4.7 weiter. Seit 0.4.2 sagen die bekannten Probleme außerdem, dass die neuen Teile nur gegen einen simulierten S3-Speicher getestet wurden, nie gegen einen echten S3-Anbieter, und dass das fehlende Repository einer Freigabe noch nicht geheilt wird (siehe oben):

• Freigaben wurden im Release-Smoke-Lauf gegen Samba getestet (sichern, durchsuchen, suchen, ZIP herunterladen, mit Berechtigungen wiederherstellen und ein Kopierjob) und in den Testsuites gegen simulierte Dienste. Sie wurden nicht gegen Windows Server (NTFS-Berechtigungen, Sicherungs-Operatoren, eine in Excel geöffnete Datei), eine Synology- oder TrueNAS-Freigabe, echte NFS-Exporte (NFS ist nicht Teil des Smoke-Laufs) oder einen Host mit SELinux im Enforcing-Modus getestet.
• Netzlaufwerke einschalten und das Verschieben der Datenbank wurden nicht über einen echten Updater und seinen Docker-Hilfscontainer getestet.
• Die neuen Seiten waren durch Komponententests abgedeckt, vor dem Tag aber nicht von Hand in einem Browser ausprobiert.

Beginnen Sie mit einer Testfreigabe, stellen Sie daraus wieder her, und behalten Sie Ihre bisherige Sicherung des Dateiservers, bis Sie selbst aus Restow wiederhergestellt haben.