Fehlerbehebung beim Endpoint-Backup

Beginnen Sie mit dem Rechner in Restow, unter Server & Clients → Inventar. Seine Übersicht zeigt, warum er Aufmerksamkeit braucht (zum Beispiel Meldet sich nicht, Sicherung überfällig, Letzte Sicherung fehlgeschlagen, Restore-Prüfung fehlgeschlagen, Sicherungsdaten beschädigt, Noch nie verbunden). Öffnen Sie unter Läufe einen Lauf, um sein Ergebnis, seine Fehler und das Ende seines Protokolls zu lesen. Jeder fehlgeschlagene Lauf trägt eine Erklärung mit Schritten, siehe Fehlererklärungen.

Auf dem Rechner zeigt restow-agent status den lokalen Zustand und braucht keine Root-Rechte. sudo restow-agent status zeigt zusätzlich die Hook-Regel. Wird restow-agent nicht gefunden, nutzen Sie den vollen Pfad: /opt/restow-agent/bin/restow-agent unter Linux, '/Library/Application Support/Restow/bin/restow-agent' unter macOS.

Die Meldungen der Installationsskripte und des Agents sind englisch und hier im Wortlaut genannt.

Installation und Enrollment

Symptom	Ursache und Abhilfe
„this installer must run as root“	Führen Sie den Befehl mit `sudo` aus, wie in Restow gezeigt.
„this Linux system does not run systemd“	Der Installer und die `service`-Befehle unterstützen nur systemd. Sie können `restow-agent run` weiterhin unter einem anderen Supervisor betreiben.
„curl is required“ oder „unsupported CPU architecture“	Installieren Sie `curl`. Unterstützt sind x86_64 und aarch64 unter Linux sowie Intel und Apple Silicon unter macOS.
„the instance URL must start with https://“	Setzen Sie in den Restow-Einstellungen eine öffentliche URL mit `https://` und erstellen Sie einen neuen Befehl. Die Skripte weisen reines `http://` ab.
„cannot download … SHA256SUMS“	Der Rechner erreicht Ihre Instanz nicht per HTTPS, oder die Instanz stellt diese Agent-Version nicht bereit. Prüfen Sie DNS, Firewall und Proxy, siehe unten.
„checksum mismatch … Nothing was installed.“	Ein Download war beschädigt oder abgeschnitten, oder etwas auf dem Weg hat ihn verändert. Führen Sie den Befehl erneut aus. Passiert es immer wieder, prüfen Sie, was zwischen Rechner und Instanz sitzt. Es wurde nichts installiert, Sie können also gefahrlos erneut versuchen.
„the release signature does not match … The files may have been changed. Nothing was installed.“	`SHA256SUMS` ist nicht mit dem Release-Schlüssel signiert, den das Skript mitbringt. Etwas auf dem Weg oder auf Ihrer Instanz hat die Dateien verändert. Umgehen Sie das nicht: Prüfen Sie Ihre Instanz und was zwischen ihr und dem Rechner sitzt. Es wurde nichts installiert.
„agent … on this instance is not signed (no SHA256SUMS.sig). Nothing was installed.“	Die Instanz bietet für diese Agent-Version keine Signatur an. Installiert werden nur signierte Releases. Prüfen Sie, dass Ihre Instanz ein Release-Image nutzt.
„this system can check the release signature neither with ssh-keygen (OpenSSH 8.1 or newer) nor with OpenSSL 3“	Typisch für RHEL, Rocky Linux und AlmaLinux 8 sowie Amazon Linux 2. Installieren Sie eines der beiden Werkzeuge, oder prüfen Sie die Signatur auf einem anderen Rechner und übergeben Sie `RESTOW_SHA256SUMS_SHA256`. Siehe Systeme ohne Signaturwerkzeug.
„SHA256SUMS hashes to …, not to the value in RESTOW_SHA256SUMS_SHA256“	Die `SHA256SUMS`, die Ihre Instanz ausliefert, ist nicht die, die Sie geprüft haben. Laden und prüfen Sie sie für die Agent-Version, die Ihre Instanz anbietet, erneut. Es wurde nichts installiert.
„… is not owned by root or is writable by group or others“ oder „… is a symbolic link; the install folder must be a real folder owned by root“	Der Agent läuft als root und wird nur dort installiert, wo kein anderer Benutzer etwas ändern kann. Korrigieren Sie den genannten Ordner (Eigentümer root, kein Schreibrecht für Gruppe und andere) oder entfernen Sie ihn, wenn Sie ihn nicht angelegt haben, und führen Sie den Befehl erneut aus.
„this machine is not enrolled and no enrollment token was given“	Die erste Installation braucht das Token. Führen Sie den Befehl in einem Terminal aus und fügen Sie das Token ein, wenn das Skript danach fragt, oder nutzen Sie `RESTOW_TOKEN_FILE` für eine unbeaufsichtigte Installation.
„RESTOW_TOKEN_FILE … does not exist“ oder die Warnung „… can be read by other users“	Prüfen Sie den Pfad der Token-Datei. Halten Sie sie bei Modus 0600 mit Eigentümer root und löschen Sie sie nach der Installation.
„The agent is installed but not enrolled“ oder ein Fehler zu abgelaufenem oder bereits verwendetem Token	Das Token ist 24 Stunden gültig und funktioniert einmal. Erstellen Sie in Restow einen neuen Installationsbefehl und führen Sie ihn erneut aus.
Der Endpoint bleibt auf „Noch nie verbunden“	Der Befehl ist nicht gelaufen, oder der Rechner erreicht die Adresse darin nicht. Ist keine öffentliche URL gesetzt, stammt die Adresse aus Ihrem Browser und ist vom Rechner aus vielleicht nicht erreichbar. Setzen Sie die öffentliche URL in den Einstellungen.

Verbindung

Symptom	Ursache und Abhilfe
Der Agent meldet ein nicht vertrauenswürdiges Zertifikat	Der Agent nutzt den Zertifikatsspeicher des Betriebssystems. Nehmen Sie Ihre private CA dort auf, oder verweisen Sie unter Linux in der Umgebung des Dienstes mit `SSL_CERT_FILE` auf eine PEM-Datei. Siehe Proxy und private CA.
DNS- oder Firewall-Fehler	Der Rechner muss Ihre Instanz auflösen und per HTTPS erreichen. Nötig sind nur ausgehende Verbindungen.
Der Rechner sitzt hinter einem Proxy	Setzen Sie `HTTPS_PROXY` und `NO_PROXY` in der Umgebung des Dienstes, zum Beispiel mit `systemctl edit restow-agent`.
Zertifikatsfehler auf einem Rechner mit falschem Datum	Die Uhr muss stimmen. Korrigieren Sie die Zeit und starten Sie den Dienst neu.
„Gesperrt“ in Restow, oder der Agent meldet einen gesperrten Endpoint	Ein gesperrter Endpoint wird abgewiesen und nimmt keine Backups oder Aufgaben an. Um den Rechner wieder zu sichern, erstellen Sie einen neuen Installationsbefehl und melden den Rechner erneut an, siehe Deinstallation.
Ein Server ist als „Meldet sich nicht“ markiert	Kein Kontakt seit länger als der Alarmgrenze (standardmäßig 2 Stunden). Der Rechner ist vielleicht aus oder offline, oder sein Agent wurde beendet. Prüfen Sie `restow-agent service status` auf dem Rechner, unter Linux auch `systemctl status restow-agent`.
Das Agent-Log sagt „the agent does nothing (no backups, no tasks, no hooks) until its installation is safe“, oder `restow-agent status` sagt „the installation is not safe“	Der Agent hat seine Binärdatei, restic oder einen Ordner darüber vorgefunden, der einem anderen Benutzer gehört oder für andere schreibbar ist. Bis das behoben ist, führt er kein Backup, keine Aufgabe und keinen Hook aus und versucht es alle 5 Minuten erneut. Führen Sie den Installationsbefehl aus Restow erneut aus: Er repariert die Installation.

Backup-Läufe

Symptom	Ursache und Abhilfe
Ein Lauf endet unter macOS Mit Warnungen	Der Vollzugriff auf die Festplatte fehlt. Fügen Sie `/Library/Application Support/Restow/bin/restow-agent` und bei Bedarf `/Library/Application Support/Restow/bin/restic` hinzu. Siehe Installation.
„Der Befehl vor oder nach der Sicherung wurde nicht ausgeführt: Der Rechner lässt Hooks aus Restow nicht zu“ (`hooks_not_allowed`)	In Restow ist ein Hook eingestellt, aber die Hook-Regel des Rechners lässt ihn nicht zu. Das Backup lief ohne ihn und ist teilweise. Erlauben Sie Hooks auf dem Rechner (`sudo restow-agent hooks scripts` oder `sudo restow-agent hooks any`), legen Sie auf einem `scripts`-Rechner das genannte Skript in `/etc/restow-agent/hooks.d` ab, oder entfernen Sie den Hook in den Einstellungen (Befehle entfernen).
Eine Sicherung schlägt mit „Der Server hat die Anfrage abgelehnt“ fehl, und die Karte Sicherungsdaten sagt, das Speicherbudget sei ausgeschöpft	Das Repository hat sein Speicherbudget oder das des Mandanten erreicht (`endpoint-quota-exceeded`). Erhöhen Sie Speicherbudget in den Einstellungen des Rechners oder das Budget der Installation (`RESTOW_ENDPOINT_QUOTA_GIB`, `RESTOW_ENDPOINT_TENANT_QUOTA_GIB`), bewahren Sie weniger Snapshots auf oder sichern Sie weniger. Wiederherstellungen funktionieren weiter. Siehe Speicherbudget.
Ein Lauf endet anderswo Mit Warnungen	Einige Dateien ließen sich nicht lesen, zum Beispiel weil sie geöffnet, gesperrt oder nicht lesbar waren, oder der Befehl nach dem Backup ist fehlgeschlagen. Der Lauf listet die Dateien und den Fehler.
„Keiner der eingestellten Ordner existiert auf dem Rechner“ (`no_paths`)	Prüfen Sie die Ordner unter Einstellungen. Ordner, die nicht existieren, werden übersprungen, aber wenn keiner existiert, schlägt der Lauf fehl.
„Der Befehl vor der Sicherung ist fehlgeschlagen, daher lief die Sicherung nicht“ (`pre_hook_failed`)	Ein fehlschlagender Befehl vor dem Backup stoppt das Backup mit Absicht. Lesen Sie die Hook-Ausgabe im Lauf-Protokoll und testen Sie den Befehl auf dem Rechner als root.
„Der Befehl nach der Sicherung ist fehlgeschlagen“ (`post_hook_failed`)	Das Backup ist gespeichert, aber der Lauf zählt als teilweise. Lesen Sie die Hook-Ausgabe im Lauf-Protokoll.
„Der Lauf hat zu lange gedauert und wurde abgebrochen“ (`timeout`)	Ein Backup ist auf 72 Stunden begrenzt. Ein Befehl vor dem Backup auf 60 Minuten und einer danach auf 30. Eine sehr niedrige Upload-Begrenzung kann dazu führen, dass ein großes erstes Backup das überschreitet.
„Unterbrochen, setzt sich automatisch fort“ (`interrupted`)	Der Agent wurde während des Laufs neu gestartet. Er setzt sich von selbst fort und löst keinen Alarm aus. Nichts zu tun.
Abgebrochen, „In der Oberfläche abgebrochen“ (`cancelled`)	Jemand hat Sicherung stoppen gewählt (der Lauf sagt „Abgebrochen von“ und den Namen). Das ist kein Fehler: kein Alarm, kein Webhook `job.failed`, und die letzte Sicherung bleibt, wie sie war. Der Agent setzt ihn nicht fort. Siehe Eine Sicherung stoppen.
Sicherung stoppen sagt „Wird abgebrochen…“, und die Sicherung läuft weiter	Der Agent bekommt die Anforderung mit seinem nächsten Heartbeat, während einer Sicherung innerhalb etwa einer Minute. Ein Agent vor 0.4.2 kennt die Anforderung nicht und führt die Sicherung zu Ende. Ein Rechner, der offline ist, hört sie erst, wenn er zurück ist. Aktualisieren Sie den Agent (`sudo restow-agent update`).
`sudo restow-agent update` sagt „A backup is running; the update waits“	Der Befehl lehnt ab, solange auf dem Rechner eine Sicherung, eine Wiederherstellung oder ein Restore-Test läuft (Exit-Code 1). Der Agent installiert das Update von selbst, sobald er frei ist. Führen Sie den Befehl danach erneut aus, wenn Sie nicht warten möchten.
`restic_exit_<N>`	Der Exit-Code von restic entscheidet über die Erklärung: 10 heißt, das Repository fehlt, 11, dass es gesperrt ist, 12, dass das Repository-Passwort falsch ist, 3, dass einige Dateien nicht lesbar waren. Andere Codes werden am Fehlertext gedeutet, zum Beispiel Netzwerk oder abgelehnt.
Das Repository ist gesperrt	Ein Backup oder eine Wartung nutzt es gerade. Warten Sie und versuchen Sie es erneut. Vor der Aufbewahrung und der Repository-Prüfung entfernt der Server Lock-Dateien, die der Speicher vor mehr als 30 Minuten erhalten hat.
Ein Laptop sichert nicht	Prüfen Sie „Nur am Netzstrom sichern“, dass der Laptop wach und online ist und dass das letzte Backup älter ist als der Abstand (bei einem Client standardmäßig 4 Stunden). Ein mit Jetzt sichern gestartetes Backup wird nicht durch den Akkubetrieb zurückgehalten. Schauen Sie auch auf Nächste Sicherung auf der Seite des Rechners: Sie sagt, wenn eine fällige Sicherung auf das Netzteil, ein Sicherungsfenster oder ein Update wartet.
Eine fällige Sicherung beginnt nicht, und die Seite des Rechners sagt „Fällig, wartet auf das Sicherungsfenster“	Eine Richtlinie der Agenten begrenzt die Stunden, in denen geplante Sicherungen beginnen dürfen. Die Seite nennt die Zeit, zu der sich das Fenster öffnet. Ändern Sie das Fenster in der Richtlinie der Installation, des Mandanten oder des Jobs, oder starten Sie die Sicherung mit Jetzt sichern, das das Fenster nicht beachtet.
Eine Sicherung, die verpasst wurde, während der Rechner aus war, wird nicht nachgeholt	Die Richtlinie sagt es so: Nachholen ist aus, die verpasste Sicherung ist älter als das Höchstalter, oder sie wartet auf das nächste Sicherungsfenster („Eine verpasste Sicherung wird nicht nachgeholt (Richtlinie)“ oder „… wird im nächsten Sicherungsfenster nachgeholt“). Siehe Verpasste Sicherungen nachholen. Eine Sicherung, die bei eingeschaltetem Rechner gewartet hat, ist nie verpasst.
Die Seite des Rechners sagt „Fällig, wartet: Restow wird aktualisiert und startet keine neuen Sicherungen“	Ein Restow-Update pausiert neue Läufe. Der Agent beginnt nichts und wartet, was weder als verpasst noch als fehlgeschlagen zählt. Die Sicherungen folgen, wenn das Update vorbei ist. Siehe Die Update-Pause.
Eine Sicherung, die ein Rechner selbst begonnen hat, ist fehlgeschlagen, während Restow aktualisiert wurde	Agents älter als 0.4.0 halten ihre eigenen Zeitpläne während einer Update-Pause nicht an, eine dann begonnene Sicherung läuft also und kann fehlschlagen, wenn die API neu startet. Sie wird von selbst wiederholt. Aktualisieren Sie den Agent auf 0.4.0 oder neuer.
Jetzt sichern bewirkt nichts	Der Rechner holt die Anfrage bei seinem nächsten Kontakt ab, meist innerhalb weniger Minuten. Pausiert gerade ein Restow-Update neue Läufe, bleibt die Anfrage auf dem Server in der Warteschlange, bis die Pause vorbei ist. Eine Anfrage, die nicht innerhalb von 7 Tagen abgeholt wird, läuft ab und wird als fehlgeschlagen markiert. Ein Rechner in keinem Backup-Job nimmt keine Anfrage an: Fügen Sie ihn zuerst einem Job hinzu. Ein Restore-Operator kann keine anfordern (HTTP 403).
Die Seite eines Rechners zeigt keinen Grund, warum eine fällige Sicherung wartet	Der Grund kommt mit dem Heartbeat des Agents 0.4.0. Ein älterer Agent sendet ihn nicht.
Der Job-Editor oder die Seite des Rechners sagt „Ordner mit Daten auf diesem Rechner werden nicht gesichert“	Der Agent 0.4.0 hat gängige Datenordner gefunden, etwa `/opt` oder Docker-Volumes, die der Job nicht sichert. Fügen Sie sie mit Diesen Ordner zum Job hinzufügen hinzu, oder lassen Sie sie bewusst weg. Siehe Datenordner, die ein Job auslässt. Bei einem älteren Agent bleibt der Hinweis von 0.3.5.
Die Platte ist voll	Der restic-Cache in `/var/lib/restow-agent/cache` kann bei großen Repositorys auf einige GB wachsen und darf gelöscht werden. Temporäre Restore-Kopien liegen unterhalb von `/var/lib/restow-agent`. Prüfen Sie auch, wohin Ihre Hooks Dumps schreiben.

Restore und Restore-Tests

Symptom	Ursache und Abhilfe
Ein Restore schlägt mit `target_not_empty` fehl	Der Zielordner existiert und ist nicht leer, oder er ist kein Ordner. Es wurde nichts angerührt. Lassen Sie das Ziel leer, um einen neuen Ordner mit Datum und Uhrzeit zu erhalten, oder wählen Sie einen Ordner, der nicht existiert.
Ein Restore schlägt mit `target_unusable` fehl	Der übergeordnete Ordner des Ziels existiert nicht, oder ein Ordner über dem Ziel lässt sich von einem anderen Benutzer als root ändern, etwa im Home-Ordner eines Benutzers. Wählen Sie ein Ziel unterhalb von Ordnern, die nur root ändern kann, etwa `/srv/restore`, oder lassen Sie das Ziel leer. Siehe Restore.
Ein Restore schlägt mit `invalid_task` fehl	Das Ziel ist kein schlichter absoluter Pfad (es enthält `..`, `.`, einen doppelten oder einen abschließenden Schrägstrich), oder die Anfrage war ungültig. Geben Sie einen schlichten absoluten Pfad an.
Ein Restore startet nicht	Der Rechner ist aus oder offline. Die Anfrage wartet und startet, sobald er sich meldet.
Die Oberfläche sagt, die Sicherungsdaten seien beschäftigt	„Die Sicherungsdaten sind gerade mit einer Sicherung oder Wartung beschäftigt“ (`endpoint-repository-locked`): Der Server führt gerade die Aufbewahrung oder eine Repository-Prüfung darauf aus. „Der Server liest gerade andere Sicherungen“ (`restic-busy`): Zu viele Lesevorgänge laufen gleichzeitig. Versuchen Sie es in einer Minute erneut.
Die Sicherungsdaten ließen sich im Repository nicht öffnen	Prüfen Sie, ob das Repository (das Speicherziel) erreichbar ist.
Ein Restore-Operator sieht kein Inventar und keine Seite des Rechners	Das ist gewollt. Restore-Operatoren arbeiten in Datei-Restore: Sie durchsuchen, laden und stellen Dateien wieder her, und die Weboberfläche lässt die Seiten weg, die sie nicht öffnen dürfen. Siehe Restore.
Ein gesperrter Rechner fehlt im Inventar	Gesperrte Rechner sind seit 0.4.0 ausgeblendet. Wählen Sie Gesperrte Rechner anzeigen, oder öffnen Sie Datei-Restore, wo sie in der Gruppe Gesperrte Rechner stehen.
Ein Rechner, der aus Restow entfernt wurde, fehlt	Ein entfernter Rechner steht in keiner Liste. Sind seine Sicherungen noch gespeichert, führt das Inventar ihn unter den Rechnern als Sicherungen von N entfernten Rechnern mit Dateien wiederherstellen auf (seit 0.4.6); sind sie gelöscht, ist er weg, und seine Sicherungen auch.
Rechner entfernen wird abgelehnt	„Nur ein gesperrter Rechner lässt sich entfernen. Sperren Sie ihn zuerst.“ (`endpoint-not-revoked`). „Rechner und Sicherungen löschen“ wird außerdem abgelehnt, solange eine Legal Hold über den Mandanten oder ein ungeklärter verdächtiger Sicherungsstand die Sicherungen hält (`endpoint-removal-legal-hold`, `endpoint-removal-suspicion-hold`): Heben Sie die Hold auf, klären Sie den Befund oder behalten Sie die Sicherungen bis zum Ablauf. Diese Wahl wird abgelehnt, wenn die Aufbewahrung des Rechners alles behält (`endpoint-removal-never-expires`). Siehe Deinstallation.
Die Sicherungen eines entfernten Rechners sind nach dem Datum noch da	Der Speicher sperrt sie noch (S3 Object Lock, die Löschverzögerung eines Verzeichnisses), oder eine Hold hält sie. Die Liste der Entfernungen zeigt das Datum oder die Hold, und der Worker löscht sie, sobald die Sperre abgelaufen oder die Hold aufgehoben ist.
Ein Restore-Test ist rot mit „Eine Datei weicht von der beim Backup festgehaltenen Prüfsumme ab“ (`hash_mismatch`)	Öffnen Sie den Bericht unter Berichte auf der Seite des Rechners, um die Abweichungen zu sehen. Führen Sie ein neues Backup und einen neuen Restore-Test aus. Meldet auch die Repository-Prüfung einen Schaden, prüfen Sie das Speicherziel.
„Eine Datei wurde im Snapshot nicht gefunden“ (`missing`), „Der Eintrag ist keine reguläre Datei“ (`not_regular`) oder „Eine Datei ließ sich nicht lesen“ (`read_error`)	Der Bericht nennt die Datei. Eine Datei, die nach einem fehlerfrei beendeten Restore fehlt, ist eine Feststellung: Der Hash in der Stichprobe wird nur von Dateien gebildet, die seit dem Snapshot nachweislich unverändert waren, sie weist also auf das Backup hin, nicht auf eine spätere Änderung. Eine Datei, die der Rechner nicht prüfen konnte (`not_regular`, `read_error`), belegt nichts: Der Test ist nicht abgeschlossen und wird erneut angeboten.
Ein Restore-Test zeigt Nicht abgeschlossen, wird wiederholt	Der Test konnte aus einem Grund nicht zu Ende laufen, der nichts über die Sicherung aussagt, zum Beispiel eine volle oder nicht beschreibbare Platte auf dem Rechner, ein während des Tests angehaltener oder neu gestarteter Agent oder ein beschäftigtes oder nicht erreichbares Repository. Es wurde nichts bewertet, und kein Alarm ging hinaus. Der Lauf nennt die Ursache; beheben Sie sie, wenn sie auf dem Rechner liegt (zum Beispiel Platz auf der Platte schaffen). Der Rechner bekommt denselben Test nach 1, 2, 4, 8, 16 und 24 Stunden erneut, solange diese Sicherung seine neueste ist; danach bringt die nächste Sicherung einen neuen Test.
Ein großer ZIP-Download bricht ab	Ein Proxy vor Restow kappt vielleicht Leerlauf-Verbindungen. Laden Sie weniger Elemente herunter oder erhöhen Sie das Leerlauf-Timeout des Proxys.

Einstellungen und Alarme

Symptom	Ursache und Abhilfe
„Dieser Rechner lässt keine Hooks aus Restow zu“ (`endpoint-hooks-not-allowed`)	Das Speichern eines Hooks wird abgelehnt, weil die Hook-Regel des Rechners `off` ist. Erlauben Sie Hooks auf dem Rechner mit `sudo restow-agent hooks scripts` oder `sudo restow-agent hooks any`. Restow erfährt die neue Regel innerhalb von fünf Minuten.
„Dieser Rechner führt nur Skripte aus /etc/restow-agent/hooks.d aus“ (`endpoint-hook-not-a-script`)	Die Regel des Rechners ist `scripts`, ein Hook muss also der Name eines Skripts in diesem Ordner sein (Buchstaben, Ziffern, Punkt, Bindestrich, Unterstrich), kein Befehl.
„Bestätigen Sie zuerst, dass Sie es sind“ (`recent-sign-in-required`)	Einen Hook zu setzen oder zu ändern und das Repository-Passwort anzuzeigen erfordert eine Anmeldung aus den letzten 10 Minuten. Bestätigen Sie mit Ihrem Passkey, oder melden Sie sich erneut an und wiederholen Sie die Aktion.
Alarm Verdächtiger Snapshot eines Servers oder Clients	Die Aufbewahrung hat einen Snapshot gefunden, den kein Sicherungslauf gemeldet hat, oder einen, der in der Zukunft datiert ist. Sie behält ihn und markiert ihn in den Sicherungsständen. Prüfen Sie den Rechner, er könnte kompromittiert sein. Die Weboberfläche bietet keine Aktion, um einen solchen Snapshot zu löschen: Muss er weg, entfernen Sie ihn mit restic und dem Repository-Passwort.
Alarm Speicherbudget von Servern und Clients	Ein Repository oder alle eines Mandanten zusammen haben 90 Prozent des Budgets erreicht, oder Uploads wurden abgelehnt. Siehe die Zeile zu Backup-Läufen oben.
Ein Sicherungsstand ist als Verdächtig markiert, oder die Aufbewahrung eines Rechners ist angehalten	Die Ransomware-Erkennung hat in einem Sicherungsstand Anzeichen eines Angriffs gefunden. Die Aufbewahrung behält die Sicherungsstände des Rechners, bis ein Administrator den Fall mit Als Fehlalarm markieren oder Aufbewahrung freigeben klärt. Prüfen Sie zuerst den Rechner.
Alarm Repository eines Servers oder Clients bleibt gesperrt	Aufbewahrung und Prüfungen haben das Repository sechsmal in Folge über mindestens 12 Stunden gesperrt vorgefunden. Meist läuft ein Backup sehr lange, oder ein Lauf des Agents hängt. Prüfen Sie den Rechner und seinen aktuellen Lauf. Ein Lauf ohne Fortschritt wird nach sechs Stunden geschlossen.

Speicherziel

Symptom Ursache und Abhilfe

Der Wechsel des primären Speicherziels unter Mandanten-Einstellungen → Repositories wird mit storage-active-endpoints abgelehnt Der Server lehnt einen Wechsel des Primärziels ab, solange Endpoints aktiv sind, weil ein aktiver Agent weiter auf das alte primäre Ziel schreibt, während es kopiert wird. Widerrufen oder deinstallieren Sie die Rechner, wechseln Sie das Primärziel mit Vorhandene Backups verschieben (empfohlen) und melden Sie die Rechner danach neu an. Sie werden zu neuen Endpoints mit neuen Repositories. Seit 0.4.2 kopiert das Verschieben die Repositories der widerrufenen Rechner mit. Siehe Überblick.

Symptom	Ursache und Abhilfe
Der Wechsel des primären Speicherziels unter Mandanten-Einstellungen → Repositories wird mit `storage-active-endpoints` abgelehnt	Der Server lehnt einen Wechsel des Primärziels ab, solange Endpoints aktiv sind, weil ein aktiver Agent weiter auf das alte primäre Ziel schreibt, während es kopiert wird. Widerrufen oder deinstallieren Sie die Rechner, wechseln Sie das Primärziel mit Vorhandene Backups verschieben (empfohlen) und melden Sie die Rechner danach neu an. Sie werden zu neuen Endpoints mit neuen Repositories. Seit 0.4.2 kopiert das Verschieben die Repositories der widerrufenen Rechner mit. Siehe Überblick.

Logs und Fehlersuche

Agent-Log: /var/log/restow-agent/agent.log, bei 5 MB rotiert, 3 Dateien bleiben erhalten.
Linux: dieselben Zeilen stehen im Journal: journalctl -u restow-agent.
macOS: /var/log/restow-agent/launchd.log enthält Absturzspuren.
In Restow: Öffnen Sie einen Lauf und dann Ende des Protokolls. Es zeigt die letzten Zeilen des Lauf-Protokolls mit maskierten Geheimnissen und die Fehler.
Ausführliches Logging: Hängen Sie --debug an einen Befehl, oder setzen Sie RESTOW_DEBUG=1. Um ein Backup mit Details im Vordergrund zu versuchen, führen Sie sudo restow-agent backup-now --debug aus.
Dienst: sudo restow-agent service status und sudo restow-agent service restart.

Endpoint-Sicherheitssoftware (EDR)

Ein Agent, der als root läuft, jede Datei auf dem Rechner liest, Daten per HTTPS sendet, einen Dienst installiert, seine eigene Binärdatei ersetzt und Shell-Befehle als Hooks ausführt, zeigt eine Kombination von Verhalten, auf die Sicherheitssoftware achtet. Antivirus- und EDR-Produkte können ihn deshalb melden, in Quarantäne legen oder blockieren. Diese Dokumentation macht keine Aussage zu einzelnen Produkten.

Stört Ihre Endpoint-Sicherheit, bitten Sie Ihr Sicherheitsteam:

Die beiden Binärdateien nach Pfad freizugeben: /opt/restow-agent/bin/restow-agent und /opt/restow-agent/bin/restic unter Linux, /Library/Application Support/Restow/bin/restow-agent und /Library/Application Support/Restow/bin/restic unter macOS.
Sie nach Hash freizugeben, wenn Ihre Richtlinie mit Hashes arbeitet. Das SHA-256 beider steht in der signierten Datei SHA256SUMS, die Ihre eigene Instanz neben den Binärdateien ausliefert, unter https://<your instance>/install/agent/<version>/SHA256SUMS. Der Agent aktualisiert sich von Ihrer Instanz, daher ändert sich der Hash von restow-agent mit jeder neuen Version. Geben Sie zusätzlich nach Pfad frei oder aktualisieren Sie die Hash-Liste nach einem Update. Der vorherige Agent bleibt als restow-agent.prev erhalten.
Ausgehendes HTTPS nur zu Ihrer Restow-Instanz zu erlauben. Der Agent verbindet sich mit nichts sonst und öffnet keinen Port.
Der Installation zu erlauben, die Dienstdatei anzulegen: /etc/systemd/system/restow-agent.service unter Linux, /Library/LaunchDaemons/com.restowbackup.agent.plist unter macOS.

Agent-Releases sind vom Maintainer signiert: eine OpenSSH-Signatur über SHA256SUMS, die das Installationsskript und der Agent prüfen. Die Binärdateien selbst tragen keine Code-Signatur und keine Notarisierung durch Apple. Verlangt Ihre Richtlinie code-signierte Software, testen Sie auf einem Rechner, bevor Sie ausrollen. Blockiert ein Produkt den Agent, endet der Lauf meist mit einem Fehler im Lauf-Protokoll oder im Agent-Log, und dort schauen Sie zuerst nach.