I echo the other replies to this one - and make the following points:
- part of the life of a TSM administrator is to educate users, with the aid of
simple and realistic examples rather than TSM jargon. People sometimes find it
a hard concept to get, but once they do, they generally come around with one of
those great 'eureka' moments.
- Yes, using different node definitions would achieve that result, at a cost of
efficiency. You end up keeping duplicate data. Do make sure that they
understand (and are willing to meet the cost) of what they are asking for.
- You could also consider making backupsets of node data and putting them
somewhere, or even exports... but again, it's not efficient.
- Also you have not mentioned their reasons for wanting this strategy - if it's
for SOX/JSOX/etc compliance, I'd be wary of promising TSM as a compliance
solution because that's not what it's designed to do. There are add on
products for that purpose that do a much better job.
I would make the assumption that you are in the same position I often find
myself (and I'm sure others on the list have the same as well) - someone has
experience with a different product, and wants to ensure that they can recover
old data from ages ago, just in case they need it. Many people keep a year or
more of monthly archives - you can do that too if you want, but it won't be
efficient, and just like a G/F/S tape set, there is a good chance that the
mission critical file that was deleted 6 months ago isn't on the monthly
archive anyway. I try to understand what sort of data they might need to have
history of - if it's documents that might have been deleted, increase the
retonly. If it's month-end financial data, use archives. If it's operating
system binaries, why do they need to keep it so long - probably a week is fine.
Sorry for the long reply... hope that it helps.
----- "Bjørn Nachtwey" <b.nachtwey AT TU-BS DOT DE> wrote:
> Dear all,
>
> some of our users want to have a grandfather-father-son strategy
> using
> the tsm backup -- as far as i figured out, such a strategy is not
> part
> of the tsm approach.
>
> futher more i found an old discussion (Dec 2004) in the archive of
> this
> list, where Charles Hart supposed to do each of the backups using a
> different nodename that directs to different domains/management
> classes
> with adapted attributes.
>
> Is this still the way of realization or can I do something different?
> Especially if I want this straregy just for parts of the data?
>
> thanks,
> Bjørn
>
>
> --
> ########################################################################
> Dipl.-Ing. Bjørn Nachtwey
> Technische Universität Carolo-Wilhelmina zu Braunschweig
> Gauss-IT-Zentrum (GITZ) -- Leiter der Abteilung Server
> Hans-Sommerstraße 65, 38106 Braunschweig
> Telephon: +49 (0)531 / 391 - 5535
> TeleFax: +49 (0)531 / 391 - 5549
> http://www.tu-braunschweig.de/it
> mailto: b.nachtwey AT tu-braunschweig DOT de
> ########################################################################
> PGP-Schluessel:
> http://www-public.tu-bs.de:8080/~nachtwey/bjoern_nachtwey.asc
> PGP-Fingerprint:
> B472 526A A903 4AEB 9269 EC0B 9CDE 7465 CE87
> ########################################################################
|
