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.
_______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
