Forum Discussion

bernath's avatar
bernath
Level 0
9 years ago

Duplicating Exchange backup sets to tape is extremely slow

I have a fairly simple setup where I do a full Exchange (2013) backup once per week with nightly incrementals in between. The Exchange data is backed up over the network to local disk storage on the backup server, then duplicated to tape. GRT is enabled.

The duplication jobs are very slow. MUCH slower than when I duplicate other types of data. There are long periods where the job appears to stall. When this happens, there is no disk or network activity occurring. The only thing happening is beremote.exe maxes out one single core of the backup server CPU. Eventually the job begins progressing again. Speeds when it actually writes to the tape are decent (~6,600MB/min).

This is BE15 (14.2.1180). Both the backup and Exchange servers are Server 2012 R2.

Is there any way I can speed up the duplication? The duplicate jobs are actually taking longer than the backups themselves.

15
Backup and Recovery
Backup Exec
Windows Server (2003-2008)
  • thecope's avatar
    thecope
    Level 3
    9 years ago

    We are having the same issues.  Background: We stood up a new server and consolidated three Exchange servers (2007) into one running 2013, so we migrated users to the new server (not an in-place upgrade) and retire the old.  Total database is just under 300 GB, compared to 200 GB previously for the server I had to back up of the three geo-distributed servers.  I had my jobs initially situated the same as we did with the 2007 server, to do backup and cataloging immediately following for GRT but the cataloging took forver by comparison to 2007 (30 minutes vs. 6+ hours).  The support group via ticket moved us to Instant GRT, which improved the backup to disk to a little over an hour (6,000 MB/minute) since the cataloging was done "instantly" and not as a separate job.  That was beautiful.

    The problem was that this caused duplication to tape to now take forever.  It is the same kind of scenario.  It initially moves the data to tape in about 2 hours (3,000 MB/minute) and then hangs, appearing as if it is doing nothing.  It will complete about 5 to 7 hours later.  The verify step on the job takes maybe 20 to 30 minutes, but doesn't kick off until it finishes the backup, which has hung up for 5 to 7 hours.  For whatever reason the ticket we have has support hung up on the overall job rate, not the fact that the data appears to copy very quickly and then get hung up, which causes the job rate to diminish slowly over the apparently idle time.

    If I actually try to duplicate incremental jobs to the tape along with the full, the job runs in excess of over 17 hours for maybe 350 GB of data.  It runs too long so I end up cancelling it since I have other jobs I need to get running.

    For now I just have to schedule the full backup to be duplicated during long idle windows for other jobs.  We do not do any deduplication or anything fancy.  It is just local hard drive storage and a single bay LTO5 tape loader library.  The backup job isn't doing anything but the Exchange information store.

    If we find resolution with the helpdesk (ticket is three weeks old now) I will post it here in case it helps anyone else.

    • thecope's avatar
      thecope
      Level 3
      8 years ago

      We are still trying to work through this with support.  In general, we have not made any real progress in the last month.  Support had us move back to doing the catalog job immediately after a backup.  This is still painfully slow, as each incrmenetal job (no more than 4 gb on average) then catalogs for over 3 hours.  It used to take maybe 10 minutes to catalog an incremental backup when we were on Exchange 2007.

      Duplication to tape, regardless what original backup to disk method and cataloging was done for GRT, still takes about 6 hours.  If we try to duplicate each incremental job for the week that corresponds to the full, it seems like each one causes the job to run an additional 6 hours.

      We are pretty much going to arrive at one of these points pending if support can actually find resolution:

      #1 - Live with the performance issues and simply never duplicate incrementals.

      #2 - Switch to non GRT backups and find some other tool that will help with individual email recovery.

      #3 - Move away from Vertias entirely.

      Given we are moving away from every other Symantec product at our institution, Veritas is on a short leash in my mind right now since it is still really a child of Symantec, despite the company sell off and disassociation from Symantec over the last year.