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

One issue with a monthly/yearly backup/archive is that the changes that occur 
between events will not be captured.  If a file is created on March 3rd and 
deleted March 25th, a monthly backup/archive that runs on the first of each 
month will not capture this file.

One method of retaining all data that is backed up nightly would be to:
- Create the node name of the client reflecting the time period that data is 
backed up - i.e. "docserver-march08".
- At the end of each time period, change the node name to the new time period 
"docserver-April08"
- run a "export node docserver-march08...." to tape and then put that tape in a 
safe place with associated recovery documentation.  After the data has been 
successfully exported, delete all files associated with the exported node 
"docserver-march08".
- Repeat for each time period.

Your database will remain manageable.
You will maintain daily recovery granularity.
You MUST keep the recovery sequence documentation for exports which span 
multiple media.
If you change media or backup platforms, you will have a bit of work importing 
and exporting to new media but, so it goes...

Have a nice day,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Henrik Wahlstedt
Sent: Thursday, January 03, 2008 10:23 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] SV: Suggestion for Archive?

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.

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.