[SOLVED] Backup VM Fehler / fehlende vzdump-quemu* Ordner

[CopperEng]

Hallo Dunuin,
auch mein TrueNAS wird regelmäßig upgegraded - da bin ich der Meinung, dass über die Updates auch Sicherheistlücken geschlossen werden ... aber das ist ein anderes Thema.
Ich habe natürlich auch mein TrueNAS im Verdacht. Aber da ich vom PVE (Konsole bzw. GUI) auf dem TrueNAS backup-Ordner anlegen und auch "beschreiben" kann (zumindest mit den Logfiles des Fehlerberichts), bin ich der Meinung hier kein Problem zu haben.

@fabian: Ja, ganz klar ein Workaround, das Problem ist noch nicht gefunden. Es kann ja auch sein, dass nach dem Neu-Aufsetzen das Problem immer noch besteht.

 

[CopperEng]

Hallo Zusammen!

Nachdem das Problem (erstmal) nicht gefunden wurde, habe ich PVE komplett neu aufgesetzt und die VMs wieder eingespielt. Bis hierher alles super.

Ich konnte die vorher (lokal) erstellten Backups direkt von meinem NAS per SMB-Storage einbinden und wieder herstellen.

Dann habe ich mit dem "neuen" PVE das Backup gestartet und das gleiche Problem wie vorher:

022-09-24 17:35:28 INFO: Starting Backup of VM 500 (qemu)
2022-09-24 17:35:28 INFO: status = running
2022-09-24 17:35:28 INFO: VM Name: embyServerUbuntu2004LTS
2022-09-24 17:35:28 INFO: include disk 'scsi0' 'local-lvm:vm-500-disk-0' 16G
2022-09-24 17:35:29 INFO: backup mode: snapshot
2022-09-24 17:35:29 INFO: ionice priority: 7
2022-09-24 17:35:29 ERROR: Backup of VM 500 failed - unable to open '/mnt/pve/smb_backup/dump/vzdump-qemu-500-2022_09_24-17_35_28.tmp/qemu-server.conf' at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 210.

Interessanterweise legt das PVE-Backup Script das logfile (siehe vorher) auf dem SMB-Storage (unter /dump) ab. Aber Backups können nicht geschrieben werden?

Mittlerweile bin ich der Meinung, dass mit irgendeinem der letzten Updates ein Bug eingeschleppt wurde. Das booten eines älteren Kernels brachte keine Lösung.

Gibt es irgendein weiteres Logfile, welches ich mir ansehen könnte? Was ist das für ein Script "QemuServer.pm"? Und was findet genau in Zeile 210 statt?

Ich vermute, dass weitere Nutzer dieses Problem haben müssen. Vielleicht wird das unter einem anderen Threat behandelt?

Viele Grüße

 

[Dunuin]

Gibt es irgendein weiteres Logfile, welches ich mir ansehen könnte? Was ist das für ein Script "QemuServer.pm"? Und was findet genau in Zeile 210 statt?

Laut Quelltext ist ab Zeile 210 (https://github.com/proxmox/qemu-server/blob/master/PVE/QemuServer.pm):

my $audio_fmt = {
    device => {
    type => 'string',
    enum => [qw(ich9-intel-hda intel-hda AC97)],
    description =>  "Configure an audio device."
    },
    driver =>  {
    type => 'string',
    enum => ['spice', 'none'],
    default => 'spice',
    optional => 1,
    description => "Driver backend for the audio device."
    },
};

 

[fabian]

Laut Quelltext ist ab Zeile 210 (https://github.com/proxmox/qemu-server/blob/master/PVE/QemuServer.pm):

my $audio_fmt = {
    device => {
    type => 'string',
    enum => [qw(ich9-intel-hda intel-hda AC97)],
    description =>  "Configure an audio device."
    },
    driver =>  {
    type => 'string',
    enum => ['spice', 'none'],
    default => 'spice',
    optional => 1,
    description => "Driver backend for the audio device."
    },
};

falsches file

https://git.proxmox.com/?p=qemu-ser...fbf951bc3fe2a0fcd03e6e96fbf7e801;hb=HEAD#l210

koenntes du mal folgendes skript (legt einen ordner "test" und ein file "test/file" am samba share an) ausfuehren?

perl -e 'use strict; use warnings; use File::Path qw(make_path); use IO::File; use Data::Dumper; my $base_path = "/mnt/pve/smb_backup/dump/"; print Dumper(make_path("${base_path}/test")), "\n"; my $file = IO::File->new(">${base_path}/test/file"); if (!$file) { print "ERR: $!\n"; } else { print "OK\n" };'

 

[CopperEng]

Hallo Zusammen,

habe das script ausgeführt und erhalte folgende Meldung:

ERR: Stale file handle

Aber: unter ../dump liegt jetzt ein Ordner "test" mit einem File mit 0 Byte Größe.


Viele Grüße

 

[fabian]

kannst du versuchen die "noserverino" mount option zu setzen (am PVE host, fuer den samba mount)?

 

[CopperEng]

Hi,
sorry ... was soll das sein? Kannst Du mir sagen, was zu tun ist?
Danke.

 

[fabian]

hast du den TrueNAS share ueber die PVE GUI als storage konfiguriert oder haendisch (z.b. mittels /etc/fstab?) kannst du den inhalt von /etc/pve/storage.cfg hier posten?

 

[CopperEng]

dir: local
path /var/lib/vz
content backup,iso,vztmpl

lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images

dir: backup_local
path /home
content backup
prune-backups keep-all=1
shared 0

dir: ro_backup_smb
path /media/backup
content backup
prune-backups keep-weekly=4
shared 0

cifs: smb_backup
path /mnt/pve/smb_backup
server trueNAS
share xxxxxx
content backup
prune-backups keep-all=1


Ich habe aktuelle 2 smb shares:

• "ro_backup_smb" habe ich haendisch über fstab angelegt. Von dort kann ich Backups zurückspielen, das funktioniert.
• "smb_backup" angelegt über das PVE GUI - von dort kann ich auch Backups zurückspielen

Viele Grüße

 

[CopperEng]

Mittlerweile habe ich gesehen, dass ich "noserverino" als Option in die fstab eintragen kann. Habe ich gemacht, danach mount -a

Und dann Dein script angepasst auf /media/backup/dump

Folgende Ausgabe:
$VAR1 = '/media/backup/dump//test';

ERR: Stale file handle


Viele Grüße

 

[fabian]

mount -a mounted nur dinge die noch nicht gemounted sind - du musst also umount /media/backup && mount -a machen (oder rebooten oder eine andere variante die sicherstellt dass die mountoption "greift")

 

[CopperEng]

Danke,
jetzt sieht es so aus:

$VAR1 = '/media/backup/dump//test';

OK


Was heißt das jetzt? Problem gefunden )

Viele Grüße

 

[CopperEng]

Hey .....

habe natürlich direkt mal haendisch das Backup gestartet ... es läuft !?
Was war das denn?

Kannst Du mir erklären was die Option "noserverino" zu tun hat? Und kann ich diese Option auch setzen, wenn ich das smb über das PVE GUI einrichte?

Viele Grüße

 

[CopperEng]

...

INFO: 65% (10.5 GiB of 16.0 GiB) in 36s, read: 193.3 MiB/s, write: 192.7 MiB/s
INFO: 69% (11.2 GiB of 16.0 GiB) in 39s, read: 242.9 MiB/s, write: 213.5 MiB/s
INFO: 73% (11.8 GiB of 16.0 GiB) in 42s, read: 201.8 MiB/s, write: 197.4 MiB/s
INFO: 77% (12.4 GiB of 16.0 GiB) in 45s, read: 211.5 MiB/s, write: 204.1 MiB/s
INFO: 80% (12.9 GiB of 16.0 GiB) in 48s, read: 160.7 MiB/s, write: 158.3 MiB/s
INFO: 84% (13.5 GiB of 16.0 GiB) in 51s, read: 233.2 MiB/s, write: 213.3 MiB/s
INFO: 89% (14.3 GiB of 16.0 GiB) in 54s, read: 240.5 MiB/s, write: 216.8 MiB/s
INFO: 92% (14.8 GiB of 16.0 GiB) in 57s, read: 201.8 MiB/s, write: 200.2 MiB/s
INFO: 96% (15.5 GiB of 16.0 GiB) in 1m, read: 226.0 MiB/s, write: 195.5 MiB/s
INFO: 99% (15.9 GiB of 16.0 GiB) in 1m 3s, read: 149.8 MiB/s, write: 149.3 MiB/s
INFO: 100% (16.0 GiB of 16.0 GiB) in 1m 4s, read: 57.0 MiB/s, write: 55.0 MiB/s
INFO: backup is sparse: 3.99 GiB (24%) total zero data
INFO: transferred 16.00 GiB in 64 seconds (256.0 MiB/s)
INFO: archive file size: 4.95GB
INFO: adding notes to backup
INFO: Finished Backup of VM 500 (00:01:04)
INFO: Backup finished at 2022-09-26 15:27:20
INFO: Backup job finished successfully
TASK OK

 

[fabian]

ja - dein NAS liefert kaputte inode werte, und je nachdem wie der zugriff auf die files passiert gibts probleme.

folgendes waere der workaround (zumindest solange bis PVE es bei CIFS/Samba erlaubt, beliebige optionen direkt zu setzen):
- /etc/fstab eintrag *mit* noserverino fuer den share anlegen, der sollte dann automatisch beim boot gemounted werden
- /etc/pve/storage.cfg anpassen (NAME und PFAD_AUS_FSTAB entsprechend ersetzen ):

dir: NAME
path PFAD_AUS_FSTAB
content backup
prune-backups keep-all=1
is_mountpoint 1

damit wird der via fstab gemountete samba share als directory storage fuer PVE konfiguriert - wichtig ist dabei das "is_mountpoint" das verhindert, dass PVE vor dem mounten schon etwas mit dem storage macht (z.b. directories anlegen die dann das mounten verhindern). falls du einen cluster hast kannst du den fstab eintrag auf allen nodes und in der storage.cfg "shared 1" hinzufuegen, falls nicht ist das nicht notwendig.

 

[CopperEng]

Hi Fabian,

vielen Dank für den Support und die Hilfestellungen. Warum trueNAS "kaputte inode Werte" liefert versuche ich noch zu klären.

Ansonsten könnten wir diesen Threat as "solved" setzen? Wie geht das??? Sorry, ich bin echt ein Anfänger

Viele Grüße

 

[CopperEng]

Hab´s gefunden ...

 

[holysoles]

Hallo zusammen, Englischsprecher hier, also entschuldigen Sie die Übersetzung.

Ich bin auf dieses Problem auch erst gestoßen, nachdem ich dieses Wochenende auf PVE 7 aktualisiert hatte. Das Hinzufügen der Option "noserverino“ hat meine Probleme behoben. Kann dies als bekanntes Problem für Samba zum Wiki hinzugefügt werden?

https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0

 

[CopperEng]

Hallo zusammen, Englischsprecher hier, also entschuldigen Sie die Übersetzung.

Ich bin auf dieses Problem auch erst gestoßen, nachdem ich dieses Wochenende auf PVE 7 aktualisiert hatte. Das Hinzufügen der Option "noserverino“ hat meine Probleme behoben. Kann dies als bekanntes Problem für Samba zum Wiki hinzugefügt werden?

https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0

Hi holysoles,

as you can see, I have solved the problem by inserting "noserverino" into my fstab file on the server.
fabian from Proxmox Team was delivering great support on this issue. But he told me, that my TrueNAS delivers wrong "inode values". I can´t believe that I am the only one facing these issues - and now I can see, that there are others as well.

Maybe you are right to suggest that this issue should be mentioned in the Wiki. Would have saved me a lot of time and panic ;-)

Regards

 

[RolandK]

anyhow, cifs mount options is in the works

https://bugzilla.proxmox.com/show_bug.cgi?id=2920
https://www.mail-archive.com/pve-devel@lists.proxmox.com/msg08657.html

the question is, if noserverino mount option would make sense to be added as a default. i'm not deep enough into the details to decide if this may break cifs mount for other users...