Re: [Networker] NetWorker 7.6 SP2 restoring while cloning

How about by creating multiple Boost devices from within the NetWorker
console manager in order to gain a bit of flexibility?

My DD system is brand new, so the latest firmware and OS are on it. Same
with the 64-bit RH Linux box to which it is connected. The DD system is
connected to the NetWorker server via a dual channel 10GB card with
private Ips. So I am wondering if I can create a second DD Boost device
within NMC the use one device to back up a group of clients who's backups
all need to start at 9:00pm and also back up a second group that needs to
start at a different time. Then both devices can clone to each of the two
LTO-5 tape drives at my disposal without the first clone process delaying
the second one. Does that sound like a reasonable plan?

On 5/10/2011 2:00 PM, "Yaron Zabary" <yaron AT ARISTO.TAU.AC DOT IL> wrote:

>   Yup, seen this as well. Before I fixed my mminfo to query the RO
>device, I started to notice that backups that were running at that time
>were blocked and waiting for the stage to finish.
>
>   Anyhow, this is a kludge and there is no excuse for no true
>concurrent access to AFTD after so many years. This is also an absurd
>because if you create an nsrmmd for each read or write session, you will
>be able to better utilize the new quad cores CPUs.
>
>On 05/10/2011 05:28 PM, Thierry Faidherbe wrote:
>> Earlier, by change, I found "a way" to recover during
>> clone/stage on an AFD dev at same time :
>>
>> The trick is not to restore using client file index
>> (recoveries browsing files) but recovering using
>> SSID/Cloneid :
>>
>> Query the SSID/CloneID of the SS you need to recover.
>> If the SSID copy has not be staged and purged yet
>> (in other word, still on AFD), you will get at least
>> 2 different cloneid, one for each copy of the ssid
>> (one on the write enabled AFD volume,
>>   one for the read-only AFD volume).
>>
>> eg :
>>
>> SSID      CLONE ID    Name  Volume
>> 12345678  123456789   c:\   Test
>> 12345678  123456790   c:\   Test.RO
>>
>> When AFD read-only part is reading (for recover,clone or stage, doesn't
>> matter),
>> if you recover using SSID/Cloneid and use Cloneid of the SSID copy from
>> the Write-enabled volume like
>> "recover -S 12345678/123456789 [-d<alternate_loc>] path_to_recover"
>> it will read from write-enabled AFD device while the
>> read-only one is reading.
>>
>> I discovered it by chance, when scripting new staging batch
>> when I did forget to specify ".RO" in<volume>.RO name in
>> piped mminfo for staging cmd during operators did recover using GUI.
>>
>> Not using that trick very often but it worked each time in
>> case of emergency recover.
>>
>> HTH
>>
>> Th
>>
>>
>> Kind regards - Bien cordialement - Vriendelijke groeten,
>>
>> Thierry FAIDHERBE
>> Backup/Storage&  System Management
>>
>> LE FOREM
>> Département des Systèmes d'Information
>> Direction Infrastructure
>>
>> Boulevard Tirou, 104  Tel:    +32 (0)71/206730
>> B-6000 CHARLEROI      Mobile: +32 (477)/995319
>>                        Fax:    +32 (0)71/206199
>> BELGIUM               Mail : Thierry.faidherbe<at>forem.be
>>
>> -----Message d'origine-----
>> De : EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] 
>> De
>>la
>> part de Yaron Zabary
>> Envoyé : samedi 7 mai 2011 16:12
>> À : NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Objet : Re: [Networker] NetWorker 7.6 SP2 restoring while cloning
>>
>> On 05/06/2011 11:19 PM, STANLEY R. HORWITZ wrote:
>>> I know in earlier NetWorker versions, doing a restore from an advanced
>>> file type device while it is sending data to another device for cloning
>>> wasn't possible. I am testing 7.6 SP2 RA with a new Data Domain and it
>>> seems that same limitation is present. Does anyone know a way around
>>>that
>>> where files can be recovered from a DD Boost device while it is being
>>> cloned?
>>
>>    Come on Stan, let's not be naive about that. EMC had years to fix
>>this
>> issue and the reason they didn't was that a too good AFTD (maybe even
>> with dedup, like PureDisk) will compete with their VTLs. Now that they
>> own Data Domain (and BRS is actually DD), they need to fix it, but I am
>> pretty sure that you will not see any improvements for AFTD without DD
>> (that is why DD boost is here).
>>
>>>
>>> To sign off this list, send email to listserv AT listserv.temple DOT edu and
>>>type
>> "signoff networker" in the body of the email. Please write to
>> networker-request AT listserv.temple DOT edu if you have any problems with 
>> this
>> list. You can access the archives at
>> http://listserv.temple.edu/archives/networker.html or
>>> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>>
>> To sign off this list, send email to listserv AT listserv.temple DOT edu and
>>type
>> "signoff networker" in the body of the email. Please write to
>> networker-request AT listserv.temple DOT edu if you have any problems with 
>> this
>> list. You can access the archives at
>> http://listserv.temple.edu/archives/networker.html or
>> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>>
>
>To sign off this list, send email to listserv AT listserv.temple DOT edu and
>type "signoff networker" in the body of the email. Please write to
>networker-request AT listserv.temple DOT edu if you have any problems with this
>list. You can access the archives at
>http://listserv.temple.edu/archives/networker.html or
>via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER