Ok, so I'm backing up using VMware APIs for Data Protection (VADP) - now which transport mode do I use?
Okay, so you just pulled your shiny "Backup Product X" out of the shrink wrap or extracted the ISO to your system. You've installed the software onto your backup server and begin to configure a VMware backup job. You get to the part where it asks for your transport method.
What's this? SAN? NBD? NBDSSL? HotAdd? Appliance?
Why don't they speak English (or your local language of choice)?
Easy there. Let's take a step back and lower the printer. You're not in Office Space.
So let's break down the Transport Modes from earlier:
SAN - Storage Area Network. You might be asking yourself "What? I can use my SAN for backups?" Sure, as long as you meet the following criteria:
1) Your Datastores reside on SAN attached storage (come on, that was a lob)
2) You're not using VVOLs or VSAN (Sorry, neither is supported by SAN transport)
3) You aren't backing up VMware Encrypted VMs (not to be confused with OS encryption or storage encryption)
4) Your backup server/appliance is attached to your SAN and zoned/LUN masked to have access to your VMFS datastores
5) Generally the fastest backup throughput but slower restore throughput, especially with thin provisioned disks
NBD - Network Block Device. "I don't want to backup my VMs with an agent!" You're right, and this isn't. Yes it travels over your IP network. Instead of backup agents on your guests though, you're connecting to a VMkernel port on your ESXi hosts and transfers using "network file copy" (NFC). This requires the following conditions:
1) Network access from your backup server/appliance to a VMkernel on your ESXi hosts running your VMs (another lob. enjoy)
2) This one doesn't care about your storage backend, since everything is passing through your ESXi hosts
3) Still can't backup VMware Encrypted VMs
4) Arguably the easiest to setup and widest support among the VMware Data protection APIs
5) Slower to backup. Generally faster to restore
6) Bandwidth/connections are restricted - This is by design and doesn't matter if the VMkernel port is dedicated to only backup operations.
NBDSSL - Network Block Device over SSL. I mentioned NBD. Why would I want NBDSSL?
1) It's more secure than NBD since it uses SSL for transport encryption
2) You finally get VMware Encrypted VM backup capability
3) The rest is pretty much the same as NBD, although it's slightly slower than NDB due to the SSL encryption/decryption overhead
4) Bandwidth/connections are restricted - This is by design and doesn't matter if the VMkernel port is dedicated to only backup operations.
HotAdd/Appliance - It's just HotAdd. I've seen products call it HotAdd, Appliance, etc. This method is literally snapshots your VMs via API call to vCenter and then mounts the disks to a Proxy VM.
-Update: Use case for HotAdd is if you want to use a completely virtual backup infrastructure and not use NBD/NBDSSL for some reason.
1) Requires a Proxy VM
2) Supports VMware Encrypted VMs IF your Proxy is encrypted as well
3) Only supports SCSI based disks - no IDE if you have some legacy configurations out there
4) PVSCSI controller isn't supported - your proxy must use LSI SCSI controller instead - Until your environment supports VDDK 6.5, at which point not only are PVSCSI controllers support, but are actually the recommended SCSI controllers. -- Thank you for pointing out this outdated information Dejan
5) The VM Host your proxy runs on must have access to all the VMDK/VMFS volumes that you may want to backup from. If not, you'll need additional proxies.
6) Your proxy needs to reside on a datastore in which the block size matches the block size of the backup target VM
7) May need to add additional SCSI controllers to support larger environments, or additional proxies (each controller is limited to 15 disks)
(had enough yet?)
8) Backs up over your IP network to your Backup server/appliance - possibly sharing the same bandwidth as your other guest VMs
I realize this was probably about a clear as mud, and it still isn't inclusive of all the various abilities and restrictions dealing with each transport method, and these have to be reviewed with each new VDDK API update (which is the API set used for VADP).
For additional reading please see the following pages:
Virtual Disk Development Kit 6.0 Release Notes
Virtual Disk Development Kit (VDDK) for 6.5
Virtual Machine Encryption Interoperability
Also, check with your Backup software vendor to determine which versions of VDDK they support.
Note on VMware VM Encryption - Regardless whether you use HotAdd or NBDSSL, your VM backup will be unencrypted unless your backup software is setup to re-encrypt the data.
If you have any further questions, you're welcome to contact me on my Twitter account.
Charles
@whitehattechs
What's this? SAN? NBD? NBDSSL? HotAdd? Appliance?
Why don't they speak English (or your local language of choice)?
Easy there. Let's take a step back and lower the printer. You're not in Office Space.
So let's break down the Transport Modes from earlier:
SAN - Storage Area Network. You might be asking yourself "What? I can use my SAN for backups?" Sure, as long as you meet the following criteria:
1) Your Datastores reside on SAN attached storage (come on, that was a lob)
2) You're not using VVOLs or VSAN (Sorry, neither is supported by SAN transport)
3) You aren't backing up VMware Encrypted VMs (not to be confused with OS encryption or storage encryption)
4) Your backup server/appliance is attached to your SAN and zoned/LUN masked to have access to your VMFS datastores
5) Generally the fastest backup throughput but slower restore throughput, especially with thin provisioned disks
NBD - Network Block Device. "I don't want to backup my VMs with an agent!" You're right, and this isn't. Yes it travels over your IP network. Instead of backup agents on your guests though, you're connecting to a VMkernel port on your ESXi hosts and transfers using "network file copy" (NFC). This requires the following conditions:
1) Network access from your backup server/appliance to a VMkernel on your ESXi hosts running your VMs (another lob. enjoy)
2) This one doesn't care about your storage backend, since everything is passing through your ESXi hosts
3) Still can't backup VMware Encrypted VMs
4) Arguably the easiest to setup and widest support among the VMware Data protection APIs
5) Slower to backup. Generally faster to restore
6) Bandwidth/connections are restricted - This is by design and doesn't matter if the VMkernel port is dedicated to only backup operations.
NBDSSL - Network Block Device over SSL. I mentioned NBD. Why would I want NBDSSL?
1) It's more secure than NBD since it uses SSL for transport encryption
2) You finally get VMware Encrypted VM backup capability
3) The rest is pretty much the same as NBD, although it's slightly slower than NDB due to the SSL encryption/decryption overhead
4) Bandwidth/connections are restricted - This is by design and doesn't matter if the VMkernel port is dedicated to only backup operations.
HotAdd/Appliance - It's just HotAdd. I've seen products call it HotAdd, Appliance, etc. This method is literally snapshots your VMs via API call to vCenter and then mounts the disks to a Proxy VM.
-Update: Use case for HotAdd is if you want to use a completely virtual backup infrastructure and not use NBD/NBDSSL for some reason.
1) Requires a Proxy VM
2) Supports VMware Encrypted VMs IF your Proxy is encrypted as well
3) Only supports SCSI based disks - no IDE if you have some legacy configurations out there
4) PVSCSI controller isn't supported - your proxy must use LSI SCSI controller instead - Until your environment supports VDDK 6.5, at which point not only are PVSCSI controllers support, but are actually the recommended SCSI controllers. -- Thank you for pointing out this outdated information Dejan
5) The VM Host your proxy runs on must have access to all the VMDK/VMFS volumes that you may want to backup from. If not, you'll need additional proxies.
6) Your proxy needs to reside on a datastore in which the block size matches the block size of the backup target VM
7) May need to add additional SCSI controllers to support larger environments, or additional proxies (each controller is limited to 15 disks)
(had enough yet?)
8) Backs up over your IP network to your Backup server/appliance - possibly sharing the same bandwidth as your other guest VMs
I realize this was probably about a clear as mud, and it still isn't inclusive of all the various abilities and restrictions dealing with each transport method, and these have to be reviewed with each new VDDK API update (which is the API set used for VADP).
For additional reading please see the following pages:
Virtual Disk Development Kit 6.0 Release Notes
Virtual Disk Development Kit (VDDK) for 6.5
Virtual Machine Encryption Interoperability
Also, check with your Backup software vendor to determine which versions of VDDK they support.
Note on VMware VM Encryption - Regardless whether you use HotAdd or NBDSSL, your VM backup will be unencrypted unless your backup software is setup to re-encrypt the data.
If you have any further questions, you're welcome to contact me on my Twitter account.
Charles
@whitehattechs
PvSCSI is recommended nowdays for HotAdd, since VDDK 6.5
ReplyDeletehttps://pubs.vmware.com/Release_Notes/en/developer/vddk/65/vsphere-vddk-65-release-notes.html
"Error in documentation. “Best Practices for HotAdd Transport” formerly recommended the LSI controller over the paravirtual SCSI controller (PVSCSI). Documentation has been corrected; PVSCSI is preferred for HotAdd in VDDK 6.5. The current recommendation is to use PVSCSI only and upgrade to 6.5 or later. If problems occur, HotAdd a dummy disk in case the first HotAdd found an unexpected target/unit on the guest OS,"