PVE / CIFS / Connection timed out (596) / communication failure (0)

[felon]

Hallo zusammen,

auf meinem PVE 7.3-3 nutze ich die Storagebox von Hetzner für Backups.
Leider bekomme ich beim anzeigen/auflisten der Backups über die GUI immer eine der beiden folgende Fehlermeldung:

Connection timed out (596)
communication failure (0)

Der Mountpoint wurde nicht über die GUI erstellt.
in der fstab habe ich den mountpoint mit folgenden Optionen eingestellt:
vers=3.0,seal,iocharset=utf8,rw,wsize=130048,credentials=/iwo/credsfile,uid=root,gid=root,file_mode=0660,dir_mode=0770 0 0

Im PVE habe ich den Mountpoint im Storage als "Directory" definiert.
Über die shell kann ich ohne Problem auf die Storagebox zugreifen. Über die GUI bekomme ich die Fehlermeldung.

Scheinbar tritt der Fehler auch nur auf, wenn sich eine gewisse Anzahl an Backups auf der Storagebox befinden.
Je weniger Files, desto eher klappt das Auflisten über die GUI.

Wenn jemand eine Vermutung/Tipp hat woran das liegen könnte, wäre ich sehr dankbar

PS:
Könnten mir folgende Optionen für den Mountpoint etwas bringen?
relatime
cache=none

Beste Grüße
Ralph

 

[mars-vie]

Hallo,

hier dasselbe Problem - hatte die StorageBox via CIFS als IP in der storage.cfg drinnen.

Allerdings über die GUI angelegt.

Hetzner hat dann wohl in der Nacht die IP gewechselt. Backups sind dann natürlich fehlgeschlagen (TASK ERROR: could not activate storage 'XXX': storage 'XXX' is not online).

Habe dann auf xxxx.your-storagebox.de geändert, macht aber keinen Unterschied.

Das Auflisten der Backups von der Hetzner StorageBox funktioniert (ca. 30+), aber beim Backup bekomme ich timeout Fehler - syslog schreibt:

got timeout
CIFS VFS: Close unmatched open
unable to activate storage 'XXX' - directory '/mnt/pve/XXX' does not exist or is unreachable


Das Backup lässt sich dann auch nicht mehr stoppen, egal ob man den Prozess killt, die Storage entfernt, unmountet, etc.
Die VM, welche gerade gebackupt wird, fährt auch nicht mehr korrekt runter.
Muss dann den ganzen Node neu starten, was sehr lange dauert, weil wahrscheinlich irgendein Prozess hängt und aufs timeout wartet (habe leider keine iLO, VNC Mögkichkeit zu diesen Server).

Keine Ahnung, was da bei Hetzner jetzt anders ist?
Bis dato sind die Backups immer perfekt gelaufen.


Getestet auf 2 Servern PVE 7.3-6 + PVE 6.4-15, beide in Serverzentren, gute Anbindung

 

[mars-vie]

Hallo,
heute funktioniert wieder alles -
der Support hat nicht wirklich hilfreich geantwortet sondern lapidar die Frage gestellt, ob ich "schon einen unmount - mount Ihrer Storage Box probiert" habe.
Egal, offensichtlich ein temporäres Problem bei Hetzner.
Leider als Backup-Storage nicht 100% zuverlässig - man braucht also noch eine 2te Backup-Strategie

 

[felon]

Hallo zusammen,

mein Problem liegt da eher nur in der GUI.
Backups. etc laufen durch.

Weiß jemand einen Rat woran es liegt, dass oben genannte Fehlermeldungen generiert werden?

Beste Grüße
Ralph

 

[fweber]

Hi, vielleicht läuft die GUI dann doch in ein Timeout, möglicherweise wegen einer zu langsamen Anbindung? Wieviele Files liegen denn im dump/-Verzeichnis auf dem Share (rauszufinden z.B. mit ls -1 /pfad/zum/share/dump | wc -l)? Liegen dort auch noch andere Files als Backups? Listet die CLI mit pvesm list <sharename> -content backup die Files in annehmbarer Zeit auf?

 

[felon]

Hallo Friedrich,

danke für Deine Schützenhilfe

es sind 720 files.
LS: listet extrem schnell. Dauert nicht mal eine Sekunde (Enter, und fertig)

pvesm list:
Start: Wed 01 Mar 2023 03:27:58 PM CET
Ende: Wed 01 Mar 2023 03:28:38 PM CET
also 00:01:01 deutlich länger.

Lass mich raten, der Timeout liegt bei 1 Minute?

Was könnte ich am besten machen?

Schöne Grüße
Ralph

 

[fweber]

Hallo Ralph,

danke fürs Nachschauen!

pvesm list:
Start: Wed 01 Mar 2023 03:27:58 PM CET
Ende: Wed 01 Mar 2023 03:28:38 PM CET
also 00:01:01 deutlich länger.

Lass mich raten, der Timeout liegt bei 1 Minute?

Hm, wenn ich richtig sehe, setzt PVE selbst an der Stelle garkein Timeout. Kommt denn dann die Liste der Backups komplett an, oder gibts einen Fehler?

Unglaublich viele Files sind 720 ja nicht -- wenn ich richtig rechne, sollten das 240 Backups sein?

Eine gewisse Diskrepanz zwischen den Laufzeiten von ls und pvesm list ist zu erwarten, weil PVE einiges mehr macht als nur die Files auflisten -- z.B. liest es jedes einzelne *.notes-File ein. Über 1min scheint mir aber für 240 Backups doch etwas viel.

Könntest du deine kompletten mount-Options für den Share posten, mit mount | grep cifs? Welchen Kernel nutzt du (rauszufinden mit pveversion)?

Verstehe ich richtig, dass nur das Auflisten von Backups langsam ist, ist also das Anlegen von Backups einigermaßen schnell?

 

[felon]

Hallo Friedrich,

danke, dass Du dir die Zeit nimmst.
Damit ich auch zum späteren Zeitpunkt Veränderungen and der fstab vornehmen/testen kann, wechsle ich den Server auf dem ich arbeite bzw. von dem ich gerade schreibe.
Ich mach das jetzt auf meinem Test-System weiter.
Das Test-System hat genau die selbe Herausforderung.
Auch die Zeiten beim listen sind sehr ähnlich.
Dort macht es auch nichts, wenn ich ungeplante Neustarts durchführen muss.

Kurzes Update zu den vorherigen Daten

Getestet vom Testsystem aus:

Auflisten Backup1 (server zu begin) über pvesm list:
Wed 01 Mar 2023 08:41:14 PM CET
Wed 01 Mar 2023 08:42:21 PM CET
Auflisten Backup2 (testserver backups) über LS mit wc:
720

Auflisten Backup2 (testserver backups) über pvesm list:
Wed 01 Mar 2023 08:26:25 PM CET
Wed 01 Mar 2023 08:26:55 PM CET
Auflisten Backup2 (server zu begin) über LS mit wc:
540

ich komme bei der Anzahl der Backups auf:
720 / 2 = 360
540 / 2 = 270

immer Backup+logfile. Hab zur Sicherheit die Anzahl gecheckt, die pvesm list ausgespuckt hat.

Output von "pveversion":
pve-manager/7.3-6/723bb6ec (running kernel: 5.15.74-1-pve)

Output von "mount | grep cifs":
//usenummer.your-storagebox.de/backup /mnt/storagebox cifs vers=3.0,seal,relatime,cache=none,iocharset=utf8,rw,wsize=130048,credentials=/creds/backupcreds,uid=root,gid=root,file_mode=0660,dir_mode=0770 0 0

Anlegen der Backups:
das Anlegen selbst geht recht zügig.
Auch die Backupjobs laufen super durch.
Backups habe ich auch getestet ob es dort evtl auch Probleme gibt. Aber super, dass es nicht so ist
ps: ich habe es auch schon ohne die Parameter "cache=none", "relatime", und "seal" versucht. Die eben genannten Parameter habe ich zum Testen genutzt, um zu sehen, ob sich dadurch die Situation verbessert.

Danke für Deine Geduld

Schöne Grüße
Ralph

 

[KxmischerLasse]

Moin,
Seit den gestrigen Wartungsarbeiten an den Helsinki Storageboxen bekomme ich folgenden Fehler wenn ich ein Backup erstellen möchte:

INFO: starting new backup job: vzdump 115 --mode snapshot --remove 0 --node fynncraft-dedi --notes-template '{{guestname}}' --storage Hetzner-StorageBox-1 --compress zstd
INFO: Starting Backup of VM 115 (qemu)
INFO: Backup started at 2023-03-02 07:49:17
INFO: status = running
INFO: VM Name: VM-Grafana-01
INFO: include disk 'scsi0' 'local:115/vm-115-disk-0.raw' 9420M
INFO: backup mode: snapshot
INFO: ionice priority: 7
ERROR: Backup of VM 115 failed - unable to open '/mnt/pve/Hetzner-StorageBox-1/dump/vzdump-qemu-115-2023_03_02-07_49_17.tmp/qemu-server.conf' at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 211.
INFO: Failed at 2023-03-02 07:49:18
INFO: Backup job finished with errors
TASK ERROR: job errors


Weiß jemand woran das liegen könnte?

 

[fweber]

Hi,

Seit den gestrigen Wartungsarbeiten an den Helsinki Storageboxen bekomme ich folgenden Fehler wenn ich ein Backup erstellen möchte:

Das schaut nach einem anderen Problem aus, möglicherweise diesem hier. Falls die verlinkte Lösung nicht funktioniert, könntest du bitte einen neuen Thread zum Thema aufmachen?

immer Backup+logfile. Hab zur Sicherheit die Anzahl gecheckt, die pvesm list ausgespuckt hat.

Danke fürs Checken. Verstehe ich also richtig, dass es keine "*.notes"-Files gibt (d.h. ls *.notes gibt nichts zurück)? Dann würde das Auslesen der *.notes-Files als Grund für die Diskrepanz zwischen ls und pvesm list ja schon mal wegfallen.

Output von "pveversion":
pve-manager/7.3-6/723bb6ec (running kernel: 5.15.74-1-pve)

Output von "mount | grep cifs":
//usenummer.your-storagebox.de/backup /mnt/storagebox cifs vers=3.0,seal,relatime,cache=none,iocharset=utf8,rw,wsize=130048,credentials=/creds/backupcreds,uid=root,gid=root,file_mode=0660,dir_mode=0770 0 0

Kannst du bitte nochmal checken, dass das die Ausgabe von mount ist? Das schaut eher wie /etc/fstab aus -- bei mount würden hoffentlich noch ein paar andere Mount-Optionen mitkommen, z.B. actimeo (siehe unten).

Anlegen der Backups:
das Anlegen selbst geht recht zügig.
Auch die Backupjobs laufen super durch.
Backups habe ich auch getestet ob es dort evtl auch Probleme gibt. Aber super, dass es nicht so ist

Gut zu hören, dass Backups schnell gehen!

Könntest du nochmal nachprüfen, wie lange ein ls -al im dump-Verzeichnis dauert (z.B. mit time ls -al)? Das fordert etwas mehr Informationen vom SMB-Server an als ein einfaches ls.

Wenn du sowieso auf einem Testsystem arbeitest, könntest du folgendes probieren:

• Die Mount-Option actimeo setzt die Zeitspanne, für die Dateiattribute lokal gecached werden und ist per default 1 (Sekunde), siehe hier. DIe könntest du mal raufsetzen, z.B. auf 60, und schauen ob pvesm list schneller geht. Das hat halt den Effekt, dass Attributänderungen durch andere SMB-Clients (oder auf dem Server) länger unerkannt bleiben -- das müsstest du dann entscheiden, ob das für dich ok ist
• Ein Kernel-Update auf 6.1 könntest du auch versuchen. Es gab da offenbar ein paar Änderungen bei CIFS, vielleicht bringt es ja was.

 

[KxmischerLasse]

@fweber Ich habe mal einen neuen Thread aufgemacht (https://forum.proxmox.com/threads/proxmox-backup-problem.123560/). Weil in dem Thread welchen du gesendet hast geht es um Zeile 210. Bei mir gehts aber um Zeile 211.

 

[felon]

Hallo Friedrich,

wegen "mount|grep cifs" hast Du vollkommen recht.
Hab aus der falschen shell kopiert. War wohl schon zu spät gestern.

Hier der richtige Output von "mount | grep cifs":
//usenummer.your-storagebox.de/backup on /mnt/storagebox type cifs (rw,relatime,vers=3.0,cache=strict,username=usenummer,domain=usenummer.your-storagebox.de,uid=0,noforceuid,gid=0,noforcegid,addr=167.235.xxx.xxx,file_mode=0660,dir_mode=0770,iocharset=utf8,seal,soft,nounix,serverino,mapposix,rsize=4194304,wsize=130048,bsize=1048576,echo_interval=60,actimeo=1)

Output von "ls *.notes":
keine notes files gefunden auf der Storagebox im dump Verzeichnis. Wofür sind die? Wie es der name vermuten lässt, evtl. Eintragungen bei den VM/CT in der Beschreibung?

Geschwindigkeit der Backups:
Naja, für mich schnelle genug
Aber hier ein paar Werte. Entnommen aus der E-Mail die ich bekomme nach vollendetem Backup-Job.
Vielleicht kannst Du mir sagen, ob das so gut aussieht?
Backup1:

01:06:08

120.34GB

Backup2:

02:14:27

160.67GB

Output von "time ls -al":
Backup1:
ls --color=tty -al /mnt/storagebox/backup1/dump 0.00s user 0.01s system 1% cpu 0.365 total
Backup2:
ls --color=tty -al /mnt/storagebox/backup2/dump 0.00s user 0.01s system 2% cpu 0.376 total

Mount Option & Kernel Upgrade:
das kann ich am Freitag oder Samstag versuchen.
Danke für den Tipp. Sobald ich das probiert habe, gebe ich Feedback.

Eine Frage zum Kernel Upgrade:
ich habe noch kein Kernel Upgrade selbst durchgeführt.
Gibt es etwas ganz besonderes dabei zu beachten bzw. Stolpersteine?
Ich frage nur wegen Themen wie ZFS und legacy boot.
Einer der Server hatte ein Problem sich mit UEFI anzufreunden.

Beste Grüße
Ralph

 

[pxx]

Hetzner hat das Problem gefixt.

Eine grundsätzliche Frage zu den Backups, die ihr per cifs auf die Hetzner Storage Box macht:
Werden die Daten unverschlüsselt über eine unverschlüsselte Leitung gesendet?

 

[Falk R.]

Bei SMB 3 kann man Verschlüsseln, muss man nur machen.
Die Backups kannst du ja auch verschlüsseln.

 

[pxx]

Bei SMB 3 kann man Verschlüsseln, muss man nur machen.
Die Backups kannst du ja auch verschlüsseln.

Danke, SMB 3.0/3.11 mit seal verschlüsseln die Übertragung.
Aber stimmt das: "Encrypted backups are only supported when running a Proxmox Backup Server"?

 

[Falk R.]

einige packen das hinter einen PBS, sonst kannst du auch manuell verschlüsseln vor der Übertragung. Dann hast du nur kein direktes Backup.

 

[pxx]

einige packen das hinter einen PBS, sonst kannst du auch manuell verschlüsseln vor der Übertragung. Dann hast du nur kein direktes Backup.

Danke.
Hinter eine PBS ist interessant, wenn das klappt trotz der vielen I/O Zugriffe. Das werde ich mal ausprobieren.

 

[Falk R.]

Erwarte aber nicht zu viel.