BE2014 SP1 unable to backup all drives (disk partitions) of Virtual Machine when using VMware Agent

[Adonis_Manansal]

Hi Everyone,

Below is the environment:

      Backup Exec 2014 SP1

      OS: Windows 2008 R2

      VMware: 5.5 update 2

      VM OS: Windows 2008 std. SP2

Settings: The VM is a file server with around 22 disk partitions inside.

Now, my problem is:

• When I perform a VMware backup of the said VM, BE2014 can only backed-up upto 9 disk partitions. The remaining disk is not included in the backed up.
• If I perform a direct backup of the VM, I can access and backed up all the disk partitions.

Does anyone encountered this scenario?

Regards,

Ado

[pkh]

Have you checked the SCL to ensure that all the disks are supported?

[ZeRoC00L]

Are you using RDM as disks in the VM ?

[Adonis_Manansal]

Hi PKH,

Yes, all disks are supported.

ZeroCOOL,

No. When I check the Datastore in ESX, there is only one disk assigned (1.5TB)

BTW, added information:

• the disks are connected in a SAN environment.
• The Guest OS is a File Server
• When I checked the Disk Management, One Physical Disk (1.5TB) is assigned
• The said disk are confirgured into multiple partition (around 22 partitions)

There are no errors shown in Backup Exec. It just indicated that from Drive N (10th partition) upto Drive Z (22nd partition) are "Never been backed up"

I created a backup policy of the Server and successfully backed up the disks.

But everytime I used VMWare Backup Policy, other disks are not backed up, only the first 9 disks partitions.

My end-user wanted to use the VMWare Backup Policy (through put: 7.8GB/min) because it is much faster compared to the remote agent backup policy (through put: 1.2GB/min)

Are there any limitations on how many Disk Partitions can Backup Exec backed up?

[ZeRoC00L]

I think it's best to open a support case for this at Symantec support.

They can investigate the logs and find out if there is a limit in number of partitions.

[Adonis_Manansal]

Just to give you guys an update.

I already logged a case, as per Symantec Support, this problem is new and have not encountered.

They already reported this to the back-end engineer and needed to evalaute and test the same scenario.

Symantec Support marked my case as close.

No solutions found :(