MauriceD
Contributor
Contributor

Traditional ArcServe Backup

Not sure where to put this, but...

have a client with VMware 5.5, with 3 ESXi 5.5 hosts with dual paths (fibre HBA cards) direct to IBM DS3400 SAN

There are a number of servers, assorted Windows 2003, 2008R2, and one 2012R2 server.

Client continues to use same backup - a DLT tape drive connected to the physical backup server.

Backup software is ArcServe15SP1

Backups happen over the (1Gb) network, same as when some of these were physical.

The File server is a Windows 2003 server with LSI Logic Parallel controller card.

It was built from scratch when the setup was ESX4.1 but the "virtual hardware" is upgraded, it is ver. 10 now.

VMware Tools is up to date.

The problem is, when the backup runs, it will randomly take either 2 or 4 hours to backup the same drive - the large data drive E: on the file server.

Friday night the backup E: session ran 3h57m with throughput of 1,232.4MB/min

Thursday it ran 1h42m with throughput of 2,845.75MB/min

This is your typical USERS and SHARED file server content - lots of small to medium files, 291GB and 337,270 files.

(Whereas the SQL server /Windows2012 with 20 very large files 17GB has a throughput of around 4100MB/min consistently.

Where would I even start in figuring out this cause?

The extra 2 hours puts the full backup finishing well past opening time.

I've had issues before where a virtualized server (P2V) would exhibit poor throughput, but this was a purpose-made virtual guest.

0 Kudos
3 Replies
vmroyale
Immortal
Immortal

Maybe asking the obvious, but is your Friday backup a full vs a diff or inc on Thursday? Or is a full one speed one day a different speed the next?

Brian Atkinson | vExpert | VMTN Moderator | Author of "VCP5-DCV VMware Certified Professional-Data Center Virtualization on vSphere 5.5 Study Guide: VCP-550" | @vmroyale | http://vmroyale.com
0 Kudos
rachelsg
Enthusiast
Enthusiast

Hi

Welcome to communities.

It may be problem at both side .

please check if any update and compatibility or know issues at arc site .

0 Kudos
MauriceD
Contributor
Contributor

No, the same job runs Monday to Friday, differentials on Sat Sun to fit on the one tape.

The odd thing is that it is erratic - about half the time, 8 hours; about half the time over 10 hours. The biggest time difference is the more than double time required to back up the file server. Most of the other sessions (6 different Windows servers) are consistently the same time.

I've seen something similar that I could not fix on another client's P2V virtualized server. The solution at the time was to rebuild a new server pure virtual, as it was only file servers.

But something seems to have gone "twang" in the last few months and now they notice the backup could run until 10:30AM.

I moved the start time from 11:00PM to 10:30PM and it's still consistently just that one Windows server.

I'm concerned that VMware and CA will point to the other's software as the problem.

The thing that concerns me the most is the random inconsistency and that it is just one virtual machine.

Is there something I should know about VMware disk controllers? VMDK's? VMware tools?

I've been trolling Google for any possible causes.

0 Kudos