ADSM-L

Re: Monthly full backups with MODE=ABSOLUTE

2005-09-02 19:15:21
Subject: Re: Monthly full backups with MODE=ABSOLUTE
From: William Boyer <bjdboyer AT COMCAST DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 2 Sep 2005 19:15:08 -0400
Each node has a nodename assigned for the monthly backup <nodename>_M, and 
that's in it's own domain LONGTERM. The policy is
VERE/VERD=NOLIM RETE/RETO=2570 and it goes to it's own disk/tape pools, 
separate from the daily backups. Right now there are 179
nodes registered in that domain. Not all of them are active right now, and I 
did manage to get them to at least run the
test/dev/prod on different schedules. So they're not all trying to hit the 
system at the same day.

The daily backup of this system in 1.5TB and more. Lots of Oracle backups. I'm 
trying to get them to buy off on using compression
for the *.DBF files. They do it for test/dev and I see as high as 84% client 
side compression.

The tape is LTO-1. They have a 3584 with 4 drives and a 3583 with 4 drives, but 
right now (excluding the monthly tapes) they have
over 150 tape volumes that don't fit in the 2 libraries. I also have them 
looking for an expansion frame on the used market for the
3584. Next year they have budgeted to upgrade tape to LTO-3 fibre attached.

The database is 225GB and 87% full. Probably 3/4 of the monthly data is not on 
a copypool tape. There just isn't time and space for
enough scratch tapes plus the primary pool tapes in the library. Once they are 
done, I have to get them out of the library to make
room for more scratch tapes to allow the daily backup to continue.

I did get them to change their policy do that test/dev servers will be reduced 
to a 90-day monthly retention. For some of these
there's almost 2-years of monthly backups that will expire once I move them 
into that domain. That will also give me some space back
in the database. For a full montly rotation the DB grows by about 5%.

We are also talking about taking the monthly nodes/data to their own server 
instance. Right now the server has 3 instances: One is
the library manager instance, then there's this production instance and there 
is another created that is supposed to be the monthly
instance. It just hasn't been implemented.

There are positive things happening. I have a list of the computers that should 
be backed up and any not on that list can be removed
from TSM. I'm also producing a list of filespaces that haven't been backed up 
in 180-days. I'm not allowed to delete anything from a
production monthly backup, but if I can remove these filespaces from the daily 
data...works for me.

I've gotten a couple good suggestions and am looking into them.

Thanks for the input.


Bill Boyer
"Some days you're the bug, some days you're the windshield" - ??

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Allen S. Rout
Sent: Friday, September 02, 2005 6:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Monthly full backups with MODE=ABSOLUTE

==> On Thu, 1 Sep 2005 11:21:39 -0400, William Boyer <bjdboyer AT COMCAST DOT 
NET> said:

> I have a client with requirements for full monthly backups being
> retained for 7-years. 2-years ago we set them up with monthly
> schedules in a domain with the copygroups set to MODE=ABSOLUTE. Now
> these backups are running forever and I think it has to do with so
> many versions of the files and an INCREMENTAL schedule. The admin of
> ths shop has said that the monthly backups take longer each month.


> My question...would setting -INCRBYDATE help with this? These backups
> MUST be a FULL. No choice on that.


What are your retention parameters for those nodes?   If you're not separating
the monthly-full nodes from the nightly nodes, you've surely got VEREXISTS 
higher than 48, right?  Is it NOLIMIT, with RETEXTRA set
at 7 years?

So, somewhere between 48 and 2500 VEREXISTS [mumble]  It's an important server 
else they wouldn't care.. 1M files or more, right?

Conservative target of 48M files for that one node, up to two -BILLION- objects 
for the one node.  Onsite copy, offsite copy?
That's what, 230GB of database size for one node?

Eugh.


Here's a plan: For your monthly fulls, make a new devclass ( or even a separate 
server??) , inaugurate a new node every month.  Run
your normal incrementals in a sane manner, completely separately. Then every 
month do:

RENAME NODE monthly-thing thing-YYYY-MM
REG NODE monthly-thing boogabooga

Put it in a special stgpool, back that up to a special copypool.  Whenever a 
tape gets full, check it out and stick it on the shelf.
Written once, never going to be reclaimed, why keep it near-line?  You only 
keep one primary volume and one copy volume on deck,
your management feels happy, and you've kept the backups chunked sufficiently 
small that you can manage moving them when it comes
time to shift media format.



Might you answer their need by cutting a backupset monthly?  Then you can store 
all that catalog information on shelves instead of
in your DB.




- Allen S. Rout