Any Hypervisor vDisk backup



  • So I use Xenserver, but this question is really for the major 3, most backup solutions make snapshots of the VM and offload that onto external storage.

    Is there a need or reason to backup the vDisk as well, and if so how would this be implemented on the 3 major Hypervisors?



  • All you really care about is the image backup. No need to backup more than that.



  • Well (and this is just for my knowledge) why is it not worth it to backup the vDisk as well? My Snapshots using NAUBackup, are the full size of the vDisk.

    But what happens if vDisk becomes corrupted? Can you perform a full rebuild of a VM from just that snapshot?

    I haven't had anything crash, and was curious what would happen.

    Or if some one mistakenly deleted a VM and the vDisk, would the snapshot be enough to restore that VM?



  • @DustinB3403 said:

    But what happens if vDisk becomes corrupted? Can you perform a full rebuild of a VM from just that snapshot?

    That's what the word backup would mean 🙂



  • @DustinB3403 said:

    Or if some one mistakenly deleted a VM and the vDisk, would the snapshot be enough to restore that VM?

    Do a test to see how it works, restores are a critical part of a backup process. But yes, a snapshot of the disk is just that, a snapshot of it. You should have an exact image of the entire disk. If not, you don't have a snapshot.



  • Haha... but in my experience I haven't seen how to backup a vDISK. So I guess, how would one go about this?

    Snapshots of the VM's (even using a tool like NAUBackup) would seem to only protect a portion of the system.



  • Ok im testing now on a non-critcal VM, and will report back.

    😃



  • @DustinB3403 said:

    Haha... but in my experience I haven't seen how to backup a vDISK. So I guess, how would one go about this?

    That's what a snapshot IS.



  • It is my understanding that NAU Backup creates a snapshot and then backs up the entire image from the point where it takes the snapshot.



  • @DustinB3403 said:

    Snapshots of the VM's (even using a tool like NAUBackup) would seem to only protect a portion of the system.

    Which portion do you feel that that would be?



  • @dafyre said:

    It is my understanding that NAU Backup creates a snapshot and then backs up the entire image from the point where it takes the snapshot.

    That is my understanding as well.



  • I guess I'm just over thinking it, as I could've sworn that I read it was recommended that a Snapshot, is not a "BACKUP", but rather just a quick way to undo changes to the VM.

    But I digress from that thought, as it seems stupid now that I think about it.

    Testing away..



  • @DustinB3403 said:

    I guess I'm just over thinking it, as I could've sworn that I read it was recommended that a Snapshot, is not a "BACKUP", but rather just a quick way to undo changes to the VM.

    In general, this is talking about using VMware or XenServer's snapshot feature by itself... because your HOST server can still fail...

    But copying entire VMs off with tools like NAUBackup you're covered... (The key is that is has to copy the ENTIRE VM off )



  • @DustinB3403 said:

    I guess I'm just over thinking it, as I could've sworn that I read it was recommended that a Snapshot, is not a "BACKUP", but rather just a quick way to undo changes to the VM.

    Of course, a snapshot is not a backup at all. It is a tool used to make a backup! The snapshot is part of the backup mechanism, not the backup itself. It doesn't become a backup until you transport a copy off to another medium.



  • @DustinB3403 said:

    But I digress from that thought, as it seems stupid now that I think about it.

    A file copy is not a backup. But a file copy to another location is a backup. See the difference? A copy is not a backup until they are decoupled.



  • 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! 🙂


Log in to reply