Ich hatte eins. Jeden Abend um 21 Uhr sichert mein Proxmox-Host alle Gäste auf einen Proxmox Backup Server. Aufbewahrung, Garbage Collection und Verify waren sauber eingerichtet, die Deduplizierung lag bei ungefähr 66:1. Ich war zufrieden. Vom 7. bis zum 9. Oktober ist trotzdem jede einzelne Sicherung gescheitert, und ich habe es nicht gemerkt.

Draufgestoßen bin ich durch reinen Zufall. Ich wollte eigentlich nur nachsehen, ob es auf dem Backupserver Updates zu installieren gab. Dabei bin ich über den Ausfall gestolpert.

Wie mein Backup aufgebaut ist

Damit die Fehler gleich Sinn ergeben, kurz zum Aufbau:

• Proxmox VE 9 auf einem einzelnen Host. Ein Backup-Job sichert jeden Abend alle Gäste im Snapshot-Modus.
• Proxmox Backup Server (PBS) 4.2 läuft als Container auf demselben Host. Das ist nicht ideal, dazu später mehr.
• Der Datastore des PBS, also der Ort, an dem die Sicherungen tatsächlich liegen, ist ein NFS-Share auf meinem NAS, einem UniFi UNAS Pro mit UniFi Drive.

Kurz zu den Begriffen: NFS ist ein Protokoll, mit dem ein Rechner ein Verzeichnis eines anderen Rechners wie eine lokale Festplatte einbindet. Ein „Export“ ist auf der NAS-Seite die Freigabe samt Regeln, wer darauf zugreifen darf und mit welchen Rechten.

Fehler Nummer eins: der PBS war aus

Im Aufgabenprotokoll von Proxmox stand an allen drei Abenden dasselbe:

could not activate storage 'PBS' ... Can't connect to 10.0.98.50:8007 (No route to host)

„No route to host“ klingt nach Netzwerk, war aber viel banaler. Der Container mit dem PBS lief schlicht nicht. Wenn kein Programm auf der Adresse antwortet, gibt es eben auch keinen Weg dorthin.

Warum er gestoppt war, weiß ich bis heute nicht.

Ein kleiner Tipp am Rande: Proxmox VE 9 schreibt kein /var/log/syslog mehr. Den Status der letzten Backup-Läufe bekommt man so:

pvesh get /nodes/<NODE>/tasks --typefilter vzdump --limit 5 --output-format json

Den Container gestartet, Autostart eingeschaltet (onboot 1), Haken dran. Dachte ich.

Fehler Nummer zwei: Wartungsmodus

Der PBS lief wieder, das Backup scheiterte trotzdem. Diesmal stand der Datastore im Wartungsmodus „offline“. In diesem Zustand nimmt der PBS keine Sicherungen an, auch wenn der Dienst selbst läuft.

Aufheben lässt sich das mit einem Befehl, ausgeführt im PBS-Container:

proxmox-backup-manager datastore update Repository --delete maintenance-mode

Wer oder was den Wartungsmodus gesetzt hat, habe ich nicht herausgefunden. Das steht noch auf meiner Liste.

Fehler Nummer drei: das NAS hat eigene Vorstellungen von Rechten

Jetzt wird es interessant. Die Dateien im Datastore gehören auf dem NAS dem Benutzer und der Gruppe mit der ID 34. Das ist unter Debian der Systembenutzer backup, unter dem der PBS arbeitet. Die Rechte stehen auf 770, also darf nur dieser Benutzer hinein.

UniFi Drive bildet NFS-Zugriffe aber standardmäßig auf einen eigenen Benutzer ab. Im Export steht dann:

all_squash,anonuid=977,anongid=988

all_squash heißt: Egal, als wer der Client kommt, auf dem NAS gilt er als Benutzer 977. Und der darf in den Datastore nicht hinein. Ergebnis: Permission denied.

Das Problem kannte ich schon von der Einrichtung. Damals hatte ich den Export per SSH direkt auf dem NAS angepasst:

cd /etc/exports.d/
grep -l Repository *.exports            # die passende Datei finden
sed -i 's/anonuid=977,anongid=988/anonuid=34,anongid=34/' <DATEI>
exportfs -ra                            # übernehmen, ohne den NFS-Server neu zu starten
exportfs -v | grep -A1 Repository       # muss jetzt anonuid=34,anongid=34 zeigen

exportfs -ra ist dabei wichtig. Ein Neustart des NFS-Servers würde alle anderen Mounts kurz unterbrechen, und davon hängen bei mir auch die Docker-Container ab.

Irgendwann zwischen damals und dem Ausfall war diese Änderung aber verschwunden. Also noch einmal angepasst, im Container neu eingebunden, Backup von Hand gestartet. Um 23:40 Uhr stand da endlich Backup job finished successfully.

Und dann hat das NAS es noch einmal gemacht

Am selben Abend habe ich gleich noch etwas umgebaut, das schon länger auf der Liste stand. Dazu gleich mehr. Dabei habe ich in der UniFi-Oberfläche die NFS-Verbindung eines anderen Containers geändert, meines Medienservers.

Kurz nach Mitternacht kam der PBS nach einem Neustart wieder nicht an seinen Datastore. Der Export stand wieder auf 977:988.

Die Erklärung: UniFi Drive schreibt bei jeder Änderung an irgendeiner NFS-Verbindung alle Export-Dateien neu. Meine Handarbeit auf der Kommandozeile kennt die Oberfläche nicht, also ist sie danach weg. Vermutlich war genau das auch der Grund, warum der Fix vorher schon verschwunden war. Beweisen kann ich das nicht.

Ich hatte also die Wahl: entweder nie wieder etwas an den NFS-Verbindungen ändern, oder dem NAS beibringen, meine Änderung selbst wiederherzustellen.

Ein Wächter auf dem NAS

Das NAS läuft intern mit systemd. Damit lässt sich eine path-Unit bauen. Die beobachtet ein Verzeichnis und startet einen Dienst, sobald sich darin etwas ändert. Dazu kommt ein Timer, der alle fünf Minuten nachsieht, falls doch einmal etwas durchrutscht.

Das Skript selbst ist klein:

#!/bin/sh
# Repository-Export fuer PBS auf UID/GID 34 (backup) mappen.
F=$(grep -l "/var/nfs/shared/Repository " /etc/exports.d/*.exports 2>/dev/null)
[ -n "$F" ] || exit 0
if grep -q "anonuid=977,anongid=988" "$F"; then
  sed -i 's/anonuid=977,anongid=988/anonuid=34,anongid=34/' "$F"
  exportfs -ra
  logger -t repo-export-fix "Repository-Export korrigiert: $F"
fi

Es ändert nur dann etwas, wenn wirklich der UniFi-Standard drinsteht. Ein zweiter Lauf tut nichts.

Dazu drei Units unter /etc/systemd/system/:

# repo-export-fix.service
[Unit]
Description=Repository-NFS-Export auf UID 34 (PBS) mappen

[Service]
Type=oneshot
ExecStart=/data/scripts/repo-export-fix.sh

# repo-export-fix.path
[Unit]
Description=Aenderungen in /etc/exports.d ueberwachen

[Path]
PathModified=/etc/exports.d

[Install]
WantedBy=multi-user.target

# repo-export-fix.timer
[Unit]
Description=Repository-Export alle 5 Minuten pruefen

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

Einschalten und einmal von Hand starten:

systemctl daemon-reload
systemctl enable --now repo-export-fix.path repo-export-fix.timer
systemctl start repo-export-fix.service

Zum Test habe ich den Export absichtlich zurückgedreht. Nach weniger als drei Sekunden war er wieder korrigiert, und im Journal stand die Meldung:

journalctl -t repo-export-fix

Meine größte Sorge war, ob Skript und Units ein Firmware-Update des NAS überleben. Herstellerfirmware räumt gern alles weg, was nicht von ihr selbst stammt. Das erste Update kam gleich am nächsten Tag, und der Wächter war danach noch da. Verlassen mag ich mich darauf trotzdem nicht. Nach jedem Update prüfe ich deshalb kurz:

systemctl is-enabled repo-export-fix.path repo-export-fix.timer

Beide müssen enabled melden. Sonst richte ich sie neu ein. Die komplette Anleitung liegt dafür in meinen Notizen.

Nebenbei: Backup ohne Umweg über die Firewall

Der Umbau, von dem oben die Rede war: Bis dahin lief der Backup-Verkehr vom Proxmox-Host zum NAS geroutet, also quer durch die Firewall, inklusive Intrusion Prevention. Für Backup-Daten ist das ein unnötiger Umweg, und es macht die Firewall zum Teil des Backups.

Jetzt hängen Host, PBS-Container und Docker-VM zusätzlich mit einer zweiten Netzwerkkarte direkt im Storage-VLAN des NAS. Der Verkehr bleibt auf Layer 2, also im selben Netzsegment, und läuft nur noch über den Switch. Auf dem Host ist das eine eigene Bridge ohne Gateway:

auto vmbr<VLAN>
iface vmbr<VLAN> inet static
        address 10.0.99.2/28
        bridge-ports nic0.<VLAN>
        bridge-stp off
        bridge-fd 0

Zwei Dinge habe ich dabei gelernt:

• Sobald ein Gast eine Netzwerkkarte im Storage-VLAN hat, nutzt er sie auch als Absender. Das NAS muss dann die neue IP in der Freigabe kennen. Sonst läuft der alte Mount noch eine Weile asymmetrisch weiter, also Anfrage direkt und Antwort über den Router, und bricht beim nächsten Neuverbinden ab.
• Den Server im Storage-Eintrag von Proxmox kann man mit pvesm set nicht ändern, weil server ein fester Parameter ist. Ich habe die Zeile direkt in /etc/pve/storage.cfg angepasst. Der Fingerprint des PBS bleibt dabei gleich, Proxmox merkt also nichts.

Warum es niemand gemerkt hat

Das ist eigentlich die wichtigste Frage, und die Antwort ist peinlich einfach. Proxmox hat die Fehler gemeldet, brav, jeden Abend. Das Benachrichtigungsziel war aber mail-to-root, und diese Mails landeten im lokalen Postfach von root auf dem Host. Da schaut niemand rein.

Zwei Tage später habe ich das richtig eingerichtet: Proxmox verschickt Benachrichtigungen jetzt per SMTP über meinen eigenen Mailserver, mit Anmeldung, und die Firewall lässt genau diesen Weg zu. Die Testmail kam an.

Für meinen Blog-Server habe ich später gleich weitergedacht. Das VPS-Backup meldet sich nach jedem Lauf aktiv bei Uptime Kuma. Bleibt die Meldung aus, kommt eine Mail. Das fängt auch den Fall ab, dass gar nichts passiert, nicht nur den, dass etwas schiefgeht.

Was ich daraus mitnehme

Ein Backup ohne Alarm ist ein Gerücht. Dass der Job eingerichtet ist, sagt nichts darüber, ob er läuft. Die Meldung muss dort ankommen, wo ich sie auch sehe.

Fehler kommen selten allein. Hätte ich nach dem ersten Fix aufgehört nachzusehen, wäre das Backup am nächsten Abend wieder gescheitert, nur mit einer anderen Meldung.

Handarbeit an Geräten mit eigener Oberfläche hält nicht. Wenn eine Weboberfläche die Konfiguration verwaltet, überschreibt sie früher oder später, was ich per SSH geändert habe. Entweder man baut einen Wächter, so wie ich, oder man lässt die Finger davon.

„No route to host“ heißt nicht immer Netzwerk. Manchmal ist am anderen Ende einfach niemand zu Hause.

Was als Nächstes kommt

Ganz zufrieden bin ich mit meinem Backup noch nicht:

• Der PBS läuft auf demselben Host, den er sichert. Fällt der Host aus, muss ich den PBS erst neu aufsetzen und den Datastore wieder einbinden, bevor ich irgendetwas zurückholen kann. Das will ich einmal durchspielen und aufschreiben.
• Es gibt keine Kopie außerhalb des NAS. Von 3-2-1 bin ich noch ein Stück entfernt, also drei Kopien auf zwei verschiedenen Medien, davon eine außer Haus.
• Proxmox meldet sich am PBS noch als root@pam an. Ein eigener Benutzer mit einem API-Token, der nur sichern darf, wäre sauberer.
• Und einen echten Restore-Test habe ich auch noch nicht gemacht. Ein Backup, das man nie zurückgespielt hat, ist im Grunde auch nur ein Gerücht.