Fehlerbehebung beim Proxmox-VE-Backup
Beginnen Sie in Restow, unter Server & Clients → VMs & Container. Der Reiter Knoten sagt, ob jeder Knoten Verbunden ist, und listet seine Probleme. Ein Gast, bei dem etwas fehlgeschlagen ist, zeigt Letzter Lauf fehlgeschlagen; klicken Sie auf seine Zeile für den vollständigen Fehler und die Warnungen des letzten Laufs (seit 0.4.3), und seine Seite listet die Läufe mit ihrem Fehler. Nur Probleme im Reiter Gäste lässt nur die Gäste übrig, die Sie brauchen. Auf dem Knoten führt restow-pve diagnose jede Prüfung aus, die eine Sicherung braucht, und sagt, was nicht stimmt:
restow-pve diagnose # --json für Skripterestow-pve test # dasselbe, und der Exit-Code ist nur dann 0, wenn alles in Ordnung istjournalctl -u restow-pve # das Log des HelfersProxmox VE führt ein eigenes Task-Log jeder Sicherung und Wiederherstellung (die Aufgabenliste des Knotens in der Proxmox-VE-Weboberfläche). Sein Ende wird in den Fehler eines fehlgeschlagenen Laufs kopiert.
Installation und Anmeldung
Abschnitt betitelt „Installation und Anmeldung“Das Installationsskript gibt diese Meldungen auf Englisch aus. Vor seinen Prüfungen ändert es nichts, und „Nothing was installed.“ heißt genau das: Sie können den Befehl noch einmal ausführen.
| Meldung oder Symptom | Ursache und Abhilfe |
|---|---|
| „this installer must run as root on the Proxmox VE node“ | Führen Sie den Befehl als root aus. |
| „pveversion not found: this is not a Proxmox VE node“, „restow-pve supports x86_64 Proxmox VE nodes only“ | Das Installationsskript ist nur für Proxmox-VE-Knoten auf x86_64. |
| „Proxmox VE … is too old: the backup provider interface needs 8.4 or newer“ | Aktualisieren Sie Proxmox VE auf 8.4 oder neuer. |
| „curl is required“ | Installieren Sie curl. |
| „the instance URL must start with https://“ | Setzen Sie eine öffentliche https://-URL für Ihre Installation und erstellen Sie einen neuen Befehl. |
| Beim Erstellen des Befehls erscheint „Instance address unknown“ („The public address of this installation is not configured.“) | Setzen Sie die öffentliche URL der Installation in ihren Einstellungen. |
| „Restow does not accept this enrollment token: it was used for another node, has expired (24 hours) or was revoked.“ | Das Token gilt einmal, für einen Knoten, 24 Stunden. Wählen Sie in Restow Befehl für einen weiteren Knoten (oder öffnen Sie den Dialog neu) und führen Sie den neuen Befehl aus. |
| „Restow refuses enrollments from this address for a while (too many failed attempts). Try again later.“ | Warten Sie und führen Sie dann einen noch gültigen Befehl aus. Fehlversuche je Adresse sind begrenzt. |
| „cannot reach … from this node (HTTPS, port 443)“ | Der Knoten erreicht Ihre Instanz nicht. Prüfen Sie DNS, Firewall und Proxy (HTTPS_PROXY). Siehe Netzwerk. |
| „unexpected answer from … when checking the enrollment token (is this the address of your Restow instance?)“ | Die Adresse im Befehl ist nicht Ihre Restow-Instanz, oder ein Proxy antwortet an ihrer Stelle. Prüfen Sie die öffentliche URL. |
| „the enrollment token contains characters a token from Restow never has; copy the command from Restow again“ | Der Befehl wurde beim Kopieren verändert (Anführungszeichen, Zeilenumbrüche). Kopieren Sie ihn noch einmal mit Befehl kopieren. |
| „This Proxmox VE cluster is already connected to another tenant. A cluster serves one tenant in this release.“ | Ein Cluster gehört zu einem Mandanten. Nutzen Sie den Mandanten, der den Cluster schon hat. |
| „the API token … has privilege separation on, so it holds none of …’s privileges and lacks … on /.“ | Ein vorhandener API-Token wurde mit eingeschalteter Rechtetrennung erstellt (der Standard in der Proxmox-VE-Weboberfläche). Schalten Sie sie mit dem pveum user token modify ... --privsep 0-Befehl aus, den die Meldung zeigt, oder erstellen Sie einen Befehl ohne den Token (Neuer Befehl ohne diesen Token). |
| „the API token … lacks … on /.“ | Dem Token fehlen Rechte. Geben Sie ihm die Rolle RestowBackup auf / mit ausgeschalteter Rechtetrennung, siehe Knoten verbinden, oder nutzen Sie einen Befehl ohne den Token. |
| Warnung „the API token … lacks VM.Allocate on /pool/restow-restore: backups work, restores from Restow will fail until it has the role RestowRestore there“ | Gewähren Sie RestowRestore auf /pool/restow-restore (und auf /storage und /sdn). |
| „the PVE API does not accept the secret of the API token … (mistyped, expired or deleted)“ | Prüfen Sie die Token-ID und das Secret, die Sie eingetragen haben. Das Secret wird nur einmal gezeigt, wenn der Token erstellt wird. |
| „… is not a PVE API token id (user@realm!name)“ | Die Token-ID hat die Form benutzer@realm!name. |
| „this node has no active thin storage with content images (lvmthin, zfspool, rbd or btrfs). PVE backs up VMs through a backup provider only with fleecing: add one, or name another storage with –fleecing-storage=NAME (after sh -s –).“ | Richten Sie einen Thin-Speicher mit dem Inhaltstyp images ein oder nennen Sie einen mit --fleecing-storage. |
| Warnung „… is not an active thin storage with content images on this node …; fleecing may fail or reserve full disk sizes“ | Der genannte Speicher ist nicht thin oder nicht aktiv. Sicherungen können scheitern oder auf ihm die volle Festplattengröße belegen. |
| „checksum mismatch for …“, „SHA256SUMS hashes to …“, „the release signature does not match …“, „release … on this instance is not signed“, „this Restow instance has no release signing key …“ | Ein Download wurde beschädigt oder verändert, oder Ihre Instanz bietet kein signiertes Release an. Es wurde nichts installiert. Führen Sie den Befehl noch einmal aus. Scheitert er weiter, prüfen Sie, was zwischen dem Knoten und Ihrer Instanz sitzt und dass die Instanz ein Release-Image betreibt. Das sind dieselben Signaturprüfungen wie beim Agent, siehe Releases prüfen. |
| „this system can check the release signature neither with ssh-keygen (OpenSSH 8.1 or newer) nor with OpenSSL 3 …“ | Installieren Sie eines der beiden Werkzeuge, oder prüfen Sie SHA256SUMS.sig auf einem anderen Rechner und übergeben Sie RESTOW_SHA256SUMS_SHA256. |
| „… is not owned by root or is writable by group or others“, „… is a symbolic link; the install folder must be a real folder owned by root“ | restow-pve läuft als root und wird nur dort installiert, wo kein anderer Benutzer etwas ändern kann. Korrigieren Sie den Ordner, den die Meldung nennt, oder entfernen Sie ihn, wenn Sie ihn nicht angelegt haben. |
| „the storage plugin does not load in this PVE’s Perl; see the error above. Remove it with: sh pve.sh –uninstall“ | Der Perl-Fehler über der Meldung sagt, warum. Entfernen Sie das Plugin und melden Sie es mit der Proxmox-VE-Version (pveversion -v). |
| „enrollment failed (see above). Run this command again; if Restow says the token was used or expired, use “Command for another node” in Restow.“ | Lesen Sie den Fehler über der Meldung. Meist ist das Token benutzt oder abgelaufen. |
| Warnung „could not add the storage; add it by hand: pvesm add restow … –content backup –nodes …“ | Führen Sie den pvesm add-Befehl, den die Meldung zeigt, als root aus. |
| „this node is not enrolled and no enrollment token was given. In Restow (…), copy the command for this node and run it here.“ | Die erste Installation braucht das Token. Führen Sie den Befehl aus Restow aus. |
Probleme von Knoten
Abschnitt betitelt „Probleme von Knoten“Die Spalte Probleme des Reiters Knoten (und restow-pve diagnose auf dem Knoten) nennt, was Sicherungen auf einem Knoten verhindert:
| Problem | Ursache und Abhilfe |
|---|---|
| Speicher-Plugin nicht installiert | Die Plugin-Dateien fehlen auf dem Knoten. Führen Sie den Installationsbefehl noch einmal aus (auf einem angemeldeten Knoten braucht er kein Token) oder restow-pve update, und starten Sie dann pvedaemon, pveproxy, pvestatd und pvescheduler neu. Ab 0.4.3 startet restow-pve sie nach einem eigenen Update selbst neu. |
| API-Token ungültig | Proxmox VE antwortet 401 auf den API-Token des Knotens: Er wurde gelöscht, oder sein Secret hat sich geändert. Das kann der Knoten nicht selbst reparieren. Entfernen Sie den Helfer auf dem Knoten (restow-pve uninstall --yes), erstellen Sie in Restow einen neuen Befehl und führen Sie ihn aus. Melden Sie einen Knoten erneut an, ersetzt das seine frühere Anmeldung. |
| Proxmox-VE-API nicht erreichbar | Der Helfer erreicht die Proxmox-VE-API auf 127.0.0.1:8006 nicht. Prüfen Sie systemctl status pveproxy. Bei einem eigenen pveproxy-Zertifikat, das die Zertifizierungsstelle des Clusters nicht signiert hat, legen Sie es fest: restow-pve config --pve-cert-sha256 <sha>. |
| Proxmox VE älter als 8.4 | Aktualisieren Sie Proxmox VE. Die Backup-Provider-Schnittstelle braucht 8.4 oder neuer. |
| Dem API-Token fehlen Berechtigungen | restow-pve diagnose listet die fehlenden. Der Token braucht die Rolle RestowBackup auf / mit ausgeschalteter Rechtetrennung. |
| Kein Fleecing-Speicher | Es ist kein Fleecing-Speicher eingestellt, oder der eingestellte ist auf diesem Knoten nicht aktiv. Richten Sie einen Thin-Speicher ein oder stellen Sie ihn ein: restow-pve config --fleecing-storage <Speicher>. |
Verbindung
Abschnitt betitelt „Verbindung“| Symptom | Ursache und Abhilfe |
|---|---|
| Ein Knoten zeigt Getrennt | Restow hat seit mehr als drei Minuten keine Meldung von ihm. Der Knoten ist vielleicht aus, oder der Dienst ist gestoppt (systemctl status restow-pve), oder das Netz oder der Proxy ist ausgefallen. journalctl -u restow-pve sagt, warum. |
| Das Journal sagt „the Restow server refuses this node’s credentials (revoked?)“ | Der Knoten wurde in Restow widerrufen. Entfernen Sie den Helfer auf dem Knoten (restow-pve uninstall --yes) und verbinden Sie ihn dann mit einem neuen Befehl erneut. |
| Uploads scheitern mit HTTP 413 | Ein Proxy vor Restow begrenzt den Body. Erhöhen Sie das Limit auf mindestens 128 MiB. |
| Zertifikatsfehler | Der Helfer vertraut dem Zertifikat, das Ihre Instanz vorzeigt. Eine private Zertifizierungsstelle braucht einen Eintrag im Truststore des Knotens. Die Uhr des Knotens muss stimmen. |
| Der Knoten sitzt hinter einem Proxy | Setzen Sie HTTPS_PROXY und NO_PROXY für restow-pve.service, zum Beispiel mit systemctl edit restow-pve. |
Nach einem Server-Update bleibt ein Knoten auf dem alten restow-pve, oder der Reiter Updates führt ihn als Update verfügbar |
Der Schritt nach dem Server-Update hat ihn nicht erreicht, oder es lief kein solcher Schritt (der Server wurde von Hand aktualisiert). Wählen Sie im Reiter Updates Knoten und Agenten jetzt aktualisieren (seit 0.4.3) oder im Reiter Knoten Auf X.Y.Z aktualisieren für einen Knoten. Ein Knoten mit restow-pve 0.4.1 ignoriert beides: Aktualisieren Sie ihn von Hand als root, sobald dort keine Sicherung und keine Wiederherstellung läuft: /opt/restow-pve/bin/restow-pve update, dann systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler. Ein Knoten, der Getrennt ist, lässt sich gar nicht erreichen. Siehe Die Knoten nach einem Server-Update aktualisieren. |
Nach einem Update von restow-pve laufen die Proxmox-VE-Daemons noch mit dem alten Storage-Plugin |
Die Daemons laden das Plugin erst beim Start. restow-pve startet pvedaemon, pveproxy, pvestatd und pvescheduler seit 0.4.3 selbst neu; ein Knoten, den ein älteres Release aktualisiert hat, tut das einmal, nachdem das neue Release gestartet ist. Um es sofort zu tun: systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler. |
Sicherungen
Abschnitt betitelt „Sicherungen“| Symptom | Ursache und Abhilfe |
|---|---|
| Eine Sicherung bleibt bei Wartet auf den Knoten | Der Knoten startet eine angeforderte Sicherung bei seiner nächsten Meldung, meist innerhalb einer Minute. Bleibt sie stehen, ist der Knoten Getrennt oder mit einer anderen Aufgabe beschäftigt, siehe oben. Der Tooltip der Markierung sagt, seit wann die Sicherung wartet und wann der Knoten sich zuletzt gemeldet hat, und die Markierung ist gelb, solange der Knoten getrennt ist (seit 0.4.0). Eine Aufgabe, die der Knoten nicht abholt, läuft nach 12 Stunden ab. |
| Eine laufende Sicherung zeigt „Noch kein Fortschritt gemeldet“ oder „Der Fortschritt braucht restow-pve 0.4.0 auf … (dort läuft …). Aktualisieren Sie den Knoten.“ | Der Helfer auf diesem Knoten ist älter als 0.4.0 und kann keinen Fortschritt melden. Führen Sie restow-pve update auf dem Knoten aus oder warten Sie, bis er sich selbst aktualisiert. Die Sicherung selbst ist nicht betroffen. Seit 0.4.1 nennt die Seite den Knoten und seine Version. Ein Helfer ab 0.4.0, der sich noch nicht gemeldet hat, zeigt für einen Moment ebenfalls „Noch kein Fortschritt gemeldet“, bis die erste Zahl eintrifft. |
| Eine Sicherung, die lief, während Restow aktualisiert wurde, ist fehlgeschlagen | Ein Helfer vor 0.4.0 wartet etwa 30 Sekunden auf den Server und gibt dann auf, und ein Update startet die API neu und wendet Migrationen länger an. Ein Helfer ab 0.4.0 versucht es fünf Minuten lang weiter. Aktualisieren Sie den Helfer auf dem Knoten und starten Sie die Sicherung dann mit Jetzt sichern erneut. Das Anhalten neuer Läufe für ein Update steht unter Updates. |
| Letzter Lauf fehlgeschlagen: „vzdump ended with …: …“ | Restow zeigt das Ende des Proxmox-VE-Task-Logs. Öffnen Sie die ganze Aufgabe in der Proxmox-VE-Weboberfläche für die Ursache. |
| „The run never reported its end (node restarted or unreachable).“ | Der Knoten wurde während der Sicherung neu gestartet oder verlor die Verbindung. Mit restow-pve 0.4.0 oder neuer schließt Restow den Lauf, sobald die Meldung des Knotens ihn nicht mehr auflistet (nach etwa zehn Minuten), als erfolgreich, wenn sein Sicherungsstand schon gespeichert war, sonst als fehlgeschlagen. Ein Helfer vor 0.4.0 sendet keine solche Liste, und Restow schließt seinen Lauf nach 48 Stunden. Wählen Sie Jetzt sichern. |
| Eine VM scheitert mit einer Meldung, dass die Backup-Zugriffs-API vom laufenden QEMU nicht unterstützt wird | Die VM wurde gestartet, bevor QEMU aktualisiert wurde. Fahren Sie sie herunter und starten Sie sie über Proxmox VE einmal neu. |
| Eine VM-Sicherung, die Sie in Proxmox VE gestartet haben, scheitert mit „cannot setup backup access without fleecing“ | Für diese Sicherung ist Fleecing aus. Sicherungen über einen Backup-Provider brauchen Fleecing auf einem Thin-Speicher. Schalten Sie es im Backup-Job ein, oder fügen Sie vzdump die Option --fleecing enabled=1,storage=<Thin-Speicher> hinzu. Sicherungen, die Restow startet, nutzen es immer. |
| „Templates cannot be backed up“ | Eine VM-Vorlage. Proxmox VE schaltet Fleecing für Vorlagen aus, sie lassen sich also nicht über einen Backup-Provider sichern. |
| „No helper on that node: restow-pve is not enrolled on node … Install it there first.“ | Der Gast läuft auf einem Knoten ohne restow-pve, zum Beispiel nach einer Migration. Verbinden Sie auch diesen Knoten, siehe Knoten verbinden. |
| Eine andere Sicherung derselben VM scheitert oder lässt diese scheitern | Proxmox VE erlaubt nur eine Sicherung einer VM gleichzeitig. Legen Sie einen Proxmox-Backup-Server-Job oder jede andere Sicherung der VM zeitlich neben den Restow-Job. |
| „commit the restore point: …“ | Der Helfer verlor die Verbindung zu Restow, als er den Sicherungsstand speicherte. Ein erneuter Versuch kann einen Sicherungsstand nicht doppelt speichern. Lässt sich das Ergebnis nicht klären, scheitert die Sicherung, und die nächste Sicherung dieser Festplatte liest die ganze Festplatte (und lädt nur hoch, was sich geändert hat). |
| Die VM wird bei jeder Sicherung vollständig gelesen | Das ist zu erwarten bei einer VM, die ausgeschaltet ist, im Modus stop läuft oder neu gestartet, vergrößert oder verschoben wurde. Siehe Vollständiges Lesen nach einem Neustart. Es wird sehr wenig hochgeladen. |
| Eine Container-Sicherung scheitert mit „restic backup failed: …“ | Die letzten Zeilen des restic-Fehlers folgen, und die Ursache steht darin. Liegt es an der Verbindung zu Restow, wählen Sie noch einmal Jetzt sichern, sobald der Knoten die Instanz erreicht. |
| Eine Container-Sicherung scheitert mit „open lost+found: permission denied“ | restow-pve auf dem Knoten ist älter als 0.3.4. Führen Sie restow-pve update auf dem Knoten aus. |
| Eine Container-Sicherung zeigt Mit Lücken erfolgreich oder den Zustand Letzte Sicherung unvollständig | restic konnte einige Elemente nicht lesen. Der Sicherungsstand bleibt erhalten und nennt die Zahl. Die Spalte Fehler des Laufs nennt die ersten Elemente („Nicht gelesen: …“), und seit 0.4.0 behält der Lauf die ersten 20. Siehe Mit Lücken erfolgreich. |
| „mode failure - some volumes do not support snapshots“ im Proxmox-VE-Task-Log | Die Volumes des Containers liegen auf Speicher ohne Snapshots (Verzeichnis, NFS). Proxmox VE fällt auf den Modus suspend zurück, der den Container kurz anhält und temporären Platz braucht. |
| Eine Sicherung zeigt Erfolgreich mit Warnungen, oder das Proxmox-VE-Task-Log sagt „TASK WARNINGS: 1“ | vzdump hat die Sicherung beendet und neben ihr vor etwas gewarnt, und der Sicherungsstand wurde festgeschrieben. Seit 0.4.2 ist das ein Erfolg, mit den Warnzeilen im Lauf, kein Fehler. Vor 0.4.2 wurde eine solche Sicherung als fehlgeschlagen gemeldet, meist wegen einer Notiz, die Proxmox VE und das Storage-Plugin austauschten; restow-pve 0.4.2 oder neuer fordert keine Notizen an. Aktualisieren Sie den Knoten. Siehe Erfolgreich mit Warnungen. |
Eine Container-Sicherung scheitert mit restic ... exit code 11 und einer Meldung, dass der Befehl „unlock“ veraltete Sperren entfernen kann |
Ein anderer Vorgang hielt die Sperre des Repositorys des Containers: meist ein früherer Lauf desselben Gasts, dessen Sperre ein Abbruch oder ein API-Neustart zurückgelassen hatte. Restow entfernt veraltete Sperren (älter als 30 Minuten oder von einem Prozess, den es nicht mehr gibt) vor Prüfungen und vor der Aufbewahrung, und restow-pve ab 0.4.3 wartet bei einer Container-Sicherung bis zu 15 Minuten auf die Sperre. Führen Sie Jetzt sichern noch einmal aus; aktualisieren Sie den Knoten (restow-pve update), wenn er älter als 0.4.3 ist. |
| Eine Sicherung zeigt Abgebrochen | Jemand hat sie in der Weboberfläche gestoppt („Abgebrochen von“ und der Name). Das ist kein Fehler, löst keinen Alarm aus, und die Sicherungsstände bleiben unberührt. Siehe Eine Sicherung stoppen und eine Warteschlange anhalten. |
| Sicherung stoppen sagt länger als eine Minute „Wird abgebrochen…“ | Der Knoten stoppt eine laufende Sicherung mit seinem nächsten Heartbeat, meist innerhalb von 15 Sekunden. Ein Knoten vor 0.4.2 sendet während einer Sicherung keinen Heartbeat und beendet sie erst bei seinem nächsten Upload, und ein Knoten, der Getrennt ist, hört den Auftrag gar nicht. Aktualisieren Sie den Knoten (restow-pve update) und prüfen Sie systemctl status restow-pve. Einen abgebrochenen Lauf, dessen Knoten 15 Minuten lang stumm bleibt, schließt der Server. |
| Eine Sicherung wartet, und der Knoten sagt Warteschlange angehalten | Jemand hat bei diesem Knoten Warteschlange anhalten gewählt („Angehalten von“ zeigt den Namen). Wählen Sie Warteschlange fortsetzen. Geplante Sicherungen warten so lange und verfallen nach 12 Stunden. |
Eine Container-Sicherung wird mit einer Meldung zu ihrem Repository abgelehnt (pve-repository-elsewhere) |
Das Repository des Containers liegt auf einem anderen Repository des Mandanten, meist einem ausgemusterten primären nach „Vorhandene Backups dort belassen, wo sie sind“ (0.4.1 und früher). Es wurde nichts angelegt. Ziehen Sie die Sicherungen mit einem Speicher-„Verschieben“ um (Das primäre Repository ersetzen) oder setzen Sie das Repository zurück (Neue Sicherungskette und Repository zurücksetzen). |
Eine Container-Sicherung wird mit „Repository state unclear“ abgelehnt (409, pve-repository-leftover, englischer Text) |
Der Container hat Sicherungsstände, aber sein Repository ist nicht als bereit vermerkt, und Restow rät nicht. Nutzen Sie Repository zurücksetzen auf der Seite des Gasts, um eine neue Sicherungskette zu beginnen (Neue Sicherungskette und Repository zurücksetzen). Repository zurücksetzen selbst wird abgelehnt, wenn der eingetippte Name nicht zum Gast passt (pve-repository-confirm-name) und bei einer VM (pve-repository-not-container): Nur Container haben ein eigenes Repository. |
Eine Container-Sicherung scheitert, weil ihr Repository nicht erreichbar ist (pve-repository-unreachable) |
Der Speicher hat nicht geantwortet, das ist nicht dasselbe wie „fehlt“: Es beginnt keine neue Kette. Prüfen Sie den Speicher (Netzwerkfreigabe, S3-Endpunkt, Zugangsdaten) und führen Sie Jetzt sichern erneut aus. |
| Der Gast sagt „Neue Sicherungskette am … begonnen: Das bisherige Repository wurde in … nicht gefunden“ | Der Server hat das Repository des Containers nirgends gefunden und ein neues begonnen (pve.repository.reinitialized im Audit-Log). Die früheren Sicherungsstände sind Nicht verfügbar und lassen sich nicht wiederherstellen. Die Aufbewahrung lässt sie in Ruhe, und die Wiederherstellbarkeit zählt sie nicht mehr. Siehe Neue Sicherungskette und Repository zurücksetzen. |
| Jetzt sichern oder das Aufnehmen eines Gasts in einen Job wird mit 409 und „Restow-Server“ abgelehnt | Auf dem Gast läuft Restow selbst, und ihn mit Restow zu sichern kann sich gegenseitig blockieren. Sichern Sie ihn stattdessen mit der Sicherung von Proxmox VE selbst oder bestätigen Sie das Risiko im Dialog. Siehe Die VM des Restow-Servers selbst. Restow in einem Container oder hinter einem Knoten vor 0.4.2 wird nicht von selbst gefunden: Kreuzen Sie auf seiner Seite Dies ist der Restow-Server an. |
Das Journal von restow-pve sagt „404 Task not found“ zu einem Aufgabenergebnis (ein Helfer vor 0.4.2) |
Der Knoten hat ein Ergebnis gemeldet, nachdem der Server die Aufgabe geschlossen hatte. Der Server nimmt ein solches spätes Ergebnis seit 0.4.2 an und gleicht den Lauf ab: Ein festgeschriebener Sicherungsstand zählt immer als erfolgreich. Seit 0.4.2 behält der Knoten außerdem ein Ergebnis, das der Server nicht annehmen konnte, und sendet es mit dem nächsten Heartbeat erneut. Aktualisieren Sie den Knoten. |
Wiederherstellungen
Abschnitt betitelt „Wiederherstellungen“| Symptom | Ursache und Abhilfe |
|---|---|
| „Privilegierte Container kann Proxmox VE aus einer Backup-Schnittstelle nicht wiederherstellen.“ (die API sagt: „PVE refuses to restore privileged containers from a backup provider. Restore it by hand as unprivileged.“) | Ein privilegierter Container lässt sich nicht über Restow wiederherstellen. Stellen Sie ihn von Hand als nicht privilegierten wieder her. |
Eine Container-Wiederherstellung oder eine Startprüfung eines Containers (Nicht gestartet) scheitert mit Can't use string ("restow") as a HASH ref |
Das Plugin von restow-pve vor 0.4.6 akzeptiert nicht, wie das aktuelle Proxmox VE es für Container aufruft. Aktualisieren Sie restow-pve auf dem Knoten (der Server bietet es an, oder führen Sie als root restow-pve update aus) und führen Sie dann bei den Sicherungsständen, die Nicht gestartet oder Fehlgeschlagen zeigen, erneut Jetzt Start prüfen oder Jetzt prüfen aus. VMs sind nicht betroffen. Siehe Wiederherstellen. |
| „Restores are off on this node“ („Restores are switched off on node … (restow-pve config –allow-restores)“) | Jemand hat auf diesem Knoten restow-pve config --allow-restores=false ausgeführt. Erlauben Sie Wiederherstellungen auf dem Knoten mit --allow-restores=true wieder, oder wählen Sie einen anderen Zielknoten. |
| „No helper on that node“, wenn Sie einen Zielknoten wählen | Auf diesem Knoten ist restow-pve nicht angemeldet. Wählen Sie einen Knoten, auf dem es läuft. |
| Die Wiederherstellung bleibt wartend | Der Knoten startet sie bei seiner nächsten Meldung. Ist der Knoten Getrennt, wartet sie, bis er zurück ist. Eine Aufgabe, die nicht abgeholt wird, läuft nach 12 Stunden ab. |
| Fehlgeschlagen mit „restore ended with …: …“ | Restow zeigt das Ende des Proxmox-VE-Task-Logs. Typische Ursachen: Der Zielspeicher existiert auf dem Zielknoten nicht, hat keinen Platz oder erlaubt keine Gast-Festplatten, die Neue ID ist vergeben, eine Bridge oder ein virtuelles Netz des Gasts ist für den Token nicht erlaubt (SDN.Use), oder der Benutzer restow@pve, seine Rollen oder der Pool restow-restore wurden gelöscht. |
| „restores are switched off on this node (restow-pve config –allow-restores=false)“ in einem Lauf | Dasselbe wie oben, vom Knoten gemeldet. |
| „the restore server did not start within 60 seconds“ | Der NBD-Server, der Proxmox VE eine Festplatte des Sicherungsstands bereitstellt, ist nicht gestartet. journalctl -u restow-pve auf dem Knoten sagt, warum. |
| Eine Container-Wiederherstellung scheitert aus Platzmangel | Der restic-Snapshot wird zuerst nach /var/tmp/restow-pve entpackt. Schaffen Sie dort Platz, oder verweisen Sie mit restow-pve config --restore-tmp auf einen größeren Ordner. |
| „the restored guest has no readable configuration“ in einem Lauf der Art Restore-Prüfung | Die monatliche Restore-Prüfung hat den Gast wiederhergestellt, aber Proxmox VE hat für ihn keine lesbare Konfiguration. Öffnen Sie den Lauf für die Einzelheiten und versuchen Sie eine manuelle Wiederherstellung desselben Sicherungsstands. |
Startprüfungen
Abschnitt betitelt „Startprüfungen“Wie sie funktionieren, steht unter Startprüfungen.
| Symptom | Ursache und Abhilfe |
|---|---|
| Es gibt kein Jetzt Start prüfen, und die Seite sagt „Keine Startprüfung möglich: …“ | Die Seite nennt den Grund. restow-pve ist auf dem Knoten des Gasts nicht installiert, oder es ist älter als 0.4.0 oder hat Startprüfungen ausgeschaltet (restow-pve config --boot-tests=true, dann den Dienst neu starten), oder Wiederherstellungen sind auf dem Knoten ausgeschaltet, oder der Gast ist ein privilegierter Container (Proxmox VE kann ihn nicht wiederherstellen) oder eine VM-Vorlage. |
| Eine Startprüfung ist Übersprungen | Der Knoten hat sie nicht ausgeführt, und der Lauf sagt warum: Der Gast braucht mehr Arbeitsspeicher als das Limit des Jobs (Nur Gäste mit höchstens so viel Arbeitsspeicher starten (MiB)), der Knoten hat weniger Arbeitsspeicher frei als das plus 1 GiB, der Speicher hat zu wenig Platz (die Daten des Sicherungsstands plus ein Zehntel davon und 1 GiB), kein geeigneter Speicher (--boot-test-storage), auf dem Knoten läuft eine Sicherung oder Wiederherstellung, oder eine andere Startprüfung läuft. Eine übersprungene Prüfung bewertet nichts und löst kein Ereignis aus. |
| Gestartet, keine Antwort und das Ereignis Startprüfung ohne Nachweis | Die VM ist gestartet und lief weiter, aber ihr QEMU Guest Agent hat innerhalb der Wartezeit (fünf Minuten) nicht geantwortet. Installieren Sie den QEMU Guest Agent in der VM und starten Sie ihn, oder nehmen Sie hin, dass nichts das System nachweist. Eine Windows-VM ohne Guest Agent wird nie besser als das. |
| Nicht gestartet und das Ereignis Startprüfung nicht bestanden | Die Wiederherstellung, der Start oder das Hochfahren ist fehlgeschlagen. Die Meldung des Laufs nennt den Schritt. Ein Gast, der Passthrough-Hardware braucht, kann scheitern, weil die Prüfung sie entfernt. |
Ein temporärer Gast restow-boottest-<vmid> liegt noch im Pool restow-restore |
Der Helfer zerstört ihn in jedem Fall und entfernt Überbleibsel beim Start des Dienstes und vor jeder Startprüfung. Bleibt einer stehen (der Knoten verlor mittendrin den Strom), starten Sie restow-pve neu. Entfernt werden nur Gäste, die sowohl das Tag restow-boottest als auch diesen Namen tragen. |
| Eine Startprüfung beginnt nie | Je Knoten läuft eine Prüfung zur Zeit, und nie neben einer Sicherung, und ein Knoten, der sich zehn Minuten nicht gemeldet hat, bekommt keine geplante Prüfung. Eine Anforderung wartet bis zu 24 Stunden auf ihren Knoten. |
Dateien eines Gasts
Abschnitt betitelt „Dateien eines Gasts“Siehe Dateien eines Gasts.
| Symptom | Ursache und Abhilfe |
|---|---|
| „Die Sicherungsdaten sind gerade belegt“ | Die Aufbewahrung oder die wöchentliche Prüfung arbeitet am restic-Repository dieses Containers. Versuchen Sie es gleich noch einmal. Eine laufende Sicherung blockiert es nicht. |
| Ein VM-Sicherungsstand listet keinen Ordner oder nicht den erwarteten | Nur Dateisysteme, die der Server lesen kann, werden zu Ordnern (ext2/3/4, XFS, NTFS, FAT, auch auf linearem LVM). Die Seite listet mit dem Grund, was sie nicht lesen konnte (btrfs, ZFS, BitLocker und so weiter). |
| Eine Datei fehlt im ZIP | Sie steht mit dem Grund in _not-restored.txt im ZIP. |
| Der Download startet nicht | Ein vorbereitetes ZIP startet einmal, innerhalb von zehn Minuten, für die Person, die es vorbereitet hat. Bereiten Sie es neu vor. |
| Eine Datei von einem XFS- oder NTFS-Volume ist älter als erwartet | Das XFS-Log und das NTFS-$LogFile werden nicht nachgespielt, ein absturzkonsistenter Sicherungsstand kann also die letzten Schreibzugriffe vermissen. Vergleichen Sie mit dem Original oder stellen Sie die ganze VM wieder her. |
Übersichten und Zählwerte
Abschnitt betitelt „Übersichten und Zählwerte“| Symptom | Ursache und Abhilfe |
|---|---|
| Nach dem Verbinden eines Knotens erscheinen keine Gäste | Sie erscheinen innerhalb einer Minute. Prüfen Sie, dass der Knoten Verbunden ist und restow-pve diagnose kein Problem meldet. Der Token braucht VM.Audit, um Gäste aufzulisten. |
Ein Gast sagt Ausgeschlossen, Jetzt sichern wird abgelehnt, und er lässt sich keinem Job zuordnen (409 urn:restow:problem:pve-guest-excluded) |
Eine Administration hat ihn bewusst von der Sicherung ausgeschlossen (seit 0.4.7). Wählen Sie Wieder einschließen auf seiner Seite oder in seiner Inventarzeile; er wird wieder gesichert, sobald ein Job ihn erfasst. Solange er ausgeschlossen ist, zählt er nirgends als ungeschützt. Siehe Einen Gast von der Sicherung ausschließen. |
| Das Ausschließen einer Auswahl von Gästen im Inventar bricht auf halbem Weg ab | Das Inventar sendet eine Anfrage je Gast, es gibt keine Sammelroute. Scheitert eine, bleiben die Gäste davor ausgeschlossen, und die Liste aktualisiert sich; wählen Sie den Rest erneut aus. |
| Ein Gast zeigt Nicht mehr gemeldet | Sein Knoten meldet ihn nicht mehr: Er wurde gelöscht oder auf einen Knoten verschoben, auf dem restow-pve nicht läuft. |
| Ein Gast wird vom Job für alle Gäste gesichert, aber das Inventar sagt Kein Backup-Job | Das Inventar zeigt den Job, dem ein Gast zugeordnet ist, weiterhin in 0.4.7. Der Gast wird gesichert und zählt anderswo als geschützt. Siehe Backup-Jobs und Schutz. |
| Ein Gast des Jobs für alle Gäste behält nur 7 tägliche, 4 wöchentliche und 6 monatliche Sicherungsstände, unabhängig von den Feldern des Jobs | Die Aufbewahrung nutzt die Regeln des Jobs, dem ein Gast zugeordnet ist, und die Vorgaben für einen Gast, der keinem zugeordnet ist, weiterhin in 0.4.7. Ordnen Sie den Gast dem Job zu. Siehe Aufbewahrung. |
| Proxmox VE warnt, das Plugin „is implementing an older storage API“ | Das Plugin auf dem Knoten stammt aus 0.3.1. Führen Sie restow-pve update auf dem Knoten aus. Seit 0.3.2 meldet das Plugin die Storage-API des laufenden Proxmox VE. |
| Remove in der Proxmox-VE-Weboberfläche wird abgelehnt | Erwartet: „retention is managed in Restow“. Sicherungsstände entfernt nur die Aufbewahrung in Restow. |
| Ein Gast sagt Nicht prüfbar und sein Sicherungsstand Nicht prüfbar: Repository gesperrt (gelb) | Die Restore-Prüfung des neuesten Sicherungsstands konnte zwei Stunden lang nicht laufen, weil ein anderer Vorgang die Sperre des Repositorys des Containers hielt. Das ist keine fehlgeschlagene Prüfung: Über den Sicherungsstand ist noch nichts bekannt, er ist weder rot noch grün. Öffnen Sie den Gast (klicken Sie auf seine Zeile unter VMs & Container): Warum die Prüfung nicht laufen konnte gibt den Bericht von restic wieder, wer die Sperre hält (Prozess-ID, Host, Benutzer, wann sie angelegt wurde). Meist braucht es nichts: Ein lebender Vorgang endet und gibt die Sperre frei, eine veraltete Sperre (älter als 30 Minuten oder von einem Prozess, den es nicht mehr gibt) entfernt Restow vor der nächsten Prüfung und vor der Aufbewahrung, und die wöchentliche Prüfung versucht den Gast nach einem Tag erneut. Um früher zu lesen, wählen Sie Jetzt prüfen beim Gast oder Alle ungeprüften prüfen in der Wiederherstellbarkeit. Kommt die Sperre immer wieder, suchen Sie nach einem anderen Prozess, der dasselbe Repository nutzt (zum Beispiel ein von Hand ausgeführter restic-Befehl), und prüfen Sie, ob der Knoten restow-pve 0.4.3 oder neuer ausführt, das bei einer Container-Sicherung auf die Sperre wartet. Sie müssen keine Sperrdateien von Hand entfernen. Seit 0.4.3. Siehe Restore-Prüfungen, die nicht laufen konnten. |
| Ein Gast sagt Restore-Prüfung verschoben, und der Sicherungsstand Prüfung verschoben: Repository gesperrt | Die Prüfung ist auf eine Sperre gestoßen und wird in etwa zehn Minuten erneut versucht; das vorherige Ergebnis gilt so lange. Nach zwei Stunden wird daraus Nicht prüfbar: Repository gesperrt. Nicht prüfbar: Prüfung unterbrochen heißt, dass restic wiederholt gestoppt wurde, bevor die Prüfung fertig war. |
Ein Gast zeigt eine rote Restore-Prüfung fehlgeschlagen mit restic check failed (exit code 11) und „the unlock command can be used to remove stale locks“ |
Eine Restore-Prüfung vor 0.4.3 ist fehlgeschlagen, weil ein anderer Vorgang die Sperre des Repositorys hielt, nicht weil der Sicherungsstand beschädigt ist. Ab 0.4.3 wird eine solche Prüfung stattdessen verschoben. Der rote Zustand bleibt bis zur nächsten Prüfung des Gasts: Wählen Sie Jetzt prüfen. |
| Ein Sicherungsstand ist Noch nicht geprüft | Jeder neue Sicherungsstand wird seit 0.4.2 binnen Minuten nach seiner Sicherung geprüft, außer Jeden neuen Sicherungsstand direkt nach der Sicherung prüfen ist unter Installation → Proxmox VE aus; dann erreicht ihn die wöchentliche Prüfung. Eine wartende Prüfung zeigt Prüfung eingereiht und läuft mit dem nächsten Durchlauf (alle fünf Minuten). Wählen Sie bei dem Sicherungsstand Jetzt prüfen oder in der Wiederherstellbarkeit Alle ungeprüften prüfen. |
| Eine Restore-Prüfung ist Fehlgeschlagen, und die Seite sagt nur „Restore-Prüfung fehlgeschlagen“ | Die Prüfung hat einen echten Fehler gefunden und zeigt ihn seit 0.4.2 unter dem Zeichen (zum Beispiel den Fehler von restic oder einen Block, der nicht übereinstimmte oder sich nicht lesen ließ); seit 0.4.6 öffnet sich der ganze Text bei Hover oder Tastaturfokus in einer Karte, die Sie markieren und kopieren können, vorher stand er im Tooltip. Vor 0.4.2 sagte die Seite nur, dass Blöcke nicht übereinstimmten oder sich nicht lesen ließen. Führen Sie Jetzt prüfen einmal erneut aus und lesen Sie den Fehler: Ein Speicherproblem nennt sich dort selbst. |
| Ein Sicherungsstand ist Nicht verfügbar | Er gehört zu einer früheren Sicherungskette eines Containers, dessen Repository nicht mehr vorhanden ist (eine neue Sicherungskette begann, oder Sie haben Repository zurücksetzen genutzt). Er lässt sich nicht mehr wiederherstellen, durchsuchen oder prüfen, und die Aufbewahrung lässt ihn in Ruhe. Siehe Neue Sicherungskette und Repository zurücksetzen. |
Logs und Dateien auf dem Knoten
Abschnitt betitelt „Logs und Dateien auf dem Knoten“journalctl -u restow-pve: das Log des Helfers.restow-pve status --jsonundrestow-pve diagnose --json: der Zustand und die Prüfungen als Daten.- Das Proxmox-VE-Task-Log der Sicherung oder Wiederherstellung, in der Weboberfläche von Proxmox VE.
/var/lib/restow-pve(Caches und das Journal),/run/restow-pve(laufende Jobs) und/etc/restow-pve/state.json(das Secret und der Token des Knotens, nur root: schicken Sie sie niemandem).