[SOLVED] systemd mount mit Wechselmedien - PVE WebIF liefert keine Daten mehr

aL1aL7

aL1aL7

New Member
Proxmox Subscriber
Apr 4, 2024
12
1
3
Hallo Zusammen,

ich benötige wieder einmal einen Denkanstoß bzw. eine Erklärung für ein Verhalten.

Ausgangssituation:
- PVE-Cluster mit 3 Nodes
- auf Wechselmedien (USB-HDD) sollen wöchentlich Offline - Backups erstellt werden
- auf den PVE-Hosts gibt es ein Storage (Directory) für den Mountpunkt der USB-Platte
Code: 
dir: USB-BACKUP
    path /mnt/usb_backup
    content backup
    is_mountpoint 1
    mkdir 0
    prune-backups keep-all=1
    shared 0

Ziel:
- USB-HDD physisch anstöpseln -> die Platte soll automatisch gemountet werden
- auf dem jeweiligen Host, an dem die Platte steckt, das Backup über das WebIF manuell anstoßen

Dachte ich mir, kann ja nicht so schwer sein, udev Regel und fertig.
Ergebnis: Zu lange das mount Zeugs nicht mehr gebraucht um festzustellen, dass die "neueren" udevs einen eigenen Namespace verwenden und das Mounten so nicht mehr funktioniert.

Plan B: systemd automount

Einen Eintrag in der fstab erstellt und per Label mounten lassen.
Bash: 
LABEL=usb_backup /mnt/usb_backup auto noauto,nofail,x-systemd.automount 0 0
systemd reload
Bash: 
systemctl daemon-reload
systemctl restart local-fs.target

Funktioniert soweit, Platte anstecken wird automatisch gemountet und kann als Backup-Storage verwendet werden

ABER
Ist die Platte nicht angesteckt ist das Webinterface des PVE-Host nicht mehr brauchbar. VM-Namen verschwinden, es werden keine Daten mehr angezeigt nur "Loading"
Restart des pveproxy hilft hier nicht. Den pvedaemon habe ich nicht neu gestartet - wobei ich vermute dass der hier keine Daten mehr liefert.

Lösung
Änderung des fstab Eintrags und setzen eines Timeouts
Bash: 
LABEL=usb_backup /mnt/usb_backup auto noauto,nofail,x-systemd.automount,x-systemd.device-timeout=1 0 0

Nun zu meinen Fragen:
Warum hängt hier das PVE-System wenn kein Timeout gesetzt ist? Ist das so gewollt?
Was ist hier eigentlich ein sinniges Timeout?
 
Mutmaßlich ist pvestatd der Auslöser für das beobachtete Verhalten.
Wenn Du das Storage deaktivierst mit pvesm set USB-BACKUP --disable 1 sollte das nicht mehr passieren. Nachdem Anstecken des Gerätes kannst Du es aktivieren pvesm set USB-BACKUP --disable 0 und das Backup erstellen, danach wieder deaktivieren.
 
Danke für Deine Antwort, aber das wären zwei zusätzliche Schritte (nicht viel Arbeit, aber es ist halt Aufwand) - was würde den gegen den systemd automount mit dem device-timeout sprechen? Mit dieser Option funktioniert augenscheinlich alles wie es soll, ich bin mir nur nicht sicher, ob ich etwas übersehe.
 
Wie wird das Backup denn ausgelöst, Platte anstecken und dann via WebGUI? Könnte man sonst auch in ein shell script packen (Storage aktivieren, vzdump für Backup, Storage deaktivieren).

Für Dein Setup wird die Timeout-Lösung schon passen. Du hast ggf. ein paar mehr Logeinträge, weil der pvestatd alle paar Sekunden auf das Storage zugreifen will und das fehlschlägt.
 
  • Like
Reactions: Johannes S
Schön das dein Problem gelöst ist, aber ich stelle mir die Frage, warum tust du dir soetwas an?
Jetzt kommt wieder das Argument, haben wir immer so gemacht und brauchen die Backups offsite.

Diese Methode birgt das größte Problem nicht im PVE oder deinem Script, sondern der Faktor Mensch.
Wenn jemand Krank wird oder extremer Stress herrscht, wie wird sichergestellt, dass die HDDs nicht mal vergessen werden?
Glaube mir, da gab es in den letzten 20 Jahren noch keine 100% Methode.

Denk mal darüber nach, das eventuell etwas moderner und sicherer zu machen.
Automatisch funktioniert immer besser als manuell. Ich nutze lieber den PBS, (inkrementelle Backups sind deutlich schonender) und dann einen Offsite PBS.
Dieser Offsite PBS darf nur beim ersten PBS lesen und macht Pull Syncs. Damit das wirklich 100% Ransomware- und Klickadmin-Sicher ist wird die Firewall beim zweiten PBS eingehend 100% zu gemacht. Er holt ja alles per Pull ab. Auf diesem kannst du auch andere Retentions einstellen und Backups auch länger aufzubewahren. Bei den HDDs bist du was die Versionierung angeht ja stark limitiert.

Eventuell hat dir das geholfen, mal auf andere Gedanken zu kommen.
 
  • Like
Reactions: Johannes S and aL1aL7
Hi Falk R.

Danke für Deinen Input. Wie Du ja gestern schon mitbekommen hast sichere ich auch automatisiert mit PBS und Veeam.
Das Offline-Backup auf USB ist wirklich für den worst case (es liegt auch immer eine Kopie im Schließfach) und mein Ziel ist auch in naher Zukunft einen PBS extern in einem RZ zu betreiben, der die Backups von meinem lokalen PBS pulled (betreibe ich so auch schon an anderer Stelle). Bis ich aber soweit bin möchte ich auf diese Zwischenlösung mit der USB-Platte nicht verzichten.
 
  • Like
Reactions: Falk R.
also per udev sollte es auch gehen, ich synce z.B. per udev (anhand der Seriennummer der HDD) mehrer HDDs auf andere als backup per udev wird nen script gestartet, die hdd die verschlüsselt ist eingebunden und gemountet dann per rsync abgeglichen danach wieder ungemountet und crypt geschlossen dann ne Mail geschickt das alles fertig ist
 
Last edited:
Nun ja PBS unterstützt auch "removable datastores", darüber könntest du die USB-Medien einbinden. Soweit ich weiß, kann man das so konfigurieren, dass beim Anstecken darauf gesynct wird
 
  • Like
Reactions: aL1aL7
Das wäre auch eine Möglichkeit, aber dann müsste ich ja regelmäßig verify jobs drüber laufen lassen - ich weiß nicht ob mein Vertrauen in den PBS so groß ist es ohne die verify jobs. Die Performance dieser Jobs dürfte dann wahrscheinlich auch nicht der Renner sein (USB Platte)
 
aL1aL7 said:
Das wäre auch eine Möglichkeit, aber dann müsste ich ja regelmäßig verify jobs drüber laufen lassen - ich weiß nicht ob mein Vertrauen in den PBS so groß ist es ohne die verify jobs. Die Performance dieser Jobs dürfte dann wahrscheinlich auch nicht der Renner sein (USB Platte)
Click to expand...
Da verify ist ein nettes optionales Feature, was viele andere Backupsysteme gar nicht haben.
Ich vertraue dem PBS 10x mehr als vzDump auf ein NAS zu machen. Da kann viel mehr kaputt gehen.
Mit USB Disk habe ich auch schon schlechte Erfahrungen sammeln müssen, als ich gefragt wurde wie man davon etwas zurücksichern kann und die Daten alle Korrupt waren. Auch der Veeam Support konnte nicht nachvollziehen, warum auf allen HDDs die Daten korrupt waren.
Dann lieber eine vernünftige Software auf vernünftiger Hardware.
Egal ob Veeam oder PBS, auf internen Disks hatte ich noch nie richtige Fehler. Zumindest immer alles behebbar.
 
  • Like
Reactions: aL1aL7 and Johannes S
Hmm, ihr macht mich fertig :D

Mein Gedankengang bei dem PBS Backup mit Sync auf USB-Platte:
Da schlummern Chunks rum die irgendwann uralt werden und aufgrund der langen "Haltedauer" die Wahrscheinlichkeit von korrupten Datenblöcken größer wird. Deshalb meine Überlegung mit den vzdump auf USB-Platte ohne PBS, dann hätte ich ja sozusagen immer "frische" Daten da ich ja einen kpl. Dump bekomme und die alte Daten überschrieben bzw. gelöscht werden.

Aber ich glaube ihr habt mich überzeugt, ich versuche mal den Weg mit einem Sync des PBS-Backups auf einen Removable Storage (USB).

Danke für euren Input
 
Ganz ehrlich, ein frisches Backup rettet dich im Ernstfall auch nicht.
Ich habe das zum ersten Mal vor 20 Jahren erlebt wo jede Woche ein frisches Full auf Tape geschrieben wurde.
Leider waren die Quelldaten auf dem Server defekt gegangen was erst beim Reboot nach einem halben Jahr aufgefallen ist.
Alle 3 Monate Tapes hatten die gleichen korrupten Daten.
Zum Glück konnten wir damals die Daten von Hand reparieren, was heutzutage garantiert nicht mehr funktioniert.
Ein altes Backup kann einem unter Umständen den Arsch retten, aber viel besser ist es den Restore tatsächlich regelmäßig zu testen.
 
  • Like
Reactions: Johannes S
Ihr habt mich überzeugt - ich lass jetzt, bis ein weiterer externer PBS am Laufen ist, die Offline-Backups über einen Sync auf die USB-Platte schreiben und verabschiede mich von Image Dumps auf Platte.

Falk R. said:
Ich habe das zum ersten Mal vor 20 Jahren erlebt wo jede Woche ein frisches Full auf Tape geschrieben wurde.
Click to expand...
Das war aber nichts virtualisiertes oder?

Falk R. said:
Leider waren die Quelldaten auf dem Server defekt gegangen was erst beim Reboot nach einem halben Jahr aufgefallen ist.
Click to expand...
Da kümmert sich ja jetzt Microsoft drum, dass eine Maschine nicht mehr so lange am Stück läuft und alle 4 Wochen am Dienstag/Mittwoch rebooted wird :p
 
aL1aL7 said:
Ihr habt mich überzeugt - ich lass jetzt, bis ein weiterer externer PBS am Laufen ist, die Offline-Backups über einen Sync auf die USB-Platte schreiben und verabschiede mich von Image Dumps auf Platte.


Das war aber nichts virtualisiertes oder?
Click to expand...
Nein, wir wollten den Server virtualisieren und dafür erst einmal neustarten und aktuellsten SP installieren vor dem konvertieren.
Ist aber egal, da ein defektes Dateisystem immer mal auftreten kann.
aL1aL7 said:
Da kümmert sich ja jetzt Microsoft drum, dass eine Maschine nicht mehr so lange am Stück läuft und alle 4 Wochen am Dienstag/Mittwoch rebooted wird :p
Click to expand...
Bei Clients ja, aber Server sehe ich immer wieder mit Uptime 365Tage+.
 
You must log in or register to reply here.
Top Bottom
Back