Lindsay,
I agree that "keep everything forever" is an extremely expensive
policy, even at the relatively low cost of tapes. But I don't agree
that keeping "inactive" files is a waste of space. Perhaps that isn't
how you meant it, but some might take it that way. How many versions of
files a customer chooses to keep is a design decision, and those are
always tradeoffs of cost versus risk. If we allow ourselves to fall
into the thinking that the "active" version is the important one, but
the "inactive" ones are somehow less important, we risk making bad
business decision just to save tapes.
With database applications especially, sometimes it could take days
or weeks before accidental deletion of some data would be detected. So
you must keep back enough versions to recover back to the point before
the accident occurred. In one of my customer's environment's, they only
keep back 14 days of backups of some large Oracle databases. This makes
my job easier, because they don't take up much tape in the library. On
the other hand, what if a person helped make a bunch of changes to the
way a database worked, and then went out on vacation for two weeks, or
just got busy with another application, and didn't realize that nightly
processing was purging data sooner than it was supposed to? It isn't
hard to picture this situation in real life. But since it has been two
weeks before the problem was detected, it is too late and the data is
gone. Of course, recovering data from that far back, extracting it,
then injecting it back into the production database would have been a
pain, but at least there would be options.
Another scenario like this involves financial applications that do
month-end closing. I have seen it happen where the accountants didn't
detect a problem that happened with month-end closing until they were
getting ready to run the next month-end closing. I usually recommend
they keep backups back to 40-45 days, so if necessary, it is possible to
restore data back to BEFORE the previous month's closing. Many customers
agree it is worthwhile insurance.
Best Regards,
John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721
-------- Original Message --------
Subject: Re: [ADSM-L] when a file has only inactive version in TSM
server?
From: lindsay morris <lind...@tsmworks.com>
Date: Thu, September 17, 2009 8:46 am
To: ADSM-L@VM.MARIST.EDU
This is a good question, really. We have found some fairly shocking
inactive-file statistics lately:
* One customer had 98.6% of their 30 TB of TSM backups in INACTIVE
files. Their policy was to "keep everything forever".
* Another customer did full database dumps every day, and kept
them for 180 days. They had about 90% of their 35 TB in inactive
backups.
Interesting that there is so much wasted storage.
(BTW, be careful if you try this at home. This is the oft-mentioned
query of the contents tables that kills TSM performance. ART trickles
in the data as it runs restore tests, so it does NOT kill TSM's
performance.)
------
Mr. Lindsay Morris
Principal
www.tsmworks.com
919-403-8260
lind...@tsmworks.com
On Sep17, at 9:07AM, Tchuise, Bertaut wrote:
> When there is no active version of the file :-)
>
> On a serious note, the TSM server will only have inactive versions
> of a
> file once the file is deleted from the client and the next incremental
> backup runs.
>
> BERTAUT TCHUISE
> TSM/NetApp Storage Administrator
> Legg Mason Technology Services
> *410-580-7032
> btchu...@leggmason.com
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
> Behalf Of
> Mehdi Salehi
> Sent: Thursday, September 17, 2009 9:01 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [ADSM-L] when a file has only inactive version in TSM server?
>
> Hi,
> when does a file have only inactive versions in TSM server?
>
> Thanks
>
> 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.
