Scott,

 

Thanks so much for your reply.  So if I understand correctly, I add the
following in the bp.conf on the master server FORCE_RESTORE_MEDIA_SERVER
= nbumedia2 where nbumedia2 is the name of the media server I want to
use for restores ?

 

I had no idea that this was by design when using OST but it certainly
makes sense.

 

Thanks,

 

Mark Glazerman

Desk: 314-889-8282

Cell: 618-520-3401

P please don't print this e-mail unless you really need to

 

From: Kendall, Scott [mailto:scott.kend...@twcable.com] 
Sent: Thursday, February 23, 2012 10:41 AM
To: Mark Glazerman; VERITAS-BU@MAILMAN.ENG.AUBURN.EDU
Subject: RE: [Veritas-bu] Issues with media server dedupe pools
/replication / restores ??

 

It's by design.  OST will try to use the "least busy" media server with
credentials.  Media Host Override is one way to get around the behavior
and get it to do what you want.

 

http://www.symantec.com/docs/TECH74646

 

 

From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Mark
Glazerman
Sent: Thursday, February 23, 2012 10:50 AM
To: stefanos; VERITAS-BU@MAILMAN.ENG.AUBURN.EDU
Subject: Re: [Veritas-bu] Issues with media server dedupe pools /
replication / restores ??

 

Stefanos,

 

We understand that the typical behavior or NBU is to look for the
primary image on the primary storage and to look to restore it to the
primary client.  That is what we want to occur with each of these
restore attempts.  We will only ever want the remote media server to
handle restores at time of disaster (or testing) when we promote all
copy 2's to become primary images.  

 

What does the media host override do ?  

 

If we delete the DR media server from the storage server, our
replication jobs between the pools fail with a 2101 (NBU status: 2101,
EMM status: Media server not found in EMM database (2101)) because our
primary pool does not have the credentials required to push the
duplicated images to the remote pool.  How would I setup an SLP to
backup to the local pool and replicate to the remote pool if the local
media server cannot see / access the remote pool ?

 

Thanks for your input,

 

Mark Glazerman

Desk: 314-889-8282

Cell: 618-520-3401

P please don't print this e-mail unless you really need to

 

From: stefanos [mailto:sm...@peppas.gr] 
Sent: Thursday, February 23, 2012 9:40 AM
To: Mark Glazerman; VERITAS-BU@MAILMAN.ENG.AUBURN.EDU
Subject: RE: [Veritas-bu] Issues with media server dedupe pools /
replication / restores ??

 

Typical,

The DR media server is trying to read the primary image from the primary
storage server are send it back to the  primary client.

 

One way to resolve this is to use the "media host override" option. 

Another way is to delete the DR media server from the primary storage
server and configure the SLPs accordingly.

 

And upgrade to 7.1.0.3. It has many fixes to deduplication

 

stefanos

 

From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Mark
Glazerman
Sent: Thursday, February 23, 2012 5:22 PM
To: VERITAS-BU@MAILMAN.ENG.AUBURN.EDU
Subject: [Veritas-bu] Issues with media server dedupe pools /
replication / restores ??

 

I'm wondering if anyone has observed strange behavior like this with
regard to media server dedupe pools and associated replication and
restores.

 

Here's our scenario...

 

We have 2 media server dedupe pools setup.  One hangs off a local media
server.  The other hangs off a media server at our DR site.  The local
pool has the credentials of the remote pool (to enable push
replication).  The remote pool doesn't have any extra credentials
although we'd ideally like to setup a pull replication setup where the
remote pool has the credentials of the local pool and initiates the pull
of images).

 

We backup to the local dedupe pool and then have an SLP which duplicates
those images to the pool hanging off the remote media server.

 

All the primary backup images are in the local pool.  All the copy 2's
are in the remote pool.  Data in both pools has the same retention.

 

If all of that is in place and backups and replication are working, when
we're asked to restore a file who's primary copy is in the local pool,
it will try and route the backup through the remote media server (which
doesn't have the primary image).  The restore job will just sit there
until we cancel it.

 

The only way we have found to resolve this issue is to remove the
credentials of the remote media server from the local media server
dedupe pool (which disables our ability to replicate data between the 2
pools), reboot all NBU machines (master server and media servers) and
the restart all the NBU services.

 

Once this has been done, restores look automatically at the local media
server (where the primary image always resides) and the restore is
successful. 

 

Support are being as good as useless so I'm reaching out to you fine
folks to see if anyone has any advice.

 

NBU environment is 7.1 solaris x86 master, 7.1 media servers on windows
2008 R2. 

 

Thanks,

 

Mark Glazerman

Enterprise Storage Administrator

Spartech Corporation

Desk: 314-889-8282

Fax: 314-854-8282

Cell: 618-520-3401

mark.glazer...@spartech.com <mailto:mark.glazer...@spartech.com> 

http://www.spartech.com <http://www.spartech.com/> 

P please don't print this e-mail unless you really need to

This e-mail and any files transmitted with it are confidential, are
intended solely for the use of the addressee, and may be legally
privileged. If you have received this email in error please notify the
sender immediately, and do not copy or forward it.

 

 

________________________________

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.

_______________________________________________
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Reply via email to