Networker

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

2007-04-12 06:57:50
Subject: Re: [Networker] Simple UNIX Clone script - for use by community (UPDATED)
From: "T. S. Kimball" <t.s.kimball AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 12 Apr 2007 06:56:03 -0400
Apologies for the delayed response, I'm having an interesting April...

My own experience has been both with tape->tape (LTO & DLT) and disk->tape
(using adv_file to DLT then later LTO).  Over 90% of my backups now goto a
big 60TB disk array first (sliced up into multiple adv_file devices) and the
first array we tried this concept with was rather... problematic.  So it got
drummed into me fast to be certain that we had clone copies made ASAP, and
they were accurate.

Specific answers below.  I have no experience with VTLs so that question was
skipped.


On Mon, 9 Apr 2007 11:39:15 -0400, Fazil Saiyed <fazil.saiyed AT ANIXTER DOT 
COM>
wrote:

>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 recovery.
>3. Seems like extensive scripting may be required to acomplish it.

I've depended on my clones in several cases (and in one DR case clones of
clones!) and so far have been OK (in particular the past couple years when I
refined my scripts).  I personally think that if you're willing to allow the
occasional missed backup or clone (say once in a month) simple scripts will
be fine.  Its the shops like ours that have very high obligations/SLAs where
the 'fun' starts.

My scripts are somewhat insane to catch several cases, such as the ones
discussed here (flags etc.), but a cursory check of one of my adv_file
volumes just now show that even *then* one or two backups can get missed in
the cloning grab (though a handful of missed clones within a year is not
bad).  It's organically grown over the years due to audits like that.

It includes server counts before and after the cloning (in case some got
missed during the operation), pages for inconsistencies, and a config file
that can set variables based on what the source is.

>4. What if any effects are on missing the window for sending tapes offsite
>due to failed cloning etc exists.

We send the volume out anyway; Our daily outgoing tape only fills half an
LTO-2 volume, so its no big deal to clone them manually into the next day's
tape.

>5. What may be advantage disadvantage related to cloning at saveset level
>vs volume.

With saveset level you have less hassle about source volumes - Important
when you have a 15 TB adv_file disk as your source!  ;)  Volume level I'd be
unable to do since I'd tie up the disk for too long.

>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).

Current environment is approximately 145 clients and growing.  About 1/4 of
them generate over half my data (daily file-level dumps of MS-SQL and
Sybase) and MUST be cloned by next morning.  And those also get hit with
recovers on a relatively constant basis in the past 6 years (hence the need
for adv_file over faster tape - helped the folks doing the recovers).

I think we've reached for a clone tape about a dozen times just in the past
couple years, and in those cases every time we were able to recover OK.

>7. I am looking for that comfort level and not fininding it in cloning
>operations.

As I said, I trust them pretty well - a hell of a lot more than I do the
source media (be it disk or tape) sometimes.  It just takes a bit of work to
get there.

>Please relay your general openion on this subject apart from technical
>difficulties.

I hope this helps.
--TSK

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