Backup Exec long runtime against 40GB Solution Manager 4.0

[Former Member]

We've been running SAP ERP for over 9 years on another DB and are just getting starting with MS SQL Server 2005 DB; so this question is from that perspective.

We are trying to use Backup Exec to perform a backup of Solution Manager 4.0 SP2 which is approximately 40GB.

The first attempt to backup the server took 11 hrs.

Turned off virus scan and the 2nd backup is now 10 hrs.

We are writing to LTO3, so these statistics are ridiculously out of line.

Can you provide a punch list of the obvious and not so obvious things to check to get this timing down to a normal place?

Thank you!

[Rudi_Wiesmayr · Accepted solution]

Hello Doreen!

We have another backup strategy on our Windows SAPs:

1. We do a BACKUP DATABASE to a file device - either on a local disk or on one on another server.

This is pretty fast. 30 minutes for the 35 GB of our SolMan to another server via LAN. Or 2:15 for 590 GB on a owned SAN disk.

2. Our infrastructure collegues write the backup files to tape in a separate process. This can run as long as it does, we do not really care. It also may fail - we still have our primary disk backup.

Yes, and we also do ONLINE backups. No pain with SQLServer, no hanging jobs, no users waiting for checkpoints, just doing its work... Much better than it was in the other quadrant, is n't it?

HTH & kind regards, Rudi

Message was edited by: myself to add "online..."

Rudolf Wiesmayr

[markus_doehr2]

Is the backup device connected locally or via network?

--

Markus

[Former Member]

Via network --

The team uses that backup device for all other servers in the environment with success, so feel that there's something related to how we are attempted this SAP on SQL Server 2005 DB backup.

We are keeping the SAP Solution Manager up 'active' while trying to get the backup.

[markus_doehr2]

is another backup running at the same time onto the same device?

--

Markus

[Former Member]

Here's more data -

The file level backup portion is running at a very quick xfer rate.

The problem / long runtime occurs while trying to backup the DB.

Sounds like we are also attempting a database check DBCC which might be the root cause of the long runtime.

We are going to take the DBCC out of the backup routine for tonight & I can report back.

[Former Member]

Removing the DBCC took 1/2 hr off the runtime, so it's now 9.5 hrs

Good grief!