Remote Backup using NBU 6,5

[Sango]

Our client has a requirement that they wanted to do a remote backup. The data in the VTL located in Building A will be duplicated to the tape library in Building B. As you can see from the diagram, the tape library and the NBU server in Building B are connected to a FC switch. Therefore, may I know how does the NBU in Building A able to control the tape library in Building B? What NBU options are needed to achieve this? Maybe I should ask the basic question. Is my design workable?

I have drawn up a diagram for reference. You can refer here,

http://img33.imageshack.us/img33/2577/backupdiagram2.jpg

Thanks in advance for all the help.
 
 

[John_Stockard]

The media server in Building A cannot directly control the library in Building B or write to the tape drives in Building B because there's no FC connectivity between the two buildings, only a 10Gig Ethernet link.

If you linked the two SANs together over the 10Gig connection by using FC-to-IP converter boxes at each end, you could then have the media server in Building A control the library in Building B and write to the tape drives in Building B.

An alternative would be to have the media server in Building A do a normal duplication job (either through Vault or through Storage Lifecycle Policies) from it's local HDS disk array to the tape library in Building B, but this would be over the 10Gig LAN and would involve the media server in Building B.  If the 10Gig connection between the buildings isn't fully consumed with other traffic, this option would work but you most likely won't be spinning the LTO-4 drives in Building B at their top speed.

[Sango]

 Hi John,

Thanks for the advice.

Firstly, the VLS 9000 is actually a VTL. :)

So to me it is not workable as the client is not going to invest in a FC-IP converter.

I have a question. When you said "An alternative would be to have the media server in Building A do a normal duplication job (either through Vault or through Storage Lifecycle Policies) from it's local HDS disk array to the tape library in Building B, but this would be over the 10Gig LAN and would involve the media server in Building B."

The customer did mentioned something that he is going to use the BPDuplicate command as his NBU is a Solaris box. So may I know by using the BPDuplicate command, can this command write the data from the VTL to the tape? Else, by using the Vault feature, do I still need the FC-IP converter?

Thanks.

[John_Stockard]

My mistake -- when I glanced at your diagram originally, I mis-read the "HP VLS 9000" as "HDS 9000" and assumed it was a traditional Hitachi disk array.  :)

If the customer scripts up something using bpduplicate (or automates it using Vault or Storage Lifecycle Policies), they don't need any fibre-channel connectivity (or FC-IP converters) between Building A and Building B.  In this case, the media server in Building A will read the relevant backup images off of the VTL in Building A over FC, send the data to the media server in Building B over TCP, and then the media server in Building B will write the backup images to the LTO-4 HP library in Building B over FC.  Likewise, they can use a very similar process to migrate their older backup images from LTO-3 tapes (in the STK L700 library in Building A) onto newer LTO-4 tapes (in the HP library in Building B).

I assume that the L700 library in Building A is reaching the end of it's lifespan and will be decommissioned sometime in the near future?

[Sango]

 Hi John,

Sorry, I am not a Unix guy so I do not know what BPDuplicate can do.

So may I ask again. Base on my diagram, using the BPDuplicate command will able to transport the data from Building A VTL to Building B tape library without the use of any FC-IP converter.

Am I correct? Is BPDuplicate command really that powerful that can overcome different protocols when transporting data?

Thanks.

[John_Stockard · Accepted solution]

The bpduplicate command is not specific to Unix.  It's also present on Windows-based NetBackup media servers.

The short answer to your question is "yes".  The bpduplicate command is used by NetBackup to create another copy of a NetBackup backup image.  This can be a disk-to-disk, disk-to-tape, tape-to-disk, or tape-to-tape copy operation -- NetBackup doesn't really care about the specifics of the source and destination as long as both the source and destination are connected to NetBackup media servers.  The source and destination for the duplication job don't have to be attached to the same media server as long as there is TCP/IP connectivity between the two media servers.  The two media servers also don't have to be running the same operating systems -- the media server in Building A could be a Windows server and the media server in Building B could be a Solaris server, and it would still work.

The bpduplicate command can also be automated using the Vault add-on for NetBackup or by using the Storage Lifecycle Policy option (in NetBackup 6.5.x).  Note that both of these options require additional NetBackup licenses.  The Vault add-on is licensed based on the number of tape drives that will be used to perform duplications.  The Storage Lifecycle Policy option is enabled by the "Standard Disk Option", "Enterprise Disk Option", or "PureDisk Deduplication Option" licenses, all of which are licensed on a front-end terabyte basis (the amount of data sitting in your customer's client computers that they want to protect, not the amount of disk space in their VTLs or backup-to-disk appliances).

Your customer can definitely use bpduplicate to take backup images off of the VTL in Building A and write them to the LTO-4 drives in Building B.  However, they should be fully aware that they will be sending the backup images over the 10Gig TCP Ethernet connection between the two buildings, which might have an impact on other TCP traffic that might be trying to use that same connection at the same time.  They should also be aware that they might not achieve the highest possible speeds on their LTO-4 tape drives when using this approach, since the 10Gig link between the buildings might become a bottleneck.

[Sango]

Hi John,

Thanks for your precious advice. I really appreciate it. :)

Once again, thanks.