[Gelöst] Umzug von VBox auf USB-Stick.

[ottonormal]

Hallo,

In der Virtualbox habe ich ein verschlüsseltes Debian-Jessie-Gnome installiert und so eingerichtet,
dass es nutzbar ist.
Davon habe ich dann mit Redobackup ein Backup erstellt und auf einen 64GB-USB-Stick übertragen.
Das hat alles gut geklappt und funktioniert.
Da dieser Stick aber nicht soo schnell ist, möchte ich dieses Backup nun gerne auf einen anderen,
schnelleren Stick übertragen. Der hat aber nur 32GB und da meckert Redobackup weil die originale
virtuelle Festplatte etwas größer ist.
Das ist eine .vdi-Platte mit 35GB, dynamisch belegt. Davon sind aber nur 15GB benutzt, der Rest ist
"nicht zugeteilt". Hier mal ein Bild davon:

http://www.pic-upload.de/view-29151805/ ... i.png.html

Eigentlich müsste das doch passen, Redobackup möchte das aber nicht.
Da es eine verschlüsselte crypt-luks -Partition ist, lässt die sich auch nicht einfach kopieren und so
auf den neuen Stick übertragen.

Die Lösung wäre das virtuelle Laufwerk zu verkleinern, also den nicht zugeteilten Platz zu entfernen
oder verkleinern, geht das und wenn wie?
Gibt es noch eine andere Möglichkeit?

Gruß, ottonormal

[rendegast]

Es geht aber darum, welche Blöcke luks schonmal "angefaßt" hat,
diese sind dann verschlüsselt und lassen sich durch zip auch nicht mehr verkleinern,
resp. durch 'qemu-img convert' freigeben.

Besorge Dir besser einen 64GB-Stick, oder erstelle ein kleineres (verschlüsseltes) Image.

Oder den Inhalt des entschlüsselten device in einen Container auf dem Stick.

[ottonormal]

Die luks-Partition soll ja auch nicht verkleinert werden, die ist ja nur 15GB groß, zusammen mit der
Boot-Partition (256MB) sollte die doch ganz bequem auf einen 32GB-Stick passen.
Es geht nur um den nicht zugeteilten Bereich auf der virtuellen Platte, den möchte ich verkleinern
bzw. entfernen. Also eigentlich eine Aufgabe für Virtualbox.

[owl102]

Es geht nur um den nicht zugeteilten Bereich auf der virtuellen Platte

Dann nulle doch den nicht zugeteilten Bereich (zum Beispiel, indem du temporär dort eine Partition erzeugst und die mit "dd if=/dev/zero ..." nullst) und jage anschließend "VBoxManage modifyhd blah.vdi --compact" über das Image. Danach sollte die VDI-Datei wieder kleiner sein.

Siehe zum Beispiel auch: https://blogs.oracle.com/virtualbox/ent ... ur_virtual

[ottonormal]

Danach sollte die VDI-Datei wieder kleiner sein.

Ich glaube, das ist ein Missverständnis. Die Größe der "Datei" ist unwichtig. Was ich möchte,
ist die Größe der "Festplatte" verändern durch verkleinern oder entfernen des "nicht zugeteilten"
Bereiches.
So dass Redobackup eine Festplatte von ca. 20 oder 25 GB Größe vorfindet statt wie jetzt 35GB.

[rendegast]

'qemu-img resize ...'
?

[ottonormal]

'qemu-img resize ...'
?

Qemu? Ist das nicht etwas anderes als Virtualbox?

Ich gebe es auf, habe jetzt schon Stunden im Netz gesucht. Es gibt immer nur Anleitungen wie die
von @owl102.
Das was ich möchte scheint wohl nicht zu gehen .

[rendegast]

Ich dachte mir

Code: Alles auswählen

$ qemu-img create img 5G
Formatting 'img', fmt=raw size=5368709120 
$ qemu-img resize img -3G
Image resized.
$ qemu-img info img
image: img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 0

doch leider in diesem Fall

Code: Alles auswählen

$ qemu-img create -f vdi img.vdi 5G
Formatting 'img.vdi', fmt=vdi size=5368709120 static=off 
$ qemu-img resize img.vdi -3G
qemu-img: This image does not support resize

Code: Alles auswählen

vboxmanage modifymedium ./img.vdi --resize 1500
0%...
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage: error: Resize medium operation for this format is not implemented yet!

$ vboxmanage modifyhd ./img.vdi --resize 1500
0%...
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage: error: Resize medium operation for this format is not implemented yet!

Tolle Wurst!

[ThorstenS]

Ich verleinere vorm Backup ziehen mit redo die Partitionen - gparted ist ja dabei. Aber das kann eben nicht mit Verschlüsselung umgehen…
redobackup kommt nicht mit kleineren Ziel Partitionen zurecht, dafür ist das tool leider nicht gemacht.

Könntest du dir nicht auf dem neuen stick die Partitionierung und den verschlüsselten Container wieder von Hand neu anlegen und dann nur die Inhalte transferieren?
Ein einfaches rsync-Backup sollte doch ausreichend sein.

[ottonormal]

Vielen Dank für Eure Tipps, ich bin aber schon dabei auf dem Stick neu zu installieren.
Schade, aber das war auch nicht so geplant, sonst hätte ich das in der VBox entsprechend
anders eingerichtet.
Naja, nächstes mal bin ich schlauer.

[trg2889]

Unabhängig von der Verschlüsselung geht was du vorhast überhaupt nicht.
Denke mal habe dich so verstanden das das virtualbox-image in einer lukspartion sich befindet oder ? Nichts desto trotz ein Datenträger der mit zb. 20 GB in virtualbox angemeldet ist aber dynamisch nur 5 GB hat wird trz 20 GB an platz benötigen weil die restlichen 15 GB reserviert sind also würde dein Image nicht passen weil der Datenträger 35GB hat und du ihn auf einen 32 GB stick kopieren willst

[geier22]

Versuchs mal so:
mit

Code: Alles auswählen

~$ VBoxManage list hdds

die UUID deiner Platte herausfinden

dann:

Code: Alles auswählen

~$ VBoxManage modifyhd [UUID der Disk ohne Klammern] --resize 45000

Die 45000 sind MB - must du natürlich anpassen , also z.B. 25000

Bei mir hat das geklappt. Ob das mit einer verschlüsselten Platte geht, weiß ich nicht, aber an sich spricht nichts dagegen
Allerdings würde ich das vdi- Image erst mal auf eine Festplatte kopieren (oder klonen) und erneut bei Virtualbox anmelden.
Und dann die "Schrumpfung" starten.

[ottonormal]

Versuchs mal so...

Danke für den Tipp, klappt aber leider auch nicht.
Die UUIDs werden alle brav angezeigt, nach

Code: Alles auswählen

~$ VBoxManage list hdds

kommt aber nur das:

Code: Alles auswählen

ottonormal@debian:~$ VBoxManage modifyhd ce076ae4-c402-4238-a7da-ff1abf981cd1 --resize 25000
VBoxManage: error: Could not open the medium '/media/ottonormal/Daten-I/Virtualbox-Linux3-DebiOBox/Debian-Gnome-32/VBox-Daten.vdi'.
VBoxManage: error: VD: error VERR_FILE_NOT_FOUND opening image file '/media/ottonormal/Daten-I/Virtualbox-Linux3-DebiOBox/Debian-Gnome-32/VBox-Daten.vdi' (VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "Resize(cbResize, pProgress.asOutParam())" at line 690 of file VBoxManageDisk.cpp
VBoxManage: error: Failed to resize medium!
ottonormal@debian:~$

Da bremst wohl die verschlüsselte Partition.

[ottonormal]

Versuchs mal so...

Nachtrag:
Ich habe das noch mal mit einer anderen virtuellen Festplatte ohne Verschlüsselung
versucht.
Die habe ich von 20000 MB auf 30000 MB vergrößert, das hat funktioniert.
Danach verkleinern von 30000 MB auf 25000 MB funktionierte dann nicht.
Da kam diese Meldung:

Code: Alles auswählen

ottonormal@debian:~$ VBoxManage modifyhd 32ff2b2d-0132-40d8-b869-2c3df2c5cac2 --resize 25000
0%...
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage: error: Resize medium operation for this format is not implemented yet!
ottonormal@debian:~$ 

Trotzdem habe ich mir diesen Tipp mal gespeichert, kommt ja vielleicht noch mal wieder
vor, dass man eine Plattenvergrößerung braucht.
Also Danke dafür .

[owl102]

Du könntest eine zweite virtuelle Festplatte in der gewünschten Größe anlegen, in der VM ein Live-Linux booten und dort die erste Platte mittels dd auf die zweite kopieren. Anschließend VM herunterfahren und in VirtualBox die erste Festplatte entfernen.

[geier22]

Hab noch mal gegoogel:

Von hier:

With the --compact option, can be used to compact disk images, i.e. remove blocks that only contains zeroes. This will shrink a dynamically allocated image again; it will reduce the physical size of the image without affecting the logical size of the virtual disk. Compaction works both for base images and for diff images created as part of a snapshot.

wie ich das verstehe, müsste es also heißen (hatte bisher nur vergrößert) :

Code: Alles auswählen

VBoxManage modifyhd 32ff2b2d-0132-40d8-b869-2c3df2c5cac2  --compact 25000

[ottonormal]

@owl102
Das hatte ich ja schon probiert, die verschlüsselte Partition lässt sich aber nicht kopieren.

@geier22
Den Befehl habe ich jetzt entsprechend geändert. Danach erhalte ich das:

Code: Alles auswählen

ottonormal@debian:~$ VBoxManage modifyhd 32ff2b2d-0132-40d8-b869-2c3df2c5cac2 --compact 25000
Oracle VM VirtualBox Command Line Management Interface Version 5.0.2
(C) 2005-2015 Oracle Corporation
All rights reserved.

Usage:

VBoxManage modifymedium     [disk|dvd|floppy] <uuid|filename>
                            [--type normal|writethrough|immutable|shareable|
                                    readonly|multiattach]
                            [--autoreset on|off]
                            [--property <name=[value]>]
                            [--compact]
                            [--resize <megabytes>|--resizebyte <bytes>]


Syntax error: Invalid parameter '25000'
ottonormal@debian:~$

Lasse ich die '25000' weg, kommt das:

Code: Alles auswählen

ottonormal@debian:~$ VBoxManage modifyhd 32ff2b2d-0132-40d8-b869-2c3df2c5cac2 --compact
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
ottonormal@debian:~$

Geändert hat sich danach aber nichts.

[DeletedUserReAsG]

Es hat schon seine Richtigkeit, dass das Image nicht auf einen Datenträger geschrieben wird, der kleiner ist, als es selbst werden kann. Was würde denn passieren, ginge es? Man würde es nutzen, vergessen, dass es eigentlich™ gar nicht draufpasst, irgendwann eine Datei zuviel schreiben und plötzlich vor ‘nem Haufen nutzloser Zufallsdaten stehen. Theoretisch wäre der Weg: FS verkleinern, Luks-Container verkleinern, Partition verkleinern, Image verkleinern. Soweit ich das verfolgt habe, würd’s aber aufgrund unzureichender Funktionalität der zuständigen Software am letzten Schritt scheitern – also wäre der Weg, wie schon geschrieben wurde: neues virtuelles HDD mit der richtigen Größe anlegen, Partitionen erstellen, luks-formatieren, FS anlegen, einbinden, Daten kopieren, altes Image löschen, fertig.

[owl102]

@owl102
Das hatte ich ja schon probiert, die verschlüsselte Partition lässt sich aber nicht kopieren.

Verstehe ich nicht und ich bin auch so mutig, "glaube ich nicht" zu schreiben. Irgendwo muß dann in deiner Vorgehensweise ein Fehler gewesen sein. Ich habe schon einige Male luks-verschlüsselte Festplatten mit dd kopiert (sowohl reale als auch virtuelle) und nie ein Problem damit gehabt. "dd if=/dev/sda of=/dev/sdb" (mit einer kleineren /dev/sdb, aber groß genug, daß alle Partitionen von /dev/sda draufpassen), ich glaube einfach nicht, daß das nicht funktioniert. Mir fällt auch keine technische Begründung ein, warum das nicht funktionieren sollte.

[DeletedUserReAsG]

Genau lesen: ein gewisses „Redobackup“ verweigert die Operation (aus gutem, nachvollziehbaren Grund). Kopieren oder dd’n wird man das Image trotzdem können, vorausgesetzt, es wurde weit genug eingedampft. Erscheint mir aber wie eine digitale Version des altbekannten russischen Roulette, hier für das System/die Daten.

[ottonormal]

@niemand
Ich verstehe es trotzdem nicht.
Die beiden Partitionen um die es geht, haben eine Größe von 15.256 MB.
Warum sollen die nicht auf einen Stick mit 32 GB passen?
Warum wird der "nicht zugeteilte" Platz am Ende der Platte in das Backup mit einbezogen
wenn ich beim Erstellen des Backups mit Redobackup nur die beiden ersten Partitionen
anhake? Ich will keinen "nicht zugeteilten" Platz kopieren und auf den Stick übertragen.
Irgendwie schon komisch, dass das "Nichts" eines großen Sticks nicht auf einen kleineren
übertragen werden kann.

Übrigens ist das Thema ja inzwischen auch als "Aufgegeben" gekennzeichnet und meine
Neuinstallation auf dem Stick abgeschlossen.
Trotzdem interessiert mich schon, ob und wie ich den "nicht zugeteilten" Platz einer
virtuellen Festplatte in Virtualbox verkleinern bzw. entfernen kann.

@owl102
Also gut, ich werde es noch einmal probieren.
Ich muss allerdings auch zugeben, dass ich das nur mit Gparted versucht habe, nicht
mittels dd. In Gparted kann ich jede Partition kopieren und auf einer anderen Festplatte einfügen,
nur bei der verschlüsselten ist der Eintrag "kopieren" ausgegraut.

[DeletedUserReAsG]

@niemand
Ich verstehe es trotzdem nicht.
Die beiden Partitionen um die es geht, haben eine Größe von 15.256 MB.
Warum sollen die nicht auf einen Stick mit 32 GB passen?

Wie, passen nicht? Ich denke, dein Backupdingens verweigert es ordnungsgemäß, das so zu schreiben? Geht es mit cp oder dd denn auch nicht? Das wäre in der Tat seltsam, würde aber eine aussagekräftige Fehlermeldung liefern, die du dann hier posten solltest. Wobei ich an dieser Stelle davon ausgehe, dass es nicht „Die beiden Partitionen haben je eine Größe von 15GB“ heißen soll – das würdemöglicherweise tatsächlich physikalisch nicht hinkommen.

Und wenn es auf die Art doch funktioniert (was ich eigentlich voraussetze, wenn beide Partitionen zusammen 15GB belegen), und du es dann nutzt, beschwere dich dann später bitte nicht, wenn du vor ‘nem Haufen Datenmüll stehst. Meine Empfehlung: mach’s sauber und ordentlich, etwa mittels vorgeschlagenem Umkopieren der Daten, und gut.

Hintergrund des Backupdingens: die virtuelle Platte kann potentiell größer werden, als auf dem physischen Datenträger Platz vorhanden ist. Ob innerhalb der virtuellen Platte was nicht zugeteilt ist, oder was auch immer, interessiert es nicht – es sieht, dass das virtuelle Device aufgrund seiner Spezifikationen nicht auf den Stick passt.

[ottonormal]

Asche auf mein Haupt und die Bitte um Entschuldigung an @owl102 weil ich Deinen
Tipp nicht weiter verfolgt habe nachdem Gparted das nicht konnte.
dd ist/war mir auch neu, nur ISOs damit auf USB-Sticks bringen, das kannte ich schon.

Also, ich habe in VBox eine neue vdi-Platte mit 25GB angelegt und auf die dann per

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb

den Kopiervorgang gestartet. Und es funktionierte, es kam zwar am Schluss die Meldung
"Auf dem Gerät ist kein Speicherplatz mehr verfügbar", aber was darauf sollte, war auch
drauf. Dann habe ich einen 32GB-Teststick in VBox eingebunden und das gleiche dann
noch mal direkt auf den Stick kopiert. Das hat über 3 Stunden gedauert, aber auch das
hat funktioniert. Der Stick bootet und das System darauf ist genau wie auch in der VBox.
Nach dem Vorgang bekam ich übrigens diese Meldung:

Code: Alles auswählen

root@debian:/home/ottonormal# dd if=/dev/sda of=/dev/sdc
dd: Schreiben in „/dev/sdc“: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
61767681+0 Datensätze ein
61767680+0 Datensätze aus
31625052160 Bytes (32 GB) kopiert, 11273,3 s, 2,8 MB/s
root@debian:/home/ottonormal#

Besten Dank also für die Hilfe, Thema gelöst .

Ach ja, mein "Backupdingens" ein gewisses „Redobackup“ - mit diesem Programm mache
ich schon sehr lange, auch schon zu Windowszeiten, alle meine Backups und bin sehr
zufrieden damit. Noch nie gab es damit bei mir Probleme, im Gegensatz zu Acronis, das
ich davor benutzt habe, das hat mir nicht nur einmal eine ganze Partition zerschossen.

Es ging mit Redobackup auch hervorragend z. B. ein Backup von einer virtuellen Platte
zu machen und das dann anschließend auf einen Stick zu übertragen, nur in diesem
speziellen Fall aus vorgenannten Gründen eben nicht.

[ThorstenS]

Ich mag redobackup auch und habe es aktuell unter jessie neu aufgelegt:
viewtopic.php?p=1070527#p1070527

Der Vorteil ist jetzt, dass ich aktuellere Treiberunterstützung habe und ich anstelle von gzip pigz benutze. Damit werden beim Packen/Entpacken alle Kerne ausgelastet.
Mein Laptop mit SSD wird nun in 14 Minuten gesichert, anstelle von 50 Minuten vorher…

[ottonormal]

Sehr interessant, den Thread kannte ich schon.
Kann man sich das schon und wenn wo herunterladen?
Gibt es das dann auch in deutsch? Englisch ist nicht unbedingt meine Sprache,
auch wenn ich mit der jetzigen englischen Version klarkomme, bin ich manchmal
doch etwas unsicher.