cancel
Showing results for 
Search instead for 
Did you mean: 

vmware backup failed using san transport mode

Vickie
Level 6
Master : Linux VM
Media : NetBackup Appliance 5230
Client : VM
Transport : SAN

VM image backup getting failed in SAN mode, but working fine with NBD mode.

Data store are mapped and visible to backup host.

1 ACCEPTED SOLUTION

Accepted Solutions

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi Vickie,

For me, its does not make sense...If you can make backup by NBD transport mode and cannot make using SAN, there is a problem with the Luns that were presented to VM backup host.

When this happen the backup job failed with an error message similar to this one:

Ex:

From Detailed Status:

10/21/2013 11:18:28 - Info bptm (pid=14932) using 1048576 data buffer size
10/21/2013 11:18:28 - Info bptm (pid=14932) setting receive network buffer to 1048576 bytes
10/21/2013 11:18:28 - Info bptm (pid=14932) using 512 data buffers
10/21/2013 11:18:29 - Info bptm (pid=14932) start backup
10/21/2013 11:18:32 - begin writing
10/21/2013 11:18:34 - Error bpbrm (pid=14922) from client winclient.local: ERR - Error opening the snapshot disks using given transport mode: Status 23
10/21/2013 11:18:37 - Error bptm (pid=14932) media manager terminated by parent process
10/21/2013 11:18:42 - Info backup2 (pid=14932) StorageServer=PureDisk:backup2; Report=PDDO Stats for (backup2): scanned: 3 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%
10/21/2013 11:18:42 - Info bpbkar (pid=0) done. status: 6: the backup failed to back up the requested files
10/21/2013 11:18:42 - end writing; write time: 0:00:10
the backup failed to back up the requested files (6)

Make sure LUNs are accessible to the VMware Backup Host and check the Troubleshotting below:

 Troubleshooting for some common transport mode related failures

Backups/Restores failing with status 6 or status 13 or status 11 with following indication in Activity monitor might indicate that there is some issue with transport modes:-

  • ERR - Error opening the snapshot disks using given transport mode: Status 23 indicates that there was some problem in accessing the vmdk using given transport mode.

    Here are some tips on handling this kind of error:
    • If you are using NBD, make sure the VMware Backup Host has connectivity to ESX server hosting the virtual machine.
    • If you are using SAN, please make sure that the datastore LUNs are accessible to VMware Backup Host.
    • If you are using HotAdd, please make sure that your backup host is Virtual Machine and following conditions are satisfied:
      • The VM should not contain IDE disks.
      • Ensure that there are sufficient SCSI controllers attached on the Backup Host VM.
      • The Backup Host VM has access to datastores where VM being backed up resides.
      • The Backup Host VM and VM being backed up should be under the same datacenter.
      • If the previous backup failed, it might have left some disks of the backup VM attached to Backup Host. These disks need to be manually removed before attempting the next backup.
    • If a non-default port for vCenter is in use, then that port needs to be defined while adding vCenter credentials to NetBackup or Backup Exec.
    • If using NBD/NBDSSL/HotAdd, please make sure the VMware Backup Host is able to communicate to port 902 of ESX server hosting the VM.
  • file read failed indicates that there might be problem in reading the VMDK using the given transport mode. 
  • file write failed indicates that there might be some problem in writing to the VMDK using the given transport mode.
    • If using SAN for restores, please make sure datastore LUNs are accessible to the VMware Backup Host and in an online state.
    • If using HotAdd for restore, please make sure that SAN policy on the Backup Host is set to OnlineAll.
    • If using SAN for restore, make sure that the size of VMDK is multiple of datastore block size.  Otherwise, the write of the last block will fail.  In this case, a workaround would be to use NBD for restore.
    • Please make sure that the you assign necessary privileges to the user configured in NetBackup or Backup Exec to log on to vSphere.

Regards,

Thiago

View solution in original post

11 REPLIES 11

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi Vickie,

All datastore were mapped for the vm backup host? What is the error that you are facing? 

About Transport modes, take a look this TN.

https://www.veritas.com/support/en_US/article.000094725

Regards,

Thiago

Hi Thiago,

Yes datastore are mapped with backup host as well so it can read the snapshot from it.

Error : Error opening the snapshot disks using given transport ... the backup failed to back up the requested files (6 )

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi Vickie,

For me, its does not make sense...If you can make backup by NBD transport mode and cannot make using SAN, there is a problem with the Luns that were presented to VM backup host.

When this happen the backup job failed with an error message similar to this one:

Ex:

From Detailed Status:

10/21/2013 11:18:28 - Info bptm (pid=14932) using 1048576 data buffer size
10/21/2013 11:18:28 - Info bptm (pid=14932) setting receive network buffer to 1048576 bytes
10/21/2013 11:18:28 - Info bptm (pid=14932) using 512 data buffers
10/21/2013 11:18:29 - Info bptm (pid=14932) start backup
10/21/2013 11:18:32 - begin writing
10/21/2013 11:18:34 - Error bpbrm (pid=14922) from client winclient.local: ERR - Error opening the snapshot disks using given transport mode: Status 23
10/21/2013 11:18:37 - Error bptm (pid=14932) media manager terminated by parent process
10/21/2013 11:18:42 - Info backup2 (pid=14932) StorageServer=PureDisk:backup2; Report=PDDO Stats for (backup2): scanned: 3 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%
10/21/2013 11:18:42 - Info bpbkar (pid=0) done. status: 6: the backup failed to back up the requested files
10/21/2013 11:18:42 - end writing; write time: 0:00:10
the backup failed to back up the requested files (6)

Make sure LUNs are accessible to the VMware Backup Host and check the Troubleshotting below:

 Troubleshooting for some common transport mode related failures

Backups/Restores failing with status 6 or status 13 or status 11 with following indication in Activity monitor might indicate that there is some issue with transport modes:-

  • ERR - Error opening the snapshot disks using given transport mode: Status 23 indicates that there was some problem in accessing the vmdk using given transport mode.

    Here are some tips on handling this kind of error:
    • If you are using NBD, make sure the VMware Backup Host has connectivity to ESX server hosting the virtual machine.
    • If you are using SAN, please make sure that the datastore LUNs are accessible to VMware Backup Host.
    • If you are using HotAdd, please make sure that your backup host is Virtual Machine and following conditions are satisfied:
      • The VM should not contain IDE disks.
      • Ensure that there are sufficient SCSI controllers attached on the Backup Host VM.
      • The Backup Host VM has access to datastores where VM being backed up resides.
      • The Backup Host VM and VM being backed up should be under the same datacenter.
      • If the previous backup failed, it might have left some disks of the backup VM attached to Backup Host. These disks need to be manually removed before attempting the next backup.
    • If a non-default port for vCenter is in use, then that port needs to be defined while adding vCenter credentials to NetBackup or Backup Exec.
    • If using NBD/NBDSSL/HotAdd, please make sure the VMware Backup Host is able to communicate to port 902 of ESX server hosting the VM.
  • file read failed indicates that there might be problem in reading the VMDK using the given transport mode. 
  • file write failed indicates that there might be some problem in writing to the VMDK using the given transport mode.
    • If using SAN for restores, please make sure datastore LUNs are accessible to the VMware Backup Host and in an online state.
    • If using HotAdd for restore, please make sure that SAN policy on the Backup Host is set to OnlineAll.
    • If using SAN for restore, make sure that the size of VMDK is multiple of datastore block size.  Otherwise, the write of the last block will fail.  In this case, a workaround would be to use NBD for restore.
    • Please make sure that the you assign necessary privileges to the user configured in NetBackup or Backup Exec to log on to vSphere.

Regards,

Thiago

View solution in original post

Hi Thiago,

I also could not understand why the backup working in NBD and getting failed in SAN.

However the Datastore is accessible by Backup Host (NetBackup Appliance 5230), as the backup of other vm there on the same Datastore is getting successfully completed.

 

 

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi @Vickie,

Any update? Your backups are still failing? From netbackup appliance, by CLISH - Manage --> FibreChannel --> Show, and see if

All HBA ports are available and the status

All datastore are show;

 

Regards,

Thiago Ribeiro

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi @Vickie,

Just for information, I found this TN take a look

https://vox.veritas.com/t5/NetBackup-Appliance/Appliance-5230-HBA-ports-using-initiater-or-target-mo...

 

Regards,

Thiago Ribeiro

Ive found that even if you run a scan on the appliance once LUNs are presented, and it appears to be presented, the only way it will work is to reboot the appliance and it will then work.

If you are running NBU 773 or higher and the VM has a duplicate BIOS UUID as another or multiple VMs, it will fail no matter what. This is a huge known issue to Veritas that has not been corrected since 773 came out. Don't get me started on this mess!!

Thiago_Ribeiro
VIP
Partner    VIP    Accredited

Hi @HunkerDownOneMo,

That true what you said...I faced the same problem with NBU version 8.0 ( Appliance 5240 3.0)...The Luns were presented and even after scan on the appliance they dont appear and I need to reboot the appliance.

 

Regards,

Thiago Ribeiro

Thanks All for your assistance and support.

Vertias suggested to Upgrade the appliace to 2.7.3 version, that's too for collecting the vxms logs at vm end and then they will gonna identify route cause. As of now they did not find anything. 

So for time being we are taking backup over LAN mode.

If the LUNs are presented to the host, then the solution is:
Clean the / tmp folder.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

@BornNew 

This 2017 post was resolved.