Multiple management class VS multiple Domains

moon-buddy

ADSM.ORG Moderator
Joined
Aug 24, 2005
Messages
7,010
Reaction score
406
Points
0
Location
Somewhere in the US
I would like to get real world experience from the community.

The question is:

There is a need to have multiple retention periods for files on a certain node. There are 2 options:

- create multiple management classes
- create multiple domains


The former allows the possbility of just one node name and backup schedules controlled by running specific command lines and calling different sys/opt files for backups

The latter is rather straightforward but requires multiple node names for the different required retention periods.

What other pluses or minuses for these 2?

From an auditing viewpoint, the latter offers a straightforward view that one can easily prove that the retention is answered for and that the destination do align with the ongoing backups.

I am more inclined with the latter for the reasons I have outlined.

What do you think?
 
Last edited:
I would do multiple domains.
Just for the simple reason that directories are always bound to the management class with the longest retention. Also, if you have a tech team rerunning backups that miss or failed, you could have a shortcut/script/whatever pointing to the correct sys/opt file. That way, you know that the appropriate data is captured correctly (excluding human error).
 
I would prefer the former for ease of management. I'm more inclined to make the life easy for the administrator than the auditor.

When the auditor comes for a visit, you could enable the auditing log in full mode for one backup run, provide him/her the audit log, and him/her can audit until their heart's content.
Edit to add: auditlogging doesn't track MC
 
Last edited:
I would do multiple domains.
Just for the simple reason that directories are always bound to the management class with the longest retention. Also, if you have a tech team rerunning backups that miss or failed, you could have a shortcut/script/whatever pointing to the correct sys/opt file. That way, you know that the appropriate data is captured correctly (excluding human error).
With one node, you would only need one schedule to rerun if it failed. The include/exclude would dictate which directory/files are bound to which management class.


here is a need to have multiple retention periods for files on a certain node.
Do you mean that the same file can be backed up more than once, but with a different retention each time?
Like a daily for 7 days and monthly for 12 months

If so, you will need multiple nodes at a minimum, multiple domains is optional. Multiple domains means you can handle retention with the default MC. Nodes in the same domain means you must handle the retention with an include to point to the MC of choice.
 
With one node, you would only need one schedule to rerun if it failed. The include/exclude would dictate which directory/files are bound to which management class.
Very true. I was thinking more along the lines of a DOMAIN statement in the sys/opt file, and not using include/exclude. For example if the scheduler is set to do DOMAIN C: -D: -E: and the tech team comes in and launches the gui, selects 'All Local' pretty sure from the baclient it will backup C, D and E.
 
I, too, am more inclined with multiple domains. Scheduling is not a big problem when you only look after one per domain. One would also have the flexibility of moving the schedules around to meet traffic demands, or move entirely the domain to another TSM server without doing other leg work.

Thanks for all the reponses.
 
Last edited:
Back
Top