Backup Exec Disk to Disk to Tape, with SAN to Tape direct copy

[jnett]

I currently have BE 2010 configured to write nightly backups to 2 SAN volumes at night, with duplicate jobs that run to tape as soon as those finish.  However, I don't think I have it configured properly to utilize the 8GB fabric speeds when writing those disk backups from the SAN to the fiber tape drive.  

What is the proper configuration for this?

Thanks.

[teiva-boy]

8gb FC is 1000MB/s i believe. Which in BackupExec speak is 60,000MB/min. Never happen, ever, with BackupExec. What speeds are you getting to disk now, how may spindles in your raid group, what type of raid, how many concurrent streams? What kind of tape drives, what kind of speeds are you getting, also FC attached? What about tape block size? Assuming all FC, client data goes over ethernet to the BE server, over FC to disk, then back into BE out to tape over FC. Client to BE is the only time traffic would go over ethernet. So many variables, so little detail provided.

[jnett]

My only concern is the second step, duplicating the backups from disk to tape, which if I'm not mistaken should all be over FC to the tape library.  It is an LTO 6 drive.  Typically backups are running anywhere from 1300mb/sec (which is too slow i think) to 5300mb/sec (which i'm happy with).

[Colin_Weaver]

The speed difference may depend on what is in the backups - I would expect a GRT enabled backup set of say a VMware guest or an Exchange information store to take longer to duplicate to tape than a non-GRT (standard remote agent) set - This is because the IMG format for GRT on disk is not a MTF format suitable for tape so processing occurs to send GRT data to tape. However a non GRT set actually writes a form of MTF into the BKF file, meaning duplicating this data to tape is likely to be quicker as less interim conversion processing is needed.

As such you probably need to start comparing the original backups that cause a slow duplicate with the original backups that create a fast duplicate to understand the cause.

You should also look at what is going on in parallel if the fast duplicates actually run at a different time of day than the slow duplicates.

[jnett]

Sorry for the delay, digging into this again today.

Here's what throws me off.  I have 1 job that is direct written to tape, no D2D2T involved.  It's writing a smaller job, about 300gb of SQL dumps.  that job runs right around 5gb/min.  

Next job is file data, mail (not exchange), etc.  Goes disk to disk to tape, and is currently running at 1.2gb/min.  I've picked through these jobs, and can't find anything for differences in the way they're setup.  

The only thing different is that the direct to tape job is coming off of our newer SAN, while the D2D2T writes to our old SAN, then to tape.  Both are 10k SAS disks, 8gb FC connections.  I guess it's possible that the new SAN is just that much faster at processing it than the old one. 

I will try to send some backups to the new SAN then to tape, see if that makes a difference.

Do I have this setup properly?  BE job runs to disk, which is a LUN presented to the BE server and added as a disk drive in Windows, then created duplicate jobs to fire off to tape once the disk job is complete.  

Thanks.

[teiva-boy]

backups touch so much of an infrastructure, there are many different bottlnecks in an environment.  client CPU, memory, disk, ethernet, switch backplane, DNS, etc, etc, etc...  No one can really help you until you touch each component to make sure it's running optimally.

Your thoughput numbers for SQL are normal, if not better than most.  Your Exchange backups are goodd, not the best I've seen, but average for what I run into.  

GRT can play a role in slowing things down, as cacn things like a consistency check.