Error bei Restore aus Backup "Cannot mkdir: No space left on device"

[jo.f]

Hallochen in die Runde,

es gibt ja diesen Fehler, dem schon einige sinnlos aufgesessen sind und auch ich brauchte jetzt 2 Tage um zu kapieren, was hier schief läuft.
Wäre es möglich, dass man den Entwicklern hier mal einen Schups gibt, dass im GUI beim "Zurückspielen" eine weitere Option mit rein kommt, in welcher man die Größe des HDD Image bestimmen kann?
Leider wird scheinbar beim Backup kein Eintrag hinterlegt, in dem die HDD Größe zu finden ist und so kommt ein viel zu kleiner Standardwert zum tragen. Leider wird einem das aber an keiner Stelle mitgeteilt.
Wenn man hier ein Feld direkt serviert bekäme, wäre das ein riesen Schritt nach vorn!

Derzeit nur manueller Workaround per Shell möglich:
pct restore 1070 /mnt/pve/ds218/dump/vzdump-lxc-1090-2022_07_18-18_18_01.tar.zst --rootfs local-lvm:16
Aber für Nicht-Linuxer ist das nicht so ohne!
Da die WebGUI ja im Backend auch nur den Befehl so zusammenpuzzlet, wäre ein weiteres Feld hier wirklich leicht umzusetzen.

Wer also Connections hat, gern mal weitergeben die Sache!
Prinzipiell ist es ein Bug, dass die HDD Größe fehlt, aber mit entsprechender GUI kein Problem und sogar noch mit Mehrwert, um VMs/CTs zu ändern.

 

[sb-jw]

Also ich kann dir nicht im Detail folgen wo ein Problem besteht. Vielleicht kannst du es ja mal mehr ausführen.
Ein Wunsch kannst über den Bugtracker immer äußern, da muss keiner connections haben.

Was ich dir aber sagen kann, wenn jemand bei einem restore einer VM die Festplatte verkleinert, dem würde ich die Finger einzeln abhacken. Warum? Weil das FS sich oftmals nicht verkleinern lässt und daher ein Resize einer virtuellen Festplatte niemals eine gute Idee ist, wenn man nicht hundertprozentig genau weiß was man da tut und wie das FS in der VM aussieht.
Aus meiner Sicht wäre dieses Features zumindest für VMs definitiv nicht brauchbar.

 

[CoolTux]

In Deinem oberen Beispiel wird ein Container wieder hergestellt, keine VM. Schlechtes Beispiel gewählt oder wirklich das was Du gemacht hast?

 

[jo.f]

Achso, ja, dachte das ist bei beiden so. Also bei mir war es auch ein CT. Ich habe jetzt keine so große VM, um das da auch mal zu testen.
Aber generell wärs schon nett, beim Restore bei beiden die Option der Datenträgergröße auch im GUI direkt parat zu haben.

Na mein Problem war, dass der ein CT-Backup immer nur mit einer rootfs Größe von 50GB erstellt hat, aber die Daten im Backup um vieles größer waren. Ich konnte mir keinen Reim drauf machen, warum der meint, der Datenträger wäre voll, denn der Zieldatenträger im Proxmox hatte genug frei.
Im Backup war aber scheinbar die Größe des org. Datenträgers nicht hinterlegt (soll das so?) und da der dann die 50GB einfach so genommen hat, die in Prox. Standard sind, ging das natürlich immer schief. Eine aussagekräftige Fehlermeldung gab es aber nicht und eben leider auch beim "restore" keinen Eintrag, der die Plattengröße betrifft.

Mit dem Bugtracker kenne ich mich leider nicht aus. Meine Nerven sind leider nicht mehr so gut, was Einarbeitung in unbekannte Plattformen angeht. Mir ist das immer zu verworren alles.

Ich kenne den Fehler ja nun, aber um zu vermeiden, dass andere in die Falle tappen, wäre es nett, wenn es jemand anregen könnte.
Auch das entsperren einer VM/CT wäre nett, wenn man das in der GUI machen könnte.
... alles, was man in der Shell machen muss, fehlt einfach in der GUI.

 

[sb-jw]

Auch das entsperren einer VM/CT wäre nett, wenn man das in der GUI machen könnte.
... alles, was man in der Shell machen muss, fehlt einfach in der GUI.

Naja, man muss das immer etwas differenzierter betrachten. Manche Probleme oder Fehler sollten nicht auftreten und wenn doch, kann man es z. B. in der GUI lösen. Manche Sachen willst du aber auch nicht via GUI lösen, weil man dich dem Problem annehmen soll. Ich hatte bisher zumindest nie groß das Bedürfnis solche Aktionen auf der GUI zu machen. Ich sehe es daher wichtiger, dass der Wartungsmodus über die GUI aktivierbar ist. Aber das ist letztlich Geschmackssache.

Dass die größe der Disk nicht im Backup ist, ist in der Tat komisch, hätte ich auch anders erwartet. Aber ich persönlich nutze keine Container, daher ist mir sowas auch noch nie aufgefallen.

 

[CoolTux]

Da ich nicht ganz verstanden hatte was genau Dein Problem ist habe ich das mit einem Container einmal getestet. Container angelegt mit 20GB Root Disk und dann Backup gemacht. Danach ein Restore und es sind wieder 20GB.
Kannst Du mir genau sagen wo Du ein Problem siehst? Die Infos zum Baackup, also besser die Info wie der Container aufgebaut ist (CPU, RAM, DISK) und so steht ja im Backup drin.

 

[sb-jw]

Vielleicht kannst du auch mal mit pct config CTID die Config teilen, vielleicht finden wir ja einen Hinweis auf die Ursache.

 

[jo.f]

Ja, muss ich mal schauen.... momentan weigert der Rechner sich, den Port 8006 freizugeben ... heul*

 

[jo.f]

Achso, den ursprünglichen CT gibts leider nicht mehr, nur das Backup.
Und bei rootfs steht da eben 50 drin, was so nie der Fall war und wohl irgend ein default Wert ist, der sich da rein geschmuggelt hat (Bug iwo).
Man kann beim Zurückspielen ja einiges anpassen, aber gerade die rootfs Size nicht, ansonsten wäre mir das sofort aufgefallen und mir wären 2 Tage Rätsel raten erspart geblieben. Generell wäre es auch schön, wenn man das anpassen könnte, auch ohne, dass man dadurch einen Fehler beseitigen wöllte. Das wäre viel wichtiger als Kernzahl usw, denn das stellt sich zur Not selbst ein.
Deshalb meine Anregung, das in die GUI mit aufzunehmen, denn das ist nur minimaler Aufwand, das umzusetzen.

Da steht das in den Infos (IPs natürlich bearbeitet):

arch: amd64
cores: 4
cpulimit: 4
features: nesting=1
hostname: photoprism
memory: 4000
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.XX.XX,hwaddr=5A:52:C7:B1:17:A5,ip=192.168.XX.XX/24,type=veth
onboot: 1
ostype: ubuntu
rootfs: USB-Backup:120/vm-120-disk-1.raw,size=50G
searchdomain: fotos-privat
swap: 4000
unprivileged: 1

 

[Falk R.]

Achso, den ursprünglichen CT gibts leider nicht mehr, nur das Backup.
Und bei rootfs steht da eben 50 drin, was so nie der Fall war und wohl irgend ein default Wert ist, der sich da rein geschmuggelt hat (Bug iwo).
Man kann beim Zurückspielen ja einiges anpassen, aber gerade die rootfs Size nicht, ansonsten wäre mir das sofort aufgefallen und mir wären 2 Tage Rätsel raten erspart geblieben. Generell wäre es auch schön, wenn man das anpassen könnte, auch ohne, dass man dadurch einen Fehler beseitigen wöllte. Das wäre viel wichtiger als Kernzahl usw, denn das stellt sich zur Not selbst ein.
Deshalb meine Anregung, das in die GUI mit aufzunehmen, denn das ist nur minimaler Aufwand, das umzusetzen.

Da steht das in den Infos (IPs natürlich bearbeitet):

arch: amd64
cores: 4
cpulimit: 4
features: nesting=1
hostname: photoprism
memory: 4000
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.XX.XX,hwaddr=5A:52:C7:B1:17:A5,ip=192.168.XX.XX/24,type=veth
onboot: 1
ostype: ubuntu
rootfs: USB-Backup:120/vm-120-disk-1.raw,size=50G
searchdomain: fotos-privat
swap: 4000
unprivileged: 1

Ganz kann ich deinem Problem auch nicht folgen. Deine DIsk ist ja laut Konfiguration 50G.
Da läuft ja Photoprism drin, und in den meisten Anleitungen wir schmutzig ein Mount externer Datenquellen gemacht.
Wenn du somit eine andere Disk als Mount in deinen Container einbindest, kann es sein, dass er das mit Backupt und das Backup somit größer als 50G wird.
Beim Restore legt er natürlich nur eine 50G Disk an, weil das so in der Konfiguration steht.
Guck dir mal die Konfiguration in deinem Container genau an.

 

[CoolTux]

Ich würde auch sagen beschäftige Dich mal mit Proxmox und Backup. Lies Dir die Dokumentationen durch und wenn Du es verstanden hast wirst Du sehen das da nirgendwo ein Bug ist. Du musst halt nur mehr lernen.

Du kannst im übrigen das Backupfile auch als Template für ein neuen Container nehmen. Da kannst Du dann sagen wie groß das root sein soll vom neuen Container.

 

[jo.f]

Naja, ich finde das schon nicht normal, dass in einem Backup mit 400GB Daten eine rootfs-Größe von 50GB eingetragen ist.
Da war auch sonst nichts eingebunden. Meine CTs sind aufgesetzt und bleiben so.
Zudem, selbst wenn der Nutzer 10x Mist gebaut hat und selbst dran schuld ist, dann wird es dem Ganzen sicher nicht schaden, ihm vom System eine kleine Unterstützung zukommen zu lassen, zumal, wenn es so wenig Aufwand ist, der noch Zusatznutzen hätte (klar, nicht für GUI-Nichtnutzer, die brauchen eh nix und wissen alles). Was meint ihr denn, wer eher System so zu einem ganz großen Teil nutzt? (Tipp: Keine it-Experten).
Naja, egal. Ist wie leider so oft, dass Kommandozeilensportler auf GUI-Nutzer herabschauen. Das ist schade und als Frontend-Gestalter und Nutzer fällt mir genau das immer sehr negativ auf. Hauptsache toller schöner Code, mit dem man sich brüsten kann... und jede Hilfe, die man einem Nutzer zukommen lassen könnte, ist doch eh nur Spielerei.

Na egal, war ein Versuch anderen zu helfen und einen Mehrwert zu schaffen. Macht damit, was ihr wollt... mein Problem habe ich selbst lösen können.

 

[fabian]

das problem kann auftreten wenn der storage beim backup machen komprimierung unterstuetzt (ZFS ), der auf den du restoren willst aber nicht. dann haben vorher unter umstaenden tatsaechlich mehr daten reingepasst, als groesse draufsteht, und beim restore fliegt dir das ganze um die ohren. die loesung ueber die GUI waere dann, entsprechend das volume zu vergroessern, nochmal ein backup zu machen, und dass dann zu restoren..

 

[jo.f]

Ah, danke für die Analyse! Hmm, aber die Daten waren tatsächlich keine, die sich komprimieren lassen (Photos) und das auch gepackt um die 400GB. Der Datenträger war an sich vorher auch mit 800GB ca. definiert. Komisch, wo das verloren gegangen ist?
Der Backup-Datenträger war Ext4 und als Ziel habe ich es auch mit Ext4 versucht und nun mit LVM-Thin umgesetzt.

Ja, genau das meine ich ja, dass man beim Zurückspielen des Backups die Größe nicht einstellen kann. Das geht nur über Shell und den Parameter dann beim restore da einzugeben. Wäre doch schön, wenn die GUI das abbildet, denn die macht doch auch nichts anderes, als den Befehl dann so ans System weiterzureichen, wie er da zusammengeklickt wird.

 

[Falk R.]

Ah, danke für die Analyse! Hmm, aber die Daten waren tatsächlich keine, die sich komprimieren lassen (Photos) und das auch gepackt um die 400GB. Der Datenträger war an sich vorher auch mit 800GB ca. definiert. Komisch, wo das verloren gegangen ist?
Der Backup-Datenträger war Ext4 und als Ziel habe ich es auch mit Ext4 versucht und nun mit LVM-Thin umgesetzt.

Ja, genau das meine ich ja, dass man beim Zurückspielen des Backups die Größe nicht einstellen kann. Das geht nur über Shell und den Parameter dann beim restore da einzugeben. Wäre doch schön, wenn die GUI das abbildet, denn die macht doch auch nichts anderes, als den Befehl dann so ans System weiterzureichen, wie er da zusammengeklickt wird.

Nur weil du in eine 50GB angelegte Disk 400GB rein packst, muss man keine Features in die GUI packen, die zu Potentiellen anderen Fehlern führen können. Nur weil du "nicht Standard" Sachen machst und dann damit Probleme bei Restore bekommst, machen das 99% der Leute nicht und haben diesen Fehler gar nicht.
Meine Meinung, Features die über 50% der Leute helfen, gern in die GUI und Features die nur 1-2% der Leute brauchen, lieber in der CLI lassen.
Ich musste gestern auch eine 500TB virtual Disk per CLI anlegen, da die GUI auf 128TB begrenzt ist. Ich kann damit leben, da die meisten Leute eh niemals so dicke VMs bauen.

 

[jo.f]

Aha? Also sollte man dir das auch aus dem Shell Kommando kürzen, zur Strafe! Nicht, dass du das Feature noch benutzt und es dir weiter hilft.
Sorry, aber wenn du ein Entwickler wärst, würde ich dich achtkantig rauswerfen ... nur so. Sicher bist du aber nur ein Admin, denn ansonsten würde ich die Firma bedauern, für die du arbeitest.
Zudem, bitte lesen! Die Disk war vor dem Backup min. ca. 800GB groß und mit ca. 400GB gefüllt! Hier geht es nicht darum, etwas zu verbiegen, sondern dem Nutzer Infos zu geben und die Möglichkeit zur Korrektur. Tut mir ja leid das sagen zu müssen, aber viele Menschen betreiben Proxmox negenbei, auch wenn dich das desillusionieren mag.
Keine Ahnung, wieso du derart gegen eine Verbesserung anredest? Fühlst du dich dann irgendwie minderwertiger, weil das dann auch ohne Console funktioniert und das auch andere einfach so machen können? Hölle!

Das ist nur meine Meinung, als ehem. Frontend / Mensch-Maschine Interface Experte aber tatsächlich nur privat nutzender Proxmoxer.
Ich bringe Projekte gern voran, aber das scheint nicht allen so zu gehen.

 

[Falk R.]

Aha? Also sollte man dir das auch aus dem Shell Kommando kürzen, zur Strafe! Nicht, dass du das Feature noch benutzt und es dir weiter hilft.
Sorry, aber wenn du ein Entwickler wärst, würde ich dich achtkantig rauswerfen ... nur so. Sicher bist du aber nur ein Admin, denn ansonsten würde ich die Firma bedauern, für die du arbeitest.
Zudem, bitte lesen! Die Disk war vor dem Backup min. ca. 800GB groß und mit ca. 400GB gefüllt! Hier geht es nicht darum, etwas zu verbiegen, sondern dem Nutzer Infos zu geben und die Möglichkeit zur Korrektur.

Das ist nur meine Meinung, als ehem. Frontend / Mensch-Maschine Interface Experte.

Ich weiß nicht was für ein Problem du hast. Jeder für mich normale Mensch baut sich eine 500GB oder größere Disk wenn er 400GB Daten rein schaufeln will. Da ich keine LXC benutze weiß ich auch nicht wie das so funktioniert in eine 50GB angelegte Disk 400GB Daten rein zu packen.
Ich habe von diesem Problem noch nie gehört und nur weil eine Person dieses Problem hat, eine Funktion in die GUI zu bauen, wo Menschen mit nicht so viel Erfahrung sich eventuell beim Restore noch mehr kaputt machen können wäre eher Fahrlässig als Nützlich.

Ich habe nur 25 jahre Erfahrung mit verschiedensten Storagetechnologien und 20 Jahre mit Virtualisierung. Ich kenne solche Probleme nicht, die du hast, aber vermutlich hast du da schon mehr Erfahrungen sammeln können.

 

[jo.f]

Für dich nochmal: Es kam irgendwo zu einem Fehler beim Backup Prozess. Die Disk war niemals als 50GB Disk angelegt. Wie soll das auch gehen.
Es ist für mich nicht nachvollziehbar, wie das in die Config des Backups kam, also für mich auch keine offensichtliche Annahme vorhanden, dort nach dem Fehler zu suchen, denn Normalfall ist, dass man den Platzmangel auf dem Host-Zieldatenträger sucht.
Darum geht es aber nicht und es is völlig egal, ob den Fehler der Nutzer oder das System erzeugt hat.
Wichtig ist, dass jede Software besser wird, wenn sie den Nutzer dabei unterstützen kann, sinnlose Fehlersuchen zu vermeiden und im besten Falle sogar noch weiteren Komfort, durch bestimmte Funktionalitäten, zu bieten.

Es ist völlig egal, wo der Fehler her kommt! Aber da er mir passiert ist, und auch anderen, und eine Abhilfe wirklich simpel umzusetzen wäre, warum nicht?
So funktioniert Softwareentwicklung! "Verbesserung durch Feedback" ist eine der wichtigsten Grundlagen guter Softwareentwicklung.

Nein, ich habe eben nicht viele Erfahrungen mit Storage Techniken und genau darum geht es!
Dass du das nicht brauchst ist klar, aber andere? Du kannst dich doch nicht als Standardfall ansehen... du brauchst die GUI sicher selten.
Aber ich merke schon, du bist kein Entwickler .... und ich eben kein Storagetechniker.

 

[Falk R.]

Für dich nochmal: Es kam irgendwo zu einem Fehler beim Backup Prozess. Die Disk war niemals als 50GB Disk angelegt. Wie soll das auch gehen.

Guck dir dein Configfile an. Da steht es weiß auf Schwarz.

 

[jo.f]

Ja, wenn man dran denkt da den Fehler zu suchen, klar! Hatte ich schon erwähnt, dass ich kein Profinutzer bin und stolz darauf, dass es irgendwie läuft? ... wie wahrscheinlich 80% der Nutzer.
Im Anhang mal das schwierige und verachtenswerte Gedankenspiel von meiner Wenigkeit.
Ich sehe keinen Grund, warum unwichtige Parameter da änderbar sind, aber einer, der echt Beine stellen kann, bzw. einen Mehrwert darstellt, beim Umzug eines Containers, nicht. Das ist doch schade!
Wenn dort bei mir dann die 50GB aus der krummen Config gestanden hätten, dann wäre alles sofort problemfrei ersichtlich und korrigierbar gewesen. Ich würde es zumindest anderen gönnen, die Info mit zu bekommen.

Der Aufwand ist, einen Parameter mehr abzubilden (werden eh schon eingelesen von der Config) und dem Systemkommando, welches dann abgeschickt wird, bei Bedarf den geänderten Wert noch mitzugeben, wie das bei den anderen Werten ja auch super funktioniert.
Aufwand: 10min