Any Hypervisor vDisk backup
-
Yeah your previous explanation helped, much like Imaging.
-
At first, as I was reading this thread, I was like - what the hell is a vDisk?
I think it's the storage pool that the VM host uses to hold the VM's disks that are running on that machine, Am I right?
That said - the VHD files are the full VMs. You only need to backup the VHDs, not the whole filesystem that ESXi, Hyper-V, Xen sees, only the files that it uses - the VHDs (or whatever file type the hypervisor uses).
The Snapshot (and I'm over simplifying this) basically creates a VHD that you can backup that has no locked portions in it so the backup process can read the entire thing.
-
@Dashrender said:
I think it's the storage pool that the VM host uses to hold the VM's disks that are running on that machine, Am I right?
Not the pool but the disk image itself.
-
@Dashrender said:
The Snapshot (and I'm over simplifying this) basically creates a VHD that you can backup that has no locked portions in it so the backup process can read the entire thing.
Good way to look at it.
-
@scottalanmiller said:
@Dashrender said:
I think it's the storage pool that the VM host uses to hold the VM's disks that are running on that machine, Am I right?
Not the pool but the disk image itself.
I don't follow - what image? to me image implies something that is static, unchanging.
-
Well @Dashrender / @scottalanmiller I tested on a non-critical VM.
Running a full NAUBackup for the test, I deleted the vDISK (the hard drive under the actual VM) the same place you can add additional disk or remove them.
Deleting this vDisk, and then importing the backup.xva file back into Xen completely rebuilt a NEW VM to a fully functional state.
Now I am being very clear as far as the process I used at least with NAUBackup, deleting the primary VM or the vDISK, and importing the backup.xva builds a completely new VM. So in effect, it builds an Image that can be used to recover with.
At this point, you might be able to remount the other vDISK from the damaged VM (and all disk under it) into the new VM, but I have no scenario to test with at this point. I'll probably test this tomorrow at some point as an learning experience.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
I think it's the storage pool that the VM host uses to hold the VM's disks that are running on that machine, Am I right?
Not the pool but the disk image itself.
I don't follow - what image? to me image implies something that is static, unchanging.
At any moment in time the vDisk or VHD is an image. It will change moment to moment but is never "in the process or changing". Any time that it is observed it is static. I know that that sounds strange, but it is a little like the infamous cat. We don't know the state of things, but if we observe it we will know.
-
@DustinB3403 said:
Well @Dashrender / @scottalanmiller I tested on a non-critical VM.
Running a full NAUBackup for the test, I deleted the vDISK (the hard drive under the actual VM) the same place you can add additional disk or remove them.
Deleting this vDisk, and then importing the backup.xva file back into Xen completely rebuilt a NEW VM to a fully functional state.
Now I am being very clear as far as the process I used at least with NAUBackup, deleting the primary VM or the vDISK, and importing the backup.xva builds a completely new VM. So in effect, it builds an Image that can be used to recover with.
At this point, you might be able to remount the other vDISK from the damaged VM (and all disk under it) into the new VM, but I have no scenario to test with at this point. I'll probably test this tomorrow at some point as an learning experience.
Awesome, so full backup, working as intended. Good deal.
-
Oh yeah, to add when I imported it named the VM "Backup_VMName" in the VM list.
Just rename it and go. As good as it could get.
-
@scottalanmiller said:
At any moment in time the vDisk or VHD is an image. It will change moment to moment but is never "in the process or changing". Any time that it is observed it is static. I know that that sounds strange, but it is a little like the infamous cat. We don't know the state of things, but if we observe it we will know.
AWWW - I wasn't seeing it correctly, the vDisk belongs to the VM, not the hypervisor, gotcha!
-
@Dashrender said:
AWWW - I wasn't seeing it correctly, the vDisk belongs to the VM, not the hypervisor, gotcha!
No long winded explanations required.
He is using the term vDisk to reference the file that in Hyper-V is the .VHD/.VHDX. Don't know the ext in other systems without looking.
-
Jared on this Host we aren't running Hyper-V but Xenserver, but yes vDISK would be the VHD/VHDX (in hyper-v) or OVA (in Xen)
-
@DustinB3403 said:
Jared on this Host we aren't running Hyper-V but Xenserver, but yes vDISK would be the VHD/VHDX (in hyper-v) or OVA (in Xen)
I know you're using sin but I was using the term that @Dashrender was familiar with
-
@JaredBusch said:
@DustinB3403 said:
Jared on this Host we aren't running Hyper-V but Xenserver, but yes vDISK would be the VHD/VHDX (in hyper-v) or OVA (in Xen)
I know you're using sin but I was using the term that @Dashrender was familiar with
Thanks!
