Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Duplication on FT

Created: 03 Mar 2013 • Updated: 03 May 2013 | 8 comments
Vipluv's picture
This issue has been solved. See solution.

How do duplicate backup images (Disk to Disk) on FT? What are the prerequisite?

Comments 8 CommentsJump to latest comment

Nicolai's picture

You can't do that. Fibre Transport (AKA Fibre Transport Layer) is a method of moving data from a client to Netbackup media server. The backup image is then written to tape or disk at the media server. Duplication of images will use the media servers back end connection - either SCSI or Fibre Channel.

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

RLeon's picture

If you are referring to:
Client -----(Backup via Fiber)----->MediaServer1-----(Duplication via Fiber)----->MediaServer2

... then the only possible configuration that would allow this involves the use of AdvancedDisk:

 

Client role:
- SAN Client

MediaServer1 roles:
- FT Media Server
- AdvancedDisk Storage Server managing LUN1

MediaServer2 roles:
- AdvancedDisk Storage Server also managing LUN1
- Destination storage such as MSDP, Tape, etc.

LUN1:
- This is a SAN array LUN mounted by both AdvancedDisk media servers; running a Clustered File System such as VxFS and CXFS.

 

With the above configuration in place, no data will travel via LAN during backups or image duplication:

1. The SAN Client sends its data via FC to MediaServer1.
2. MediaServer1 stores the data in the AdvancedDisk disk pool (LUN1), which is also mounted by MediaServer2.
3. With the used of the alternate read host feature, MediaServer2 reads via FC the backup images from LUN1, then duplicates them to the final destination - which could be another SAN LUN, or FC Tape Drives.

 

The above is actually pretty similar to a common configuration in shared tape library environments.
In this case, sharing a tape library between media servers has the same effect as sharing the AdvancedDisk storage in the above example.

If you are using MDSP or OST storages, I would recommend using Optimized Duplication between your media servers, instead of using AdvancedDisk and Clustered Files Systems.

 

Since you are enquiring specifically about "duplicate", "disk to disk" and "FT", I interpreted that you wanted to do LAN-free duplications between media servers.

Marianne's picture

RLeon, shared disk is no longer supported as from NBU 7.0.

Client -----(Backup via Fiber)----->MediaServer1-----(Duplication via Fiber)----->MediaServer1 will work.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

RLeon's picture

Marianne,

I am not referring to the obsolete feature named SharedDisk that was under the Flexible Disk Option in 6.x, as described in this document:
http://www.symantec.com/business/support/index?pag...

1.2    SharedDisk support
Note that support for SharedDisk is available only with NetBackup 6.5.x and will not be included in NetBackup 7.0.  SharedDisk support will be withdrawn with NetBackup 6.5.x support on 3rd October 2012.

 

I am talking specifically about about AdvancedDisk Sharing:

2.1.1    AdvancedDisk sharing
The concept of AdvancedDisk sharing was introduced in NetBackup 6.5.2 and allows storage that can be mounted against the same mount point on multiple Media Servers such as storage presented over NFS or using Storage Foundation Cluster File System, Lustre or CXFS, to be placed into disk pools and shared between those Media Servers.  Storage presented is this way is accessible to all the Media Servers at the same time and remains mounted at all times while server is up.

 

Best practice for configuring AdvancedDisk:
http://www.symantec.com/business/support/index?pag...

AdvancedDisk sharing
The concept of AdvancedDisk sharing was introduced in NetBackup 6.5.2 and allows storage that can be mounted against the same mount point on multiple Media Servers such as storage presented over NFS or CIFS or clustered file systems such as Veritas Cluster File System, Lustre or CXFS, to be placed into disk pools and shared between those Media Servers.  Storage presented is this way is accessible to all the Media Servers at the same time and remains mounted at all times while server is up.

 

Unlike SharedDisk, the new AdvancedDisk Sharing feature is available in 7.x.
Volumes do not "failover" between media servers; they can be mounted and written to concurrently by multiple media servers because of the use of Clustered File Systems.

Vipluv's picture

Hopefully Nicolai has answered the question but then also wants to explain details which I missed earlier (just wanted to re-confirm that there is no way out)

Missed to inform about backup environment earlier:
We are in process of duplicating all old image by bpduplicate command. NBU environment has 2 media servers and Storage unit is configured through OST (AdvancedDisk sharing with CIFS). Storage is communicating with both media servers (not with master server). All the LSU resides on same Storage.

When running bpduplicate to copy image manually from source storage units to destination storage units, Transport type as LAN.
Media 1 -> Media 1,
Media 2 -> Media 2,
Media 1 -> Media 2 and vice versa

Can we duplicate backup images on FT or any way to speed up the duplication task?

Marianne's picture

OST appliance is network attached, not SAN.
Backups as well as OST -> OST duplication is taking place over the network. Your topology diagram should confirm this.

Only when duplicating OST -> tape on certain OST appliances (Quantum for example) can tape be direct/SAN attached to appliance.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

RLeon's picture

Media 1 -> Media 1
This is already duplicating as fast as it gets.

Media 2 -> Media 2
Same as the above.

Media 1 -> Media 2
Make sure you use the -altreadhost Media2 switch in the bpduplicate command, and that the -dstunit switch is a storage-unit attached to Media2.
What that means is, even though the image was written by Media1, the duplication job will use Media2 to read the data from the OST storage, then write it to the locally attached storage unit defined in -dstunit.
If you do not use -altreadhost, the data will be read by Media1, sent via LAN to Media2, before getting written to Media2's storage unit, which can be very slow.

Media 2 -> Media 1
Same as the above, but the other way around.
Use the -altreadhost Media1 switch in the bpduplicate command, and the -dstunit to a storage-unit attached to Media1, so that data will not travel through LAN between the media servers.

 

 

Can we duplicate backup images on FT or any way to speed up the duplication task?

Please note that even if your OST storage is connected via SAN/FC/FT instead of LAN/network to both your Media Servers (Example: Hitachi HUS100 OST storage), when you duplicate images from Media1 to Media2, unless you use -altreadhost (alternate read host), data will still go through the LAN between Media1 and Media2.

If your OST storage is connected to the media servers via LAN/network, then duplication via SAN/FC/FT is not possible.

SOLUTION
Marianne's picture

Can we assume that you have 2 OST appliances? 
Maybe one in production site and one in another building for DR purposes?
All media servers can see both appliances (via network) and have STU's configured for both?

So, if backups are done to STU called Media1-OST1 and you duplicate backups to Media1-OST2, then data transfer will happen across the network between OST1 -> OST2.
Media1 is merely starting the job and monitoring it via bptm and bpbrm processes.
If OST1 and OST2 is configured with private 10Gb network, you should see excellent transfer rates.

Maybe best if you give us full details of your configuration?

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links