Saveset chunks are written to the tape when a reasonable sized chunk is ready
to go (I'm sure there's a better technical explanation for how this is handled,
but that works). What this results in is a tape which has savesets like:
| A | B | C | A | B |A|
C |
To recover that data, you'd need to read chunks, position the tape, read more
chunks, etc. When you clone those savesets to another tape, what you end up
with is more like:
| A | B | C
|
because the drive has already done the recovery once and written that in full
to another tape. Now, you not only have confirmed that the backup is good by
confirming that the original can be read, you've helped speed up a recovery by
giving the system a single chunk of data to read (subject to the write speed of
the disks being anywhere close to the read speed of the tapes). By creating a
copy, you've also got the possibility to recover at least 2 servers
simultaneously going on your previous discussion about this. And if you can
offsite the second jukebox, you've now got an offsite copy of the data in case
of site disaster. The only problem is to force NetWorker into choosing the
right volume (between original and clone) for the recovery.
Otherwise, man nsrclone should tell you all you need.
Cheers,
Stuart.
________________________________
From: EMC NetWorker discussion on behalf of Ben Harner
Sent: Sun 24-Sep-06 22:21
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Backup Pools
Good point. Could you explain more on the clone process(the shed)?
Thanks
Ben
----- Original Message -----
From: Stuart Whitby <swhitby AT DATAPROTECTORS.CO DOT UK>
Date: Friday, September 22, 2006 4:49 am
Subject: Re: [Networker] Backup Pools
> The problem you'd have by going to multiple pools is that your
> single drives would be stuck with one pool anyway, and any
> overnight backups to the jukebox would have to wait for other
> clients to finish in order to change the tape so that they can use
> the one for their own pool. If you get a hung saveset on the first
> jukebox backup, you don't get any further jukebox backups that
> night as the tape will not be ejected and you have no spare
> capacity to load tapes for other pools.
>
> My personal preference is to keep pools as simple as possible and
> base this on retention policy. One pool for each retention period
> (and keep as few as reasonably possible) and one for indexes and
> bootstrap.
> If you're specifically looking at improving recovery times, I'd
> recommend getting a similar but seperate jukebox to clone to,
> preferably one which is based offsite (put it in a shed with power
> & a fibre connection out the back of the office). If you're
> looking at using all your drives to recover 3 systems at once, it's
> because you've had a site based failure, and the benefit of cloning
> in this way is that you have easily accessible offsite (or "out of
> office" with my shed suggestion) backups which are also based on
> saveset rather than tape. ie, you have one continuous saveset on
> tape which can just be streamed back to the server. You *can* do
> this to different tapes on a server by server basis, but that's
> scripted wizardry rather than default option.
>
> In this case, I'd rather make sure you get the backups and know
> that recoveries will happen eventually rather than run the risk of
> not getting backups but having great recovery times when you do.
>
> Cheers,
>
> Stuart.
>
> ________________________________
>
> From: EMC NetWorker discussion on behalf of Ben Harner
> Sent: Thu 21-Sep-06 19:46
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Backup Pools
>
>
>
> Well first we have a IBM LTO 3581 jukebox and a IBM LTO 3580 single
> drive. We 1000 mbps throughput. But the backup server only has a
> 100mbps card. There are 17 clients. At full backups 5 clients
> are at
> least 100gb - 200gb per client. And the others are between 30 and 60
> gb. 5 groups are single client and are the larger clients, 1 is
> doubleclient median in size and 1 group has 9 clients which are
> smaller save
> sets. 15 clients are using the jukebox and 2 are using the single
> drive. We have another single drive but that is used by a different
> department but would be accessible to us in a disaster recovery
> operation if need be which is why I was looking into breaking up are
> most important server into different pools as to aid in a quicker
> recovery. If more than one server was to crash we could recover 3
> servers simultaneously if we know for sure that the servers are on
> different tapes.
>
> Thanks for the help
>
> Ben
>
> Stan Horwitz wrote:
> > On Sep 21, 2006, at 1:50 PM - 9/21/06, Ben Harner wrote:
> >
> >> Thanks for the reply. So if I have a jukebox with 7 slots and
> say I
> >> have 4 different pools with 1 to 2 tapes for each pool you think
> >> there would be long waits between backups? Shouldn't it be only
> the>> wait of the jukebox changing the tape? Right now all session
> have to
> >> wait for the previous one to finish per tape drive so wouldn't that
> >> be the same either way? Right now I have 15 clients being
> backed up
> >> nightly to one tape drive using one pool. I am trying to get it
> so I
> >> can specify certain tapes for certain clients. I'm guessing the
> only>> way to do that is through pools. Is there other ways?
> >
> > Possibly. Its difficult to say without knowing how much data
> would go
> > to the individual devices and how fast the throughput is. Answering
> > your question would be easier if you explained what your hardware
> and> network environment is like and the amounts of data involved.
> >
> > 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
> > wit 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
>
> 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
> wit 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
>
>
>
> 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
> wit 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
>
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
wit 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
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
wit 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
|
