How do storage provisioning options impact virtual machine backups?

Storage options for a vSphere virtual machine (VM) can be configured a number of different ways. Each option has pros and cons associated with it, and every situation, of course, is different. Let’s start with the two main categories of storage resources in vSphere: NFS and SAN. NFS storage has VMDK files residing on an NFS share and is a standard file server protocol.

The vSphere SAN options are where the configuration choices increase and may become confusing. SAN options include VMFS volumes on fibre channel and iSCSI shared storage resources or local disk resources on an ESX(i) server.

This dizzying array of possibilities allows the individual VM to be provisioned with the following options for storage:


  • A VMDK file residing on a production NFS datastore
  • A VMDK file residing on a production VMFS datastore
  • A Raw Device Mapping (RDM) in physical mode on a production SAN resource
  • An RDM in virtual mode on a production SAN resource
  • The iSCSI initiator configured within the guest operating system to an iSCSI target

These options will greatly impact how the VM is to be backed up with Veeam Backup & Replication. VMDKs are a rather safe bet and whether NFS or VMFS is used for the file system; I’d recommend VMFS if a decision needs to be made. Simply put, VMFS is first in line for new VMware features; namely Storage IO Control.

Many options to provision storage to VMs

Using RDMs complicates the situation, as backup strategies may be impacted. Veeam Backup & Replication supports RDMs in virtual mode only. Be sure to see this recent post on this topic, RDMs explained for Veeam Backup & Replication.

The iSCSI initiator used within the VM needs to be used very strategically. The use case we like to see this configuration used is for the Veeam Backup & Replication server installed as VM with iSCSI storage as the target. The backup jobs will be sent directly to the iSCSI target, formatted as NTFS on the Veeam Backup & Replication server. This brings better performance than leveraging VMDKs on a VMFS volume for this task. Further, the drive size can be very large to accommodate the backup repository. See this recent blog post on the Veeam blog, Using the iSCSI initiator within Veeam Backup & Replication in a VM.

Configuring the iSCSI initiator within a VM that is to be backed up with Veeam Backup & Replication will exclude the drives that are provisioned directly through the iSCSI target to the guest VM. This practice needs to be used with extreme caution, and our recommendation is to ensure that anything you back up with Veeam Backup & Replication is on a VMDK (or a RDM in virtual mode only when required). The primary reason is that the VMware snapshot won’t include the storage resources provisioned through the iSCSI initiator on the VM.

What considerations do you use when provisioning disk resources to an individual VM? How do you go about data protection for situations outside of the norm? Share your comments below.

Get weekly blog updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam’s Privacy Policy
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our blog with this weekly digest.

Eliminate Data Loss
Eliminate Ransomware

#1 Backup and Recovery


  • One other thing to note about RDMs versus VMFS is performance and management benefits. Back in the old days of 3.5 the old rule was if you want better storage IO performance you had to go with and RDM.

    Not so with 4.x. VMware has really made the IO stack more efficient and responsive so the performance benefit of using a RDM is insignificant.

    You get much better management and admin features with a VMFS volume. It’s also easier to increase the disk size, use Storage IO and get and add volumes to a VM.

  • Rick.Vanover says:

    Joe – I agree, I only do RDMs to write blogs. VMFS and VMDK all the way for me.

  • XIANLEE78 says:

    How or does disk provisioning affect replication in regards to deduplication. thin vs thick, does one give better results for replication and deduplication?

  • Rick.Vanover says:

    That’s a good question. I’m not sure, I’d presume it is a minor / unmeasurable difference as the consumed blocks are all our engine will actively process.

Leave a Reply

Your email address will not be published.