Fazil Saiyed wrote:
Helo,
With all the factors involved in cloning, i have enough doubt to re-
consider cloning.
1. With all the flags and cloning considerations, can it be fully
automated in VTL inviroment or is it going to be daily headach ?
I'm sure it can be. To make it really simple, you could just test
enabling automatic cloning on your groups. We do this with a few groups,
but we're not using a VTL. I would think with a VTL that your speed
would be so much faster to tape, since you're writing directly from
disk, that having automatic cloning turned on for the groups would be
less of an issue? Now, if your PTL is not directly attached to the
server or snode, and you're instead sending, say, iscsi packets over the
network or some SAN to the PTL from the VTL then there would be more of
a delay, but still shouldn't be enough to hinder you too much, at least
not like not having a VTL [sigh]. A script could be run daily that
checks the status on completed and cloned save sets and emails a message
if anything looks awry.
As some have suggested, however, with VTLs, you might be better off
increasing the number of virtual devices to as many as you can legally
run and decreasing the number of target sessions on those devices, maybe
even down to 1. This way, there's less to unmultiplex (or even nothing
to unmultiplex in the case of 1 target session) when cloning from
virtual tape to physical tape which would make cloning faster. Now,
there was a big discussion on this forum some time back about cloning
and multiplexing, and I'm not sure what the final consensus was. Some
felt that multiplexing is preserved during cloning, others felt it was
not, and still others believed that it could vary depending on the
amount and size of the data that was being cloned and/or how it was
being cloned? I just can't recall the upshot of the whole thing. My head
was numb after the first several threads. And I'm not sure about staging
either., as far as via a VTL. I would probably just do it using
automatic cloning and then monitor it and see how it goes. The simpler
you can keep your operations and still have things work, the better.
2. There seems to be enough factors that could fail or raise doubt on
cloning process whereby making it hit or miss and unreliable for rescovery.
I think it's reasonably reliable, and I dare say it would be far more so
in a VTL environment. Cloning does work, and has proved itself many
times in many shops. As you pointed out earlier, it's nominally a way to
identify a bad or suspect 'original' tape. Of course, nothing is bullet
proof. There's always the chance that something could slip under the
radar, but that's life and certainly no reason to abandon ship. A
practical solution will cover you in most "reasonable" cases. Sure,
there are always "fantastic" scenarios, but your script is a good start,
and you could make a few tweaks and/or consider a few other options to
enhance it further. If you discover a flaw, fix it. It's up to you to
determine if those have merit and to what extent they do. Cloning is
better than not cloning period. Furthermore, you could do something like
clone all your fulls, keep one set off site, one set on, and then ditto
for the next batch, but then at some point maybe recycle older clone
tapes, so maybe you have, say, a 3 month rotation? The main purpose in
cloning is not only to afford you a temporary copy that's physically
stored elsewhere but also to validate the original data and give you an
opportunity to rerun a backup wherein the cloning identified a problem.
Again, nothing is full proof, but cloning is gonna cover you in 99% of
the cases.
3. Seems like extensive scripting may be required to acomplish it.
Not really. Your script seemed reasonable. You could just add another
check that uses '-v', and looks at the status of the save set, along
with the clflags and ssflags, too. I have seen some cases wherein a
saveset was identified as having a 'copies' value of 2 even though the
clone failed, but cloning works most of the time, and there should be
other signs of a problem that would clue you in that the clone was not
successful or cannot be trusted - namely, the clflags value, but
looking at the ssflags and results of '-v' can't hurt except maybe
adding a little more processing time to your script. Maybe send e-mail
if something doesn't look right, but don't clone, or maybe try to clone
but also send email? This way you're alerted to a possible situation -
kind of a heads up.
4. What if any effects are on missing the window for sending tapes offsite
due to failed cloning etc exists.
Clearly, the longer the original tapes and the clone counterparts remain
on site the greater chance for an issue. You want them in different
locations as soon as you can reasonably do so. However, just because
there's, say, 10 failed save sets or 'suspect' save sets that you want
to re-clone or manually clone or look at more closely before cloning -
like maybe run a scanner command against the affected original tape(s)
or whatever - well, that doesn't mean that that has to hold you up from
taking the other tapes off site. You could re-clone those to a temp
pool, and then take the temp pool tapes off site later.
5. What may be advantage disadvantage related to cloning at saveset level
vs volume.
Maybe you don't want to clone everything on there? I've never cloned by
volume. I've always used the CLI, and just specified ssids (typically
using something like 'nsrclone -s server -S -f /tmp/inputfile.txt). I
think doing it by ssid might give you better control. Also, if there are
any original save sets that your script determined were suspicious then
you could work around those when doing it by ssid. However, you could
not do that when doing it by volume. Also, you have to keep in mind that
one or more save sets will span to another volume. Pretty much every
volume is going to have one or more save sets that span. I'm not sure
how newer versions of NetWorker deal with this when cloning. My
experience was that it always wanted to continue with the next piece.
So, cloning by ssid might give you more flexibility wherein you could
have multiple clone operations going on simultaneously such that each
operation is working on a different list of ssids that don't overlap,
i.e. none of them is from the same source tape. You then exclude the
ssids that do overlap, and then you come back to those later; you do
those last. Doing it by volume would negate that ability.
6. Can the users of this forum relate thier cloning experiance\restores
for people who have done it over 6 months in medium to large enviroment,(
50+ servers).
I've related that.
7. I am looking for that comfort level and not fininding it in cloning
operations.
Again, a clone is better than no clone for reasons I've stated.
Please relay your general openion on this subject apart from technical
difficulties.
Thanks
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
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
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
|