[SOLVED] Backup laden schlägt fehl

U

user58292

New Member
May 9, 2019
11
0
1
39
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:
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
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
 
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
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.
 
Ich habe local nochmal deaktiviert und wieder reaktiviert und dann --storage local verwendet damit hat es jetzt funktioniert. Vielen Dank!
 
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:
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
 
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 ^^.
 
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.
 
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.
 
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 ^^.
 
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.
 
So ich habe das Problem jetzt gelöst. Ich bin einfach dieser Anleitung gefolgt:

  1. Screen installieren
    Bash: 
    apt-get update && apt-get install screen
  2. Falls die Datei eine .vma.lzo Dateiendung hat
    Bash: 
    screen -S lzop lzop -d vzdump100.vma.lzo
    Das wird lange dauern.
  3. Die .vma extrahieren
    Bash: 
    screen -S extract vma extract vzdump100.vma vzdump100/
    Das wird auch lange dauern.
  4. Backup Verzeichnis öffnen
    Bash: 
    cd vzdump100
  5. Nun ist die Disk eine .raw Datei. Falls eine .qcow2 Datei benötigt wird
    Bash: 
    screen -S convert qemu-img convert -p -O qcow2 disk-drive-scsi0.raw /var/lib/vz/images/vm-100-disk-0.qcow2
    Das dauert auch lange.
  6. Erstelle eine neue VM (hier mit der ID 100). Füge eine kleine neue Disk hinzu welche gleich mit dem Backup ersetzt wird.
  7. Öffne das Web GUI -> VMs -> 100 -> Wähle die neue Disk aus -> unmount
  8. Nun wieder in der Konsole gehen wir in das VM Verzeichnis
    Bash: 
    cd /var/lib/vz/images/100/
  9. Lösche die neue temporäre Disk
    Bash: 
    rm vm-100-disk-0.qcow2
  10. Füge das Backup ein
    Bash: 
    mv ../vm-100-disk-0.qcow2 .
  11. Wieder im Web GUI klicke auf die unmounted Disk -> Bearbeiten -> Mounten
  12. Starte die VM

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:
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.
 
You must log in or register to reply here.

About

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

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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 yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back