Okay, gang, since I was away, I see that my original posting titled:
"Merits of cloning versus dual backups?" has since created a firestorm
of questions in this area of multi-plexing versus de-multi-plexing of
data when cloning is involved. I read all of the replies -- can't say
that I completely understand all of the nitty gritty -- and I must say
that I am impressed with the level of detail that this discussion has
gone into, but I'm not clear that there was ever a final word or
agreement on this issue. I did some testing, and I thought I'd present
this and see if there's a final word here, or if I'm just in the dark.
I backed up 4 clients to one tape (scratch.001) for a total of 15
savesets. Only one drive was used with a parallelism of 5. The sessions
was never exceeded. 5 was the max I ever saw writing at one time.
Clearly, some, if not all, of the savesets are multi-plexed or
interleaved onto the target volume (scratch.001) if I can use that term.
I then created 4 clone volumes (scratch_c.001 - 004) as follows:
1. nsrclone -s server -b 'Scratch Clone' -S ssid1 ssid2 ssid3 ....
ssid15
2. nsrclone -s server -b 'Scratch Clone' -S -f file
where file contained a list of all 15 ssids in the same order as listed
in option 1.
3. nsrclone -s server -b 'Scratch Clone' -V scratch.001
4. I looped through the file used in option 2 and then directed this to
an nsrclone command to clone just that ssid. So, in essence, I ran a
separate clone process for each of the 15 savesets.
I wanted to keep the test as fair to each option so I mounted all of the
clone volumes before running any of the tests in order to avoid any hang
time from ejects, mount operations, etc. All options produced the same
end results, but option 4 was very slow (no surprise, I'm sure) due to
the obvious fact that various rewinds and fast forwards were required
during each invocation of the nsrclone command. I don't think I even
bothered to time this. Options 2 and 3 were nearly identical in speed.
Option 1 was about 40 odd seconds slower than options 2 and 3.
>From what I can tell, NetWorker would have to de-multiplex the data
before it clones it because it clones the savesets one at a time
regardless of the method. This is obvious from the devices window. I can
see the devices window listing 1 of 15, 2 of 15, 3 of 15 ... 15 of 15.
The data was clearly multi-plexed when it was written to the source
tape: scratch.001, but since NetWorker has to read it -- just like it
would if you were recovering it -- before it can write it, and it's
writing the savesets one at a time, if MUST be de-multiplexing it,
right? Now, perhaps this changes when you're cloning an entire volume as
opposed to just specifying individual savesets, but it's been mentioned
by several people that cloning a volume does not imply making an exact
copy of it but rather a clone of each saveset -- a different concept all
together. Thus said, this is the same as cloning each one individually,
although a lot faster.
When you're writing one saveset at a time, you're not multi-plexing. I
asked Legato about this business with clones, and they agreed that it is
not re-multiplexing the data when it clones, and is in fact
de-multiplexing since it has to read the saveset before it can write it
to the clone copy, and it can only read one at a time. So, if the
saveset that is being read was multiplexed onto the source tape then
it's being de-multiplexed to read it and thus it will remain that way on
the clone since it never writes more than one at a time to the clone.
So, recovers from clones should be indeed be faster since there's
nothing to de-multiplex.
Does anyone have any comments. I'd like to hear them, please? I suspect
I may have overlooked something in my thinking and could be drawing
false conclusions.
Thanks.
George
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
