Backup/Recovery of VMware Independent Disks

Last post 04-03-2017, 5:58 PM by ozzie.castillo. 3 replies.
Sort Posts: Previous Next
  • Backup/Recovery of VMware Independent Disks
    Posted: 10-30-2016, 11:59 AM


    We are looking to implement VMware independent disks in order to reduce the snapshot overhead for some of our SQL related VMDKs.  I understand that Commvault will not backup independent drives since snapshotting is disabled.  The concern we have is around how a BMR will look.  I see that Commvault does backup the VMX file which contains the independent drive information but the restore obviously omits the respective VMDKs.  This puts us in a position of having to manually create all the missing VMDKs and figure out how each of them were mapped at the OS level.

    For those of you using independent drives, how are you handling BMRs?  For example, are you maintaining some sort of documentation of all the drives sizes and volume mappings so that you can manually create them after a recovery?  I was hoping that Commvault would still create the independent VMDKs during the recovery but they'd just be empty and the drive mappings would be retained at the OS level.  I'm just checking to see if there's a simpler more automated way of recovering VMs with independent drives where VMDKs and OS drive mappings are retained.  Having to put everything back together manually can start to become cumbersome if you have VMs with a large number of independent drives.  How are the rest of you managing this type of scenario?



    - Bill

  • Re: Backup/Recovery of VMware Independent Disks
    Posted: 10-31-2016, 3:02 PM

    Anyone using independent disks?  What is your recovery procedure after performing a full recovery of a VM with independent disks?  How are you tracking the missing VMDKs, sizes and OS drive mappings? Just trying to get a feel for how others are recovering VMs that have VMDKs that have been excluded due to utiliziing independent disks.  Thank you.


    - Bill

  • Re: Backup/Recovery of VMware Independent Disks
    Posted: 11-01-2016, 1:53 PM

    I've considered how to avoid backing up the same info multiple times.  For instance, if you back up the databases to a backup file, you still want to be able to reconstruct the VM quickly, hence why I've converted all my servers to VMs.  Backing up the databases to a VMDK that is marked as Independent Persistent is one way to avoid backing up the same data you otherwise back up.

    That being said, it probably isn't the best way.  For my environment, I have one big SQL server and I back up the databases using CommVault's SQL agent daily, then back up the entire VM once a week.  On my smaller database servers I just backup to disk and back up the VM nightly.  

    I have considered how I would re-architect things when I make the leap toward replication, though.  It would save a lot of inter-site bandwidth to avoid replicating both the VM and the database backups.  When I get to that point I think I'll probably backup the databases to a network share instead of local disk for these small database servers (less than 100GB each).  

    For SQL Server versions 2005 and newer, backing up the VM and relying on VSS to make that backup consistent has never given me any trouble in 4 years.  You're mileage may vary, but in most of my systems I no longer need to back up the databases to a file, I merely back up the entire VM and recovery is a 1-step process instead of several steps.  

  • Re: Backup/Recovery of VMware Independent Disks
    Posted: 04-03-2017, 5:58 PM

    BillyK, I ran into this post while researching on the same topic. Just wondering if you have found a better way for backing up your Exchange environment.

    In my case, we have 2 x VM, each holding active Exchange DBs as part of a DAG configuration.


The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy