Hello,

Ive searched for veritas documents or a list of what I could try out to solve my issue. I have a backup job that runs very slow on version 9.1. The total is 41GB of data including an exchange. It should be less than 8 hours but its running over 24 hours. Any tips to try? Thanks

Windows 2003 SP2?

windows 2003 server SBS with no Service pack

try temporarily disabling your Exchange "brick by brick" job and just perform an infostore backup job.  You'll probably find it goes much faster.

a good practice is to break up your jobs into logical units, scheduled to run one after the other.  Then the performance bottleneck will quickly become apparent.  This good practice has several other benefits as well, including ease of administration.

Thanks steve thats great advice. When you say break up the job into different units, could I run the job to backup data 1st that overwrites the tape, then another job to backup the exchange that appends to the same tape, so that the data and exchange is kept on the same tape? Thanks

Exactly.  You might want to disable media protection to simplify administration when adding new tapes (unless you have a robotic library).  Since the Append Jobs won't be able to run until the Overwrite job is finished, they'll queue up and execute as soon as the tape drive becomes available.

When I say "brick by brick" job, I mean the one that you can use to restore individual email messages.  When I say "info store" job, I mean the one that takes everything back to a known point in time.

If you find you're having performance problems in the Exchange Info store brick by brick job, you could try 1) disabling other disk I/O activities during the backup period like a) scheduled file based AV scans, b) scheduled AV for exchange scans, c) diskeeper (defrag) operations, d) other backup jobs, e) exchange av real time scans (but only do this temporarily and disable SMTP during this period) etc.  Other things to try are 2) moving the exchange stores to a separate partition (that's on a separate array from the main OS) to increase performance, 3) defragmenting the exchange store.

Exchange Brick by Brick jobs are notoriously slow.  If you do all the above things, then you may consider changing the types of backups you do.  You could continue running your nightly backups of the info store, but do a *full* backup of the exchange store in "brick by brick" mode over the weekend.  Then, do a *differential* backup nightly.  This will take less time.

It's worth noting that if you have BUE 11d and CPS, you can perform a special kind of backup job that backs up the infostore as if it was a giant file.  Then when you want to restore, you get granular control of the restore function.  It's really cool in that you spend less time on your backups, but when you go to restore it takes a long time to run because of the way it works.  Restore operations are the exception though, so it's a pretty good tradeoff.  If you're looking to upgrade anyway, this is something to consider.

Ok I have set up 2 jobs I will post bakc the results thanks steve. I didnt have time to set the brick by brick or infostore option. Is that available on 9.1? if so where about?

When you click on the "Backup" tab, you'll see several options for backing up Exchange.  Two say "Microsoft Exchange Mailboxes" and "Microsoft Exchange Public Folders".  When you check anything in here, you're using "Brick by Brick".  You'll also see an option for "Microsoft Information Store", which is the entire database as a unit.

Check out pages 1070-1080 in the Veritas Bue 9 manual.  They give a really good description of how all this works.

This link to the Admin Guide may work:
http://entkb.symantec.com/availability/resultDisplay.do?gotoLink=65&;docType=1002&contextId=38838%3A65.86&clusterName=SymantecAVailability&contentId=9aedbb8f-a40f-4a9d-8fbc-05a13701c2a4&responseId=20ee712d41c2e49c%3A1b1fbf4%3A113fc86bf9c%3A5fcb&groupId=7&;answerGroup=16&score=952&page=http%3A%2F%2Fsymantec.atgnow.com%2Favailability%2Fdocs%2Fpdf%2FBEWNT%2F254158.pdf&result=15&excerpt=Administrator%27s+Guide&resultType=5000#

The Brick by Brick and InfoStore backup jobs have been available for quite some time, and 9.x versions are no exception.  You need the "Exchange Agent" license, which you must already have if you're having performance problems!

Here's some more information on your exact problem from Symantec:

Veritas Document ID: 264851
http://support.veritas.com/docs/264851
Slow throughput while backing up Microsoft Exchange mailboxes for Exchange 2000 and Exchange 2003 Servers.

Details:
Inherently, Microsoft Exchange mailbox backups in Backup Exec (tm) are slower than database backups. This is due to the fact that, in order to back up mailboxes on a 'brick-level,' Backup Exec has to impersonate an Exchange mailbox account and authenticate for each individual mailbox item, whereas a database backup is streamed to Backup Exec in one continuous data package.  

Wow great help steve ill have a read through. I understand the brick by brick and infostore now I have used that before, I thought it was an option though. Ill leave it on brick by brick so I can see what it does then maybe try infostore.

Well, I hope this is your problem.  We still haven't established the portion of your backups that are slow.  However this is a likely cause that should be investigated.  

The tips in my (25 Jul 07 9:01) post are some good tips for many different types of performance problems.  

SteveOT's suggestion (23 Jul 07 7:42) could very well fix it too.

Once you locate the bottleneck, then decide on your plan of action.

I think i found the fauklt the tape or tape drive has many errors so the back up stops after  a few hours. The tapes are new and I have ran chekc on the drive which eventually was ok after many cleans. There must be a problem with the drive. I have HP tape tools on there, im going to run theh tests again. I did test runs in BUE the data one was ok but the exchange job failed after 20 mins with no real clue in the log. I at a loss with this now.

Be sure to run the Firmware check in L&TT (HP Library and Tape Tools) and then (with BUE Services stopped) run the diagnostic tests in L&TT.

If the drive fails, you can get it replaced under warranty by HP.  You'll need to know: 1) if you're using the most current windows drivers for the SCSI controller card, 2) that the drive has the latest firmware, 3) Veritas/Symantec Tape drivers are up to date

You might want to try a different scsi cable and active terminator.  Be sure you have the drive on it's OWN scsi channel that is NOT on a RAID controller.  The SCSI card should be U320 or better for modern TBU drives, a 160 really isn't fast enough.  If you have another U320 card handy, try replacing it, or use another SCSI channel on the server.

Its strange as the back up used to work fine. When I do try and stop the services the job engine doesnt stop. I have ran the tap tools tests before but I think the services were running. The back up just doesnt run at all now. Although I checked this morning (its on a customer site) the clean light was flashing so I have cleaned the drive but I did this many times not long ago. Maybe the drive is damaged. If I can get the services to stop with rebooting the whole server I will use tape tools again and then maybe call HP to check if it is in warranty

OK stopped the service and running all tests from tape tools. Ill post up what I get, so far just some warning from the 'Device Analysis' see below

|__ Test 'Device Analysis' started on device 'HP C7438A' at address '3/0.3.0'
    ||__ Operations Log
    |    ||__ analyzing device data...
    |    ||__
    ||__ Analysis Results
        ||__ Device Analysis for DDS Drives
        ||__ Firmware rev 'V601' is up-to-date for 'C7438A' as of Fri Oct 6 19:00:00 2006.
        ||__ Serial EEPROM Data is not accessible on this drive
        ||__ Life data is not available.
        ||__ There were 1 rules checked.

ok all the other tests passed i even done the dds test but i am using a dat72 drive here is the result
|__ Analysis Results
    ||__ DDS Drive Assessment Test version V04.06.2007
    ||__ Time: Tue Jul 31 11:19:45 2007       Serial Number: 0005207110
    ||__ Device Analysis for DDS Drives
    ||__ Firmware rev 'V601' is up-to-date for 'C7438A' as of Fri Oct 6 19:00:00 2006.
    ||__ Serial EEPROM Data is not accessible on this drive
    ||__ Life data is not available.
    ||__ There were 1 rules checked.
    ||__ Testing has completed and no problems were found.

I think ill try a new backup job and see if that works

Ok I created a new back up job by using the a save selection list, cleaned the drive ran tape tools test (all ok see abpve posts) ran a test backup on a file and everything seems to be ok. But the normal job ran last night is still running 15 hours later and I dont know why it is running so slow. I have a feeling the tape drive is faulty and damaged the tapes but all tests show that they are ok. Anyone got any clue's? Thanks

what is the model of the drive?
try a job that backs up one giant file (perhaps ~ 1GB or so) with compression on and off
what speed does BUE say it's getting?  (should be in the job log)

Hi steve thanks for replying. The throughput was 161MB with compression and without 176MB. The model of the drive is HP DAT72 external drive. I had lots and lots of alerts in the alert section which i cleared, alot werer multiple tape alerts. The jobs ran ok by the way no problem.

Was that Hardware or Software compression?

I've never been impressed with DAT throughput.  HP's site says that the maximum throughput is 23GB/hr with 2:1 compression.  Since we all know that never happens, you're really looking at 11 or 12 GB/hr.  If my math is right, you should be in the 190 mb/min speed range.  So it's not perfect, but not really bad either (+60mb/min is what I expect to see from DAT drives).

I guess at this point try to do the jobs broken up into logical pieces and see if the bottleneck is the *type* of data being backed up, or just the drive.

I tried breaking up the data into exchange and data. I will break them up into folders and see if i can find out what is going on. Thanks again mate.

Hi steve I ran the original backup and it ran ok upto 5 GB so I guess it will be ok by manually running the job its just when the job is scheduled to run the problem occurs.m So this looks like a scheduling problem.

perhaps there's another server task that's running at the same time as the scheduled jobs, slowing them down

Yeah, I checked those out. I will look into that again. and post up what I find.