Networker

Re: [Networker] Simple UNIX Clone script - for use by community (UPDATED)

2007-04-10 14:38:38
Subject: Re: [Networker] Simple UNIX Clone script - for use by community (UPDATED)
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 10 Apr 2007 14:35:58 -0400
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