Back up a raw disk VM?

[FlashAaAh]

Running VB 6.0.12 on Ubuntu 18.04 with guest Windows 7. I made a raw disk that points to a physical SSD which hosts the guest OS (also have a 1TB HDD for host and everything else).

I want to be ready for a quick redeployment and minimal loss of data in case of a hardware (SSD) failure.

What is the best way to back up the raw disk content? If needed, also quickly attach that backup to a different VM and not necessarily again from a raw disk (might be a different host OS or just one drive available)?

[socratis]

What is the best way to back up the raw disk content?

Back up the SSD like you would backup any other hard drive attached to your computer?

The rawdisk is a "pointer" to an actual disk, nothing special. So, backup the disk like you would any other disk.

[FlashAaAh]

That is understood.

A way to fulfil the second question requirements?

[socratis]

You've already created a "<rawdisk>.VMDK" file in order to raw-access the disk. This VMDK file is of the "text" kind, something like that:

# Disk DescriptorFile
version=1
CID=19cf0ef7
parentCID=ffffffff
createType="fullDevice"

# Extent description
RW 2007040 FLAT "/dev/disk1" 0

# The disk Data Base 
#DDB

ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="1991"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="4d2de46c-2aac-4c54-9a62-06357eabbb72"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="be37a153-fb3a-45da-8c32-b58d960c481b"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.geometry.biosCylinders="995"
ddb.geometry.biosHeads="32"
ddb.geometry.biosSectors="63"

This basically describes the location and geometry of the hard disk. This VMDK file is attached to your VM via the VM's recipe, the "<VM>.vbox" file. If you back up your host, then those files are backed up as well. You ... are backing up your host, right?

[FlashAaAh]

Based on your answers, I don't think you understand my question.

I fully understand what a raw disk means, look at the OP.

What I want is the VM backup to be ready for a quick attachment/deployment/whatever-you-call-it to another VB instance which is not necessarily on the same machine. As I would a copy of a virtual disk file. Get a .VDI copy and attach it to another VM, fire it up and continue on my way as if nothing happened.

What I would really like to avoid is to have a backup file that needs operating system to be restored. That way, I already have a VM just for that, that restores said backup to another .VDI that I then attach to another VM (or the same one and boot from it, makes no difference).
The restore part is what I do not need because of:
- the time needed to perform the restore
- the disk space requirement, to hold both the .VDI and the backup at the same time, prolly not available att.

[socratis]

What I want is the VM backup to be ready for a quick attachment/deployment/whatever-you-call-it to another VB instance which is not necessarily on the same machine.

Based on that answer, I don't think that you understand what a rawdisk is. How exactly are you going to move to another computer B and have access to the rawdisk of computer A? You got to make absolutely sure that the SSD from computer A is the same as the one in computer B. And I really mean the same, as in identical twins, otherwise your VMDK is going to be invalid.

As I would a copy of a virtual disk file

A rawdisk isn't a virtual disk file, it's an actual real disk.

Get a .VDI copy and attach it to another VM

If you want a VDI, then create a VDI, not a rawdisk!

[FlashAaAh]

@Socratis, I thank you for your assistence this far, but please, do not respond to this thread any more.

Any takers? Can't be the only one that runs a raw disk, but wants/needs a virtual disk file backup.

[socratis]

but please, do not respond to this thread any more.

You got to be kidding me right? You are not in a position to dictate, or demand, or even ask (even politely) what other users are doing or not, what other users are commenting on or not! This is not your home, not your neighborhood, not your kingdom! This is a public forum. Are we crystal clear on this?

And just because of your lack of understanding isn't met with the answer that you wished for, don't get your frustration aimed at me. Try to understand the problem, and then come back again. With a proper question that makes half a sense...

And yes, you are the only one that has asked for a backup of a raw disk. The rest of the users seem to understand that a raw disk is a pointer to an actual, physical disk. How you back up a physical disk is not a VirtualBox question!

[Whiskeyjack]

@Socratis, I thank you for your assistence this far, but please, do not respond to this thread any more.

Any takers? Can't be the only one that runs a raw disk, but wants/needs a virtual disk file backup.

Not a very bright idea to alienate the single person who is trying to help you.

[klaus]

Is it so difficult to think of cloning (using the GUI or VBoxManage clonemedium), which socratis already hinted at without using the exact buzzword? That way you get a .VDI or .VMDK image (or any other image format supported by VirtualBox) which you can use independent of raw disk access.

Alternatively you could clone the entire VM, copy the resulting VM directory to some backup store and remove the cloned VM again (assume you don't want to permanently keep it in VirtualBox). When needing to run the VM from backup, just copy it to the default VM directory and re-add (register) the .vbox file again.

[FlashAaAh]

Is it so difficult to think of cloning (using the GUI or VBoxManage clonemedium)

Thank you, that is the answer! I didn't think that would work without sudo, I have no sudo permissions.

which socratis already hinted at without using the exact buzzword?

Where and how, exactly? All I can read is "it is a physical disk, back it up as any other disk on you host. The .vmdk is just a text file."

It is not hard to give a straight answer, just as you did. Thank you again, clonemedium comand is exactly what I was looking for: an exact copy of the raw disk content in a form of a functional and portable virtual disk file.

[socratis]

Klaus, I'm sorry, but I still stand by my answer. What you're describing is a "convert a raw disk to a VDI", which is a whole lot different from what the OP wanted/described/asked. If that's the goal, there are several ways to achieve that, be it "clone" or "convertfromraw".

@FlashAaAh
If that's what you wanted from the beginning (to convert a rawdisk to a VDI), I'm afraid things got "lost in the translation"/question.

[FlashAaAh]

I did write that. It took klaus one post and one sentence to give the absolutely right answer. Somehow he understood right away what I aimed at.

[scottgus1]

guest Windows 7....What is the best way to back up the raw disk content? If needed, also quickly attach that backup to a different VM

I would run in-the-guest backup software (for Windows, Macrium Reflect is good). There are two ways this backup could be done:

1. Clone using the backup software from the source raw disk to a temporarily attached extra VDI. This VDI can then be put on another guest quickly.

2. Image using the backup software from the source raw disk to a host shared folder via a real (not Guest Additions based) network. The image would need to be restored, which would take time, but would be mountable on the host or another PC if the backup software can allow it, to access the guest's data. (in other words the guest data is not locked into a VDI.)

Both of these processes could happen within the guest while the guest was running. Restore would happen by booting the receiving guest with the backup software's restore boot ISO.

Personally, my backup routine would involve both of these methods. Either one could be used to restore the guest OS to a new raw disk, too.

[FlashAaAh]

1. Clone using the backup software from the source raw disk to a temporarily attached extra VDI. This VDI can then be put on another guest quickly.

That solution was my last resort, but a few problems with it:

1. Puts additional strain on the VM resources. RL performance is already diminished simply by the VM's nature itself.
2. The VM has to be up and running for the process, so no elegant way to shut down the entire computer. With clonemedium, there's a bash script that creates a (new) .vdi (each time with, let's say, date-based name) and shuts down the physical machine afterwards. No need to be present once I execute it.
3. Needs additional software.

2. Image using the backup software from the source raw disk to a host shared folder via a real (not Guest Additions based) network. The image would need to be restored, which would take time, but would be mountable on the host or another PC if the backup software can allow it, to access the guest's data. (in other words the guest data is not locked into a VDI.)

I thought of that, too, but not feasable in my case:

What I would really like to avoid is to have a backup file that needs operating system to be restored. That way, I already have a VM just for that, that restores said backup to another .VDI that I then attach to another VM (or the same one and boot from it, makes no difference).
The restore part is what I do not need because of:
- the time needed to perform the restore
- the disk space requirement, to hold both the .VDI and the backup at the same time, prolly not available att.

Networked storage is not available, Im affraid. Just what I can access as a user on my computer.