Networker

Re: [Networker] How does nsrclone order a list of SSIDs for cloning?

2009-12-22 23:30:18
Subject: Re: [Networker] How does nsrclone order a list of SSIDs for cloning?
From: Preston de Guise <enterprise.backup AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 23 Dec 2009 15:27:16 +1100
George, Brett,

On 23/12/2009, at 15:18 , George Sinclair wrote:

> bbartick wrote:
>> We recently rolled out a VTL and I'm in the process of scripting the cloning 
>> process. From the testing I've done, it seems as though nsrclone does not 
>> clone the SSIDs in the order you pass to the command.
>> I'd love to clone the oldest savesets first so that I can roll them off the 
>> VTL first.
>> I was thinking I could do something similar to:
>> mminfo -ot -q "pool=VTL1,copies=1,!incomplete,savetime<21 days ago" -r ssid 
>> --> output to a file $FILE
> 
> I've run into this many times. I think it wants to best preserve the 
> interleaving as it is on the original/source tapes. As a result, if, for 
> example, five save sets are wrapped (multiplexed) together on the original 
> volumes then that's how it wants to leave those when it writes those to the 
> clones.

Yes, since NetWorker keeps multiplexing, it needs to re-order any list of 
received savesets in the best order to preserve interleaving and prevent 
seeks/rewinds on each piece of media it encounters.

I believe, though I've not done sufficient testing, that when cloning from 
ADV_FILE -> tape you'll get the clone happening in the order requested, since 
each saveset has a file# on the disk backup unit of 0, meaning that in order of 
access they're all equal.

> However, if you instead run separate nsrclone commands for each ssid then 
> that will force it to clone each one separately. It has to. And I don't see 
> how that would eat up more space on physical clone tapes than it would if it 
> preserved the interleaving, but it will certainly take longer and is more 
> inefficient. That may not be a viable option for you, though, and I'm sure 
> you already considered that.

To be more accurate, I'd describe this as being hideously longer/inefficient. 
The reason for this is that at the end of each write operation, NetWorker will 
(for want of a better term) pause for a moment before writing the 2x EOF 
markers at the end of the media.

Thus, if you're cloning one saveset at a time, you're doing the following:

read+write
(pause)
write double-EOF

for next saveset:
backtrack one EOF
read+write
(pause)
write double-EOF

In actual fact it's about as "sub-optimal" as you can get. Furthermore, if you 
don't time it properly and you have multiple devices, you'll find that the 
first volume/device written to is still busy when you attempt to clone the 
second saveset, resulting in NetWorker wanting to conduct the clone operation 
on another drive/volume, meaning that savesets will then be spread out in a 
worst-case layout.

Cheers,

Preston.

--
Preston de Guise

http://www.enterprisesystemsbackup.com          "Enterprise Systems Backup and 
Recovery: A corporate insurance policy"
http://nsrd.info/blog                           NetWorker Blog
http://iamtheanticloud.wordpress.com            Confused about Cloud? Get a 
fresh opinion 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