Jobs failures

[Marduk]

This Job is only virtual machines are backing, a Vmware host called TPCV359-207. are about 40 servers being backed up and is generating errors as shown on the screen.

I wonder in every mistake or how I can fix.

[ZeRoC00L]

What is the transport method you have chosen ?

If it is SAN, make sure the backup server has access to the vmware volumes.
Try transport method NBD to see if that is working.

[Marduk]

I answer any questions or concerns you have arrived

1) What types of agents are? Vmware, DA?

Yes only

2) Tape Backup? What kind of tape? Current rotation scheme?

The tape you have is an MSL2024 LTO5 with 1 in FC, ​​to do tape backup for full SAN Backup all vm, the current backup scheme is a GFS 6, 4, 12

3) Support for SAN? SAN type?

SAN, the SAN have is 8GB FC.

note: how I can know which method of transport I have?

[ZeRoC00L]

In the job-properties you can select different methods.

[Jaydeep_S]

You should be able to know the transport method used for the job inside the job log. The place where you can set it is in the job properties -> Vmware tab (2010) or job properties -> virtual machines tab (2012)

What is the version of BE and ESX

For SAN backups make sure that the configuration is made as per

http://www.symantec.com/docs/TECH155831

For V-79-57344-38278 look at articles

http://www.symantec.com/docs/TECH163103

http://www.symantec.com/docs/TECH77785

The error on the 2fSQL machines is a perfect match for the solution below
http://www.symantec.com/docs/TECH129185

For V-79-57344-38278 look at
http://www.symantec.com/docs/TECH77353

[Marduk]

I will review the documentation to add to the forum. attached screenshot of the configuration having the JOB

[Marduk]

I will review the documentation to add to the forum. attached screenshot of the configuration having the JOB

[Jaydeep_S]

Yes that is how you will select SAN transport method on the backup.

[ZeRoC00L]

In that case, your backup exec server probably does not have direct access to the FC Volumes where the VMFS files are located.

You have two options:

- change to NBD transport method, this will backup the VMDKs over the network, but can be slower.

- grant access to the Vmware LUNs on the SAN for the Backup Exec media server, but be very carefull with this. If you don't know what you are doing, you can destroy your complete vmware environment. Make sure to doublecheck the technote Jaydeep already provided (http://www.symantec.com/business/support/index?page=content&id=TECH155831). This option is only possible if your backup server is equiped with at least one fibre channel adapter with connection to the SAN.

[Marduk]

I understand. reviewing it zerokool and jaydeep says. and documentation that you ask me to read. encounter three possible causes that I found in the documentation. but would like to help me with the last point. I made it and the rest are fine.

Troubleshooting / Solution
1. Verify the media server can see the SAN disks and they are not marked as OFFLINE.
2. Ping the ESX Host by name from the media server.  Verify the media server can resolve the name and IP of the ESX host correctly.
3. Create a new user account and give it administrator rights in vCenter or the ESX host and attempt the backup again using the new user account.

[ZeRoC00L]

I think point 1 is the most important, make sure that the media server can see the SAN disks.
Do you already have this configured ?

[Marduk]

clear. Not only is watching the wrong server. see other servers that supports very well.

[Marduk]

http://www.symantec.com/business/support/index?page=content&id=TECH129185

someone can make me understand this problem?

[Jaydeep_S]

If you look at the Virtual machine name TCPV359-48 IIS%2fSQL that shows in the job log that you originally posted, there is a special character % in the name.

1. Try renaming the Virtual Machine (in Vcenter/Vsphere) so that it does not have any special characters like ! @ # $ % ^ & * and then attempt a backup.

2. Try to backup directly from ESX host instead of VCenter/VSphere

3. Disable all GRT (File and Application) and perform a backup of this VM seperately.

[Marduk]

I will test with another server called BOG-SQL2. to support a virtual machine must also have installed the agent or not necessary.

[ZeRoC00L]

No, for the Vmware Agent the Windows agent does not need to be installed.

If you also have a license for SQL, you can install the RAWS agent in order to support GRT functionality.