[SOLVED] Backup laden schlägt fehl

user58292

New Member
May 9, 2019
11
0
1
34
Hallo,
ich musste vor ein paar Tagen meinen Server wegen einer RAID Umstellung einmal neu installieren und habe mich dazu entschieden über Proxmox Backups anzulegen diese auf einen Zwischenserver zu speichern, den alten Server wieder mit Proxmox zu bespielen und dann die Backups wieder drauf zu laden.
Ich bin jetzt soweit, dass ich meine Backups wieder zurück auf den neu installieren Server spielen wollte, unglücklicherweise tritt beim Zurückspielen/migrieren ein Fehler auf mit dem ich nichts anfangen kann:

Code:
restore vma archive: lzop -d -c /var/lib/vz/dump/vzdump-qemu-101-2019_05_08-03_40_08.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp16768.fifo - /var/tmp/vzdumptmp16768
CFG: size: 347 name: qemu-server.conf
DEV: dev_id=1 size: 536870912000 devname: drive-scsi0
CTIME: Wed May  8 03:40:16 2019
no lock found trying to remove 'create'  lock
TASK ERROR: command 'set -o pipefail && lzop -d -c /var/lib/vz/dump/vzdump-qemu-101-2019_05_08-03_40_08.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp16768.fifo - /var/tmp/vzdumptmp16768' failed: command '/usr/bin/qemu-img create -o 'preallocation=metadata' -f qcow2 /var/lib/vz/images/101/vm-101-disk-0.qcow2 524288000K' failed: got timeout
Ich habe dann natürlich direkt versucht die Backups auf dem Proxmox-Zwischenserver testweise zu migrieren was dann komischerweise auch direkt wunderbar funktionierte.

Die Integrität der Dateien auf dem Zielserver ist perfekt und auch Updates wurden mit apt update, upgrade, dist-upgrade geladen.

Auch nach einer weiteren Neuinstallation des Zielsystems blieb der Fehler bestehen.

pveversion -v Ausgabe:

Code:
proxmox-ve: 5.4-1 (running kernel: 4.15.18-14-pve)
pve-manager: 5.4-5 (running version: 5.4-5/c6fdb264)
pve-kernel-4.15: 5.4-2
pve-kernel-4.15.18-14-pve: 4.15.18-38
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: not correctly installed
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-9
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-51
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-42
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-26
pve-cluster: 5.0-37
pve-container: 2.0-37
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-20
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-51
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
 
Last edited:

JoeB

New Member
May 7, 2019
11
3
3
49
hier ist der Fehler beschrieben:
failed: command '/usr/bin/qemu-img create -o 'preallocation=metadata' -f qcow2 /var/lib/vz/images/101/vm-101-disk-0.qcow2 524288000K'

gib den befehl doch mal direkt in die Konsole ein - :) müsste eigentlich Fehlermeldung: "Could not create file: No such file or directory' erscheinen.

Evtl. hattest Du auf dem alten Server lvm oder zfs benutz, bei dem jetzigen aber (noch) nicht.
Jedenfalls ist wohl der Pfad (Diskzuordnung) zu VM101 noch nicht angelegt.
 
  • Like
Reactions: user58292

user58292

New Member
May 9, 2019
11
0
1
34
Das spuckt er mir dazu aus:
Code:
-bash: /usr/bin/qemu-img create -o preallocation=metadata -f qcow2 /var/lib/vz/images/101/vm-101-disk-0.qcow2 524288000K: No such file or directory
 

JoeB

New Member
May 7, 2019
11
3
3
49
ist das Verzeichnis den wenigstens vorhanden ?
von der webgui aus liest das restore programm die <VMID>.conf datei aus und bestimmt, wo das img erstellt werden soll.
man kann das backup aber auch von der Konsole aus einspielen.
bsp.
qmrestore <vzdump-qemu-122-2016_09_13-14_12_32.vma> <VMID>

(( man qmrestore

qmrestore help
qmrestore <archive> <vmid> [OPTIONS]
Restore QemuServer vzdump backups.
<archive>: <string>
The backup file. You can pass - to read from standard input.
<vmid>: <integer> (1 - N)
The (unique) ID of the VM.
--bwlimit <number> (0 - N)
Override i/o bandwidth limit (in KiB/s).
--force <boolean>
Allow to overwrite existing VM.
--pool <string>
Add the VM to the specified pool.
--storage <string>
Default storage.
--unique <boolean>
Assign a unique random ethernet address.
))

qmrestore <vzdump-qemu-122-2016_09_13-14_12_32.vma> <VMID> --storage /var/lib/vz/images

wird in /var/lib/vz/images die VM wieder angelegt.

Wahrscheinlich ist das aber nicht das gewünschte ziel.

mußt du anpassen.

Evtl. aber noch einmal in PVE Webgui prüfen, welche Platte / Verzeichnis / LVM / ZFs etc. für "images / CT " zur Verfügung gestellt wurde.
 
  • Like
Reactions: user58292

user58292

New Member
May 9, 2019
11
0
1
34
Wenn ich den Befehl qmrestore vzdump-qemu-102-2019_05_08-12_11_44.vma.lzo 102 --storage /var/lib/vz/images/ ausführe gibt es mir das hier aus:
Code:
qmrestore vzdump-qemu-102-2019_05_08-12_11_44.vma.lzo 102 --storage /var/lib/vz/images/
400 Parameter verification failed.
storage: invalid format - storage ID '/var/lib/vz/images/' contains illegal characters

qmrestore <archive> <vmid> [OPTIONS]
Grundsätzlich ist das Ziel aber richtig auch vorher waren meine VMs in diesem Verzeichnis.

Ich habe unter Datacenter -> Storage -> local -> /var/lib/vz als Verzeichnis (ich habe da nichts dran geändert seit der Installation außer es als Backup Verzeichnis hinzuzufügen).
Das Unterverzeichnis images ist auch vorhanden ich kann schließlich auch neue VMs erstellen aber meine Backups halt nicht laden.
 

user58292

New Member
May 9, 2019
11
0
1
34
Ich habe local nochmal deaktiviert und wieder reaktiviert und dann --storage local verwendet damit hat es jetzt funktioniert. Vielen Dank!
 

user58292

New Member
May 9, 2019
11
0
1
34
Ich habe jetzt noch die letzten VMs wiederherstellen wollen und leider tritt der Fehler wieder auf:


Code:
restore vma archive: vma extract -v -r /var/tmp/vzdumptmp17710.fifo /var/lib/vz/dump/vzdump-qemu-100-2019_05_06-13_44_02.vma /var/tmp/vzdumptmp17710
CFG: size: 345 name: qemu-server.conf
DEV: dev_id=1 size: 9895604649984 devname: drive-scsi0
CTIME: Mon May  6 13:44:05 2019
no lock found trying to remove 'create'  lock

TASK ERROR: command 'set -o pipefail && vma extract -v -r /var/tmp/vzdumptmp17710.fifo /var/lib/vz/dump/vzdump-qemu-100-2019_05_06-13_44_02.vma /var/tmp/vzdumptmp17710' failed: command '/usr/bin/qemu-img create -o 'preallocation=metadata' -f qcow2 /var/lib/vz/images/100/vm-100-disk-0.qcow2 9663676416K' failed: got timeout
Hat noch jemand Vorschläge was ich mal austesten könnte?
 
Last edited:

user58292

New Member
May 9, 2019
11
0
1
34
Nachtrag:
Ich habe versucht den Befehl:

Code:
/usr/bin/qemu-img create -o 'preallocation=metadata' -f qcow2 /var/lib/vz/images/100/vm-100-disk-0.qcow2 9663676416K
manuell einzugeben und dabei gibt er mir dies hier aus:

Code:
qemu-img: /var/lib/vz/images/100/vm-100-disk-0.qcow2: Could not create file: No such file or directory
 

Leon Gaultier

Member
Mar 14, 2019
173
7
18
41
Dann schau doch mal ob es den Path
/var/lib/vz/images/100/
überhaupt gibt. wenn nicht musst ihn an legen
 

user58292

New Member
May 9, 2019
11
0
1
34
Den Path /var/lib/vz/images/100/ gibt es nicht. Ich habe gerade einfach mal bevor ich das Backup geladen habe das Verzeichnis erstellt leider kommt nach ~15 Minuten der selbe Fehler "TASK ERROR: command 'set -o pipefail && vma extract..." (s. oben).
Wenn ich das Verzeichnis erstelle und manuell den Befehl den ich im letzten Nachtrag geschickt habe ausführe wird ein Volume erstellt. Viel bringen tut es mir aber nichts weil meine Daten dann ja noch nicht da drin sind ^^.
 

user58292

New Member
May 9, 2019
11
0
1
34
Mir ist gerade aufgefallen, dass nachdem ich den Befehl:
Code:
qmrestore vzdump-qemu-100-2019_05_06-13_44_02.vma 100 --storage local
ausgeführt habe tatsächlich der Ordner /var/lib/vz/imasges/100 erstellt wird und dort eine Datei drin liegt mit dem Namen vm-100-disk-0.qcow2 die langsam größer wird. Nach 10 Minuten war die Datei ungefähr 500MB groß also läuft das Backup eventuell sogar? Vielleicht ist das Backup zu groß (5TB)? Nach ungefähr 15 erscheint wieder der alte Fehler "TASK ERROR: command 'set -o pipefail && vma extract..." (s. oben) und das Verzeichnis samt Datei ist gelöscht.
 

Leon Gaultier

Member
Mar 14, 2019
173
7
18
41
Wie viel Platz hast Du denn? Wo lag eigentlich die Maschine vorher? lvm-local?

Wenn ich bei mir schaue dann ist bei mir /var/lib/vz local und somit in der eigentlichen Debian Struktur. Aber das kann ich Dir nicht genau sagen ob das ein Problem ist. Ich selbst verwende CEPH als Speicher für die VM's.
Aber 5 TB ist schon ne Hausnummer.
 

user58292

New Member
May 9, 2019
11
0
1
34
Insgesamt hat der Server 18TB durch einen Software RAID5 mit 4x6TB Platten und die VMs lagen vorher auf der selben Maschine nur auf einem 12TB Software RAID10. Die VMs lagen vorher im selben local Verzeichnis /var/lib/vz. Komisch finde ich, dass es jetzt möglich war meine anderen VMs zu migrieren die den selben Fehler beim migrieren hatten (s. oben). Dieses anderen VMs waren aber auch deutlich kleiner zwischen 9GB bis 500GB. Ich muss nur langsam den 5TB Server migrieren am Montag sollte der Server laufen sonst bekomme ich ärger ^^.
 

Leon Gaultier

Member
Mar 14, 2019
173
7
18
41
Ansonsten bevor wir hier weiter raten. Wende Dich doch an den Support. Die können Dir da auch direkt helfen.
 

JoeB

New Member
May 7, 2019
11
3
3
49
Hallo,
wie kommst du drauf, dass noch 10+TB frei sind ?
( Kannst du mal den konsole Befehl mit Ausgabe hier posten ? )
Mit welchem Dateisystem / Filsystem ist /var/lib/vz aufgesetzt ( LVM, ZFS etc. ) ?
( welcher mount wird verwendet ? )

Wie groß ist /tmp system - wie groß ist Swap ? Wieviel RAM ?

Kleiner Tip noch:
<Paramater> ist nicht wörtlich in einem Konsolenbefehl zu übernehmen, es ist ein Platzhalter für eigene "richtige" Werte.
 

user58292

New Member
May 9, 2019
11
0
1
34
So ich habe das Problem jetzt gelöst. Ich bin einfach dieser Anleitung gefolgt: https://blog.nasourso.com/proxmox/fixing-a-failing-backup-restore-job
Ich weiß noch nicht genau warum es nicht möglich war das Backup normal über Proxmox zu laden vielleicht ist der Prozess einfach timeoutet. Mir ist aufgefallen, dass während des entpackens der 5TB Datei auch keine Fortschrittsanzeige zu sehen war vielleicht hat das den Fehler erzeugt. Mir war es jedenfalls möglich diesen Fehler auf 3 Systemen zu reproduzieren es ist also ein Grundsätzlicher Fehler von Proxmox vielleicht sollten die Entwickler sich das nochmal genauer anschauen.

Trotzdem vielen Dank für die Hilfe!
 
Last edited:

JoeB

New Member
May 7, 2019
11
3
3
49
Evtl. lag es an der Größe > 4TB.
Ist aber schon ein bisschen viel.

Aber vielen Dank, dass Du die Lösung auch gepostet hast. Ich lese in Foren immer nur Probleme und leider sehr häufig die Antwort:

Jetzt geht es . Warum und wie - das weiß dann halt nur der Ratsuchende.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!