Sorry for the late reply, weekend and all that but being from Australia as well you're
in the same boat. :-)
For our monthlys, on our main fileserver which has about a 1tb of data, we see an
average of about ~12% change in data a month. I'm not sure the percentage of change
for our other servers but most of the other files are just database dumps and web
content, whose change rate is pretty constant. We only do selective backups for
monthlys so only important (non-OS) data gets backed up.
When we were doing full archives of our main fileserver each month, the database was
climbing close to 10% extra and at one stage got to 80gb, getting to unwieldy. On
average now we only use a bit over 2 LTO tapes a month for the monthlys.
We already run three different nodes on our servers for different backups (daily inc,
weekly inc and monthly inc) so adding a extra server to manage with it's own set of
nodes won't be a huge problem. It's not a elegant TSM setup but it works. I was
looking at modifying the management class for our daily backups so we could retire the
weekly nodes, but I think we would have a huge blow-out in the amount of data being
retained, forcing us to upgrade to a much bigger library for little gain. Our library
is already at near capacity, don't think management would want to spend $100000 on a
bigger library.
Cheers,
Gordon Woodward
Wintel Server Support
[EMAIL PROTECTED]
.QLD.GOV.AU To: [EMAIL PROTECTED]
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: Thoughts on Monthly
Archives
U
16/07/2004 11:53 AM
Please respond to
ADSM-L
Gordon,
I've though of doing this in the past, but, if we postulate a random daily change
rate, then the chances of a particular file being changed in any one month are
at 1% , 1-(0.99**30), or about .25
at 2%, 1-(0.98**30) , or about .45
at 3%, 1-(0.97**30), or about .60 (Please feel free to correct my maths if I'm
wrong - probability was never my strong point)
Now, of course its often the same files which change day after day, so real experience
should be better than this, but at the time, I decided that the overhead of
mainitianing two TSMs (and two clients per node) wasn't worth the benefit, and went
with archives.
Can I ask what rate of change you are seeing on your monthly backups?
Thanks
Steve
Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia
>>> [EMAIL PROTECTED] 16/07/2004 11:22:20 >>>
We use to do full Monthly archives of all our important data on our servers but our
TSM database was growing too rapidly, especially when we have to retain our backups
for 7 years. What we ended up doing is registering a whole new alternate set of nodes
specifically for Monthly backups and now just run incrementals. Our database doesn't
grow as rapidly anymore and we don't chew through as many tapes.
I'm thinking of now creating a second TSM instance and have that running exclusively
for our monthly backups to take the load off our day to day operations.
Gordon Woodward
Wintel Server Support
[EMAIL PROTECTED]
Sent by: To: [EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
EDU Subject: Thoughts on Monthly Archives
16/07/2004 07:00
AM
Please respond to
ADSM-L
We are implementing the following:
Monthly FULL backups, saved for 4 years for document retention purposes.
Backupsets are not viable, as a restore would be a pain. So it looks like
we're going to do this with archives. My idea is to create another storage
pool with it's own media, another domain with it's own management class (we
really need only one: save 1 version of this file for 4 years), and remove
that media once the archive runs.
Anyone care to comment on if this is the best, easiest, way to do this? Or
comment on what to expect with things like tape usage and database size?
We're currently at 57% of a 12gig database.
Thanks in advance!!!
Mike Bantz
Systems Administrator
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole
use of the intended recipient(s). This confidentiality is not waived or lost, if you
receive it and you are not the intended recipient(s), or if it is transmitted/received
in error.
Any unauthorised use, alteration, disclosure, distribution or review of this email is
prohibited. It may be subject to a statutory duty of confidentiality if it relates to
health service matters.
If you are not the intended recipient(s), or if you have received this email in error,
you are asked to immediately notify the sender by telephone or by return email. You
should also delete this email and destroy any hard copies produced.
***********************************************************************************
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
