Nach Update von PBS kein Zugriff mehr auf Datastore

[MarkusScheuch]

Guten Morgen

ich habe gestern ein Update des PBS auf proxmox-backup-server 3.0.4-1 running version: 3.0.4 gemacht.
Auf einem NAS liegt ein ISCSI Target, auf dem NAS sehe ich auch den Status verbunden mit dem PBS.

Am PBS selbst steht in der GUI in der Übersicht "Datastore ist nicht verfügbar"
Unter Inhalt steht die Fehlermeldung "Bad Request(400) unable to open chunk stoe VMBackups at "/VMBackups/.chunks" - No such file or directory (os error 2)
Der Ordner VMBackups ist auch wirklich leer.

Ein zfs list bringt die Meldung "no datasets availabe"

 

[Chris]

Guten Morgen

ich habe gestern ein Update des PBS auf proxmox-backup-server 3.0.4-1 running version: 3.0.4 gemacht.
Auf einem NAS liegt ein ISCSI Target, auf dem NAS sehe ich auch den Status verbunden mit dem PBS.

Am PBS selbst steht in der GUI in der Übersicht "Datastore ist nicht verfügbar"
Unter Inhalt steht die Fehlermeldung "Bad Request(400) unable to open chunk stoe VMBackups at "/VMBackups/.chunks" - No such file or directory (os error 2)
Der Ordner VMBackups ist auch wirklich leer.

Ein zfs list bringt die Meldung "no datasets availabe"

Hallo,
die Fehlermeldung deutet darauf hin, dass der datastore nicht gefunden wird, vermutlich weil dieser nicht gemounted wurde? Wurde der datastore auf einem ZFS storage eingerichtet oder via iSCSI target? Eventuell liefert das systemd journal einen Hinweis was schiefläuft? journalctl -b -r liefert das journal seit dem letzten boot in umgekehrter Reihenfolge.

 

[MarkusScheuch]

Kann es sein, dass es vlt. damit zu tun hat?

Auf dem NAS ist für die Festplatten ein RAID eingerichtet, darauf habe ich eine ISCSI LUNN/Target erzeugt, dies ist mit dem PBS verbunden, darauf ist dann ein ZFS Pool/Datastore erstellt.

 

[MarkusScheuch]

Hallo,
die Fehlermeldung deutet darauf hin, dass der datastore nicht gefunden wird, vermutlich weil dieser nicht gemounted wurde? Wurde der datastore auf einem ZFS storage eingerichtet oder via iSCSI target? Eventuell liefert das systemd journal einen Hinweis was schiefläuft? journalctl -b -r liefert das journal seit dem letzten boot in umgekehrter Reihenfolge.

- 400 Bad Request: [client [::ffff:10.6.11.74]:31079] unable to open chunk store 'VMBackups' at "/VMBackups/.chunks" - No such file or directory (os error 2)


Diese Meldung wiederholt sich mehr sehe ich hier nicht.

 

[Chris]

Kann es sein, dass es vlt. damit zu tun hat?

Auf dem NAS ist für die Festplatten ein RAID eingerichtet, darauf habe ich eine ISCSI LUNN/Target erzeugt, dies ist mit dem PBS verbunden, darauf ist dann ein ZFS Pool/Datastore erstellt.

Ja es hat sicher damit zu tun, dass das iSCSI target nicht richtig verbunden ist, wenn ZFS dies ebenfalls nicht sieht. Was sagt ein zpool status?

 

[MarkusScheuch]

Ja es hat sicher damit zu tun, dass das iSCSI target nicht richtig verbunden ist, wenn ZFS dies ebenfalls nicht sieht. Was sagt ein zpool status?

Aber es ist kein Problem dass auf dem NAS ein Raid eingerichtet ist oder?Habe gelesen, dass ZFS nicht funktioniert wenn ein Hardware Raid gesetzt ist?
Als Meldung von zpool status kommt "no pools available"

 

[Chris]

Na ja, ideal ist so ein setup sicher nicht. ZFS braucht am besten direkten zugriff auf lokale Platten, ohne Hardware Raid Controller und das Netzwerk dazwischen hilft auch nicht wirklich. Aber mal davon abgeshen, wenn das pool noch nicht mal importiert wurden, dann ist sicher was mit der verbindung zum iSCSI target. Listet ein zfs import ein pool, wenn openiscsi verwendet wurde, dann sollte auch systemctl status open-iscsi.service eventuell mehr infos liefern.

 

[MarkusScheuch]

Na ja, ideal ist so ein setup sicher nicht. ZFS braucht am besten direkten zugriff auf lokale Platten, ohne Hardware Raid Controller und das Netzwerk dazwischen hilft auch nicht wirklich. Aber mal davon abgeshen, wenn das pool noch nicht mal importiert wurden, dann ist sicher was mit der verbindung zum iSCSI target. Listet ein zfs import ein pool, wenn openiscsi verwendet wurde, dann sollte auch systemctl status open-iscsi.service eventuell mehr infos liefern.

Die Ausgabe von systemctl status open-iscsi.service:

● open-iscsi.service - Login to default iSCSI targets
Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; preset: enabled)
Active: active (exited) since Thu 2023-10-26 07:48:12 CEST; 1h 4min ago
Docs: man:iscsiadm(8)
man:iscsid(8)
Process: 1080 ExecStart=/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=0/SUCCESS)
Process: 1388 ExecStart=/lib/open-iscsi/activate-storage.sh (code=exited, status=0/SUCCESS)
Main PID: 1388 (code=exited, status=0/SUCCESS)
CPU: 10ms

Oct 26 07:48:10 proxbackup50 systemd[1]: Starting open-iscsi.service - Login to default iSCSI targets...
Oct 26 07:48:12 proxbackup50 iscsiadm[1080]: Logging in to [iface: default, target: iqn.2004-04.com.nas:q802:iscsi.proxbackup.df9518, portal: 10.6.14.5,3260]
Oct 26 07:48:12 proxbackup50 iscsiadm[1080]: Login to [iface: default, target: iqn.2004-04.com.nas:q802:iscsi.proxbackup.df9518, portal: 10.6.14.5,3260] successful.
Oct 26 07:48:12 proxbackup50 systemd[1]: Finished open-iscsi.service - Login to default iSCSI targets.

 

[MarkusScheuch]

Na ja, ideal ist so ein setup sicher nicht. ZFS braucht am besten direkten zugriff auf lokale Platten, ohne Hardware Raid Controller und das Netzwerk dazwischen hilft auch nicht wirklich. Aber mal davon abgeshen, wenn das pool noch nicht mal importiert wurden, dann ist sicher was mit der verbindung zum iSCSI target. Listet ein zfs import ein pool, wenn openiscsi verwendet wurde, dann sollte auch systemctl status open-iscsi.service eventuell mehr infos liefern.

Wäre es denn besser, nur ein JBOD zu machen und darauf dann eine LUN zu setzen und dies dann mit einem ZFS Pool auszustatten? Für Backups zu machen, reicht mehr die Geschwindigkeit mit dem externen NAS eigentlich.

 

[MarkusScheuch]

Habe mal zum test ein neues ISCSI Ziel verbunden, nach jedem Neustart des PBs ist das Problem das gleiche.
400 Bad Request: [client [::ffff:10.6.11.74]:31079] unable to open chunk store 'VMBackups' at "/VMBackups/.chunks" - No such file or directory (os error 2)
Der Ordner ist auch komplett leer, der .chunks .lock ist weg.
Zum Vergleich ein NFS Share auf dem identischen NAS, bleibt verbunden.

 

[Falk R.]

Solange deine iSCSI Disk nicht sauber verbunden ist, ist der Ordner immer leer.
Deine iSCSI Disk muss unter Disks sauber auftauchen. Alles andere kommt später.