ADSM-L

Re: [ADSM-L] SV: Suggestion for Archive?

2008-01-03 10:23:19
Subject: Re: [ADSM-L] SV: Suggestion for Archive?
From: Henrik Wahlstedt <SHWL AT STATOILHYDRO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Jan 2008 16:22:30 +0100
Hi,

Everybody seems to fancy backupsets, exports and archives. I think Lloyd is 
right here suggesting normal backup under a different nodename.
Normal monthly/yearly backups wont punish your DB so much as archives and you 
should be able to live with one TSM server instance.
It is your Filers that will kill TSM if you try to archive them monthly with 10 
years retention... Just test and let me know if I am incorrect. :-)


//Henrik


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Lloyd Dieter
Sent: den 3 januari 2008 16:01
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] SV: Suggestion for Archive?

Christian,

Is the primary tape pool collocated?  If not, I'd strongly recommend it 
(although it's probably too late to help you with this issue).  I collocate all 
of my primary sequential access pools, and control usage with maxscratch and 
collocation groups.

Do you have enough space in your disk pools to do a "move nodedata" from tape 
to disk pools in preparation for the generate backupset or export operation?

The other option I've used is to define "monthly" or "yearly" nodes, with 
different node names, schedules and retention settings.  For example, "node_a" 
for the dailys, "node_a_monthly", "node_a_yearly".  It's a nuisance to set up 
on the client side, but works well once it's in place and avoids database bloat.

I think that you're going to have issues doing many archives like that, 
especially for your anticiptade growth...even if it gets you past the immediate 
issue.

Don't forget that you can set up a second TSM instance on the same physical 
box...that might help for what your'e trying to accomplish.

-Lloyd


On Thu, 03 Jan 2008 13:58:20 +0100
Christian Svensson <christian.svensson AT CRISTIE DOT SE> wrote thusly:

> Hi Lloyd,
> We have tried Backupset for a wild now but we see that it takes approx
> 3 weeks to archive all 300 nodes. If the backupset fails then do we 
> need to restart the entire job and we are getting behind the schedule.
> We looking at to create smaller "node groups" but still it takes a 
> long time. :(
> 
> I was thinking to maybe setup a second TSM Server and export the data 
> from one server to the other and that maybe can reduce the time. I'm 
> guessing that the problem is probably all tape mounts that is required 
> to collocate all data so maybe that is something to look at?
> 
> Or what do you think?
> A good information to know is that the end-user looking at to grow up 
> to 100 TB in the next 4-5 years.
> 
> Thanks
> Christian
> 
> -----Ursprungligt meddelande-----
> Från: Lloyd Dieter [mailto:ldieter AT ROCHESTER.RR DOT COM]
> Skickat: den 3 januari 2008 13:09
> Till: ADSM-L AT VM.MARIST DOT EDU
> Ämne: Re: Suggestion for Archive?
> 
> Christian,
> 
> This sounds like an excellent use for backupsets, or else possibly 
> periodic exports.
> 
> Other sites have a second instance of TSM that is used for periodic 
> large backups and long-term retention requirements.
> 
> I generally discourage archives for large amounts of data, due to the 
> DB entries that are created, as well as the amount of time required to 
> create those archives.  The only sites that I have with "out of 
> control" database growth are attempting to do what you describe.
> 
> -Lloyd
> 
> 
> 
> On Thu, 03 Jan 2008 11:09:13 +0100
> Christian Svensson <christian.svensson AT CRISTIE DOT SE> wrote thusly:
> 
> > Hi all,
> >
> > I hope you all had a great new year.
> >
> > Just a quick question.
> >
> > Has anyone tried to archive 20 TB data every mouth for 10 years? If 
> > yes how are you doing that and how is your environment looks like?
> >
> >
> >
> > Happy New year
> >
> > Christian


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.

<Prev in Thread] Current Thread [Next in Thread>