How To Associate a Tape Drive on a Different Server with a Tape Library

[Paul_G1]

I'm using Backup Exec 2010 R3 running on Windows Server 2008 R2 to manage a tape library with four tape drives.  I have the library expansion and NDMP options.  There are two servers A & B requiring backup (actually Netapp Filers controlled via NDMP).   The tape drives are each individually connected to the servers by fiber channel, and the tape library is controlled via the fiber channel connected to tape drive 1.

If I associate all four drives with server/Filer A then everything works as expected.  Backup Exec discovers the four drives and the library as being connected to server, and treats all four drives as belonging to the library.  I can backup to any/all of the drives and Backup Exec manages the library to ensure that tapes are loaded as needed into each drive.

However backup from server B using this approach is a lot slower than backup from server A as the data from B has to cross the network between the two servers to get to the tape drives.  So what I'd like to do is have drives 1 & 2 connected to server A and drives 3 & 4 connected to server B.  Unfortunately when I do this and re-discover the drives Backup Exec correctly associates drives 3 & 4 with server B but as it can only see the tape library via drive 1 on server A it treats drives 3 & 4 as orphans with no library.  Any attempt to backup to drive 3 or 4 then results in Backup Exec prompting for tapes to be loaded manually.

So, is there any way of configuring Backup Exec to associate a tape drive on server B with a tape library which it manages via server A?

[VJware]

Consider the SAN SSO Option.

http://www.symantec.com/business/support/index?page=content&id=HOWTO24287

[Colin_Weaver]

Zone everything across the SAN to do with the library (robotic arm and all 4 drives) to both NetApp filers and let Backup Exec handle the sharing of the access.

Note as long as ONLY 1 Media server is involved to manage the NetApp filers then you should not need SSO

[Paul_G1 · Accepted solution]

Colin,

Great, sounds simple - thanks for this.  I'll try this option before the SSO one as it's something I can configure quickly and I'll confirm as soon as I know.

Regards,

Paul

[Paul_G1]

Colin,

This works exactly as you specified.  I had no idea it was possible to share a library and drives across Filers like this.  Both Filers see the library and four drives, and Backup Exec accordingly shows the library and four drives on each Filer (after a little confusion during re-discovery!).  Backup Exec running four backup streams is picking the "local" instance of the drive compared to the data being backed up in the stream, so no ethernet involved.  It also seems to have worked out the sharing of the common media library, at least as far as I've tested.

The only slight puzzle is that the backup data throughput per Filer falls to around 60% compared to running each Filer independently to two drives, although total backup time is still very much less than when I was backing up half going across between Filers.  At the moment I can only think I'm hitting a SAN throughput bottleneck with hitting both Filers simultaneously, but further investigation needed.

Many Thanks!

Regards,

Paul

[Colin_Weaver]

It is still possibly to accidentally be moving the date from one filer via the other to the tape drive (which would show up as performance. The job logs should state which ndmp filer devcie was being used for each job to identify this. Not sure if we fixed it but at one point we had an issue where

Filer 1 would directly moves it's data to the library.

Filer 2 backup  jobs was set to use the same media set and append - and would remember where the tape was last mounted from  (Filer 1) when appending.

I think this was more likely in single tape drive libraries and the easy fix was use different media sets for the two filers and also consider starting the jobs as overwrites.

We also have had the odd issue with SCSI contention across the SAN between the two filers which can sometimes be helped by changing the settings on each filer and I think we resolved any other conditions for this as well - certainly not seen a cases for that issue. This would not cause a performance issue though, it would cause a job failure.