09-28-2012 05:09 AM
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.
09-28-2012 05:28 AM
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.
09-28-2012 05:44 AM
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?
09-28-2012 05:48 AM
In the job-properties you can select different methods.
09-28-2012 05:59 AM
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
09-28-2012 12:21 PM
I will review the documentation to add to the forum. attached screenshot of the configuration having the JOB
09-28-2012 12:22 PM
I will review the documentation to add to the forum. attached screenshot of the configuration having the JOB
09-28-2012 01:14 PM
Yes that is how you will select SAN transport method on the backup.
09-29-2012 01:44 AM
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.
10-01-2012 07:31 PM
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.
10-02-2012 04:34 AM
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 ?
10-02-2012 06:19 AM
clear. Not only is watching the wrong server. see other servers that supports very well.
10-02-2012 09:27 AM
http://www.symantec.com/business/support/index?page=content&id=TECH129185
someone can make me understand this problem?
10-02-2012 09:06 PM
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.
10-03-2012 03:34 PM
I will test with another server called BOG-SQL2. to support a virtual machine must also have installed the agent or not necessary.
10-04-2012 12:13 AM
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.