Server Retirement Script

[darbronnoco]

Hi All, I am looking for a way to streamline my node retirement process. Currently when a server is retired we remove the schedule and have to set a calendar reminder in outlook to go back and delete the file spaces after the retention has passed. If we forget the data is still out there and gradually takes over our DataDomain space. Is there a way to automate this process a bit more? I would think when we are ready to retire if we marked all the file spaces as inactive that they would retire and the file spaces be removed per their retention policy automatically. Then the next step in the script would be to have a check for any nodes older than X (an amount to keep new nodes that haven't had a backup from being removed) with not file spaces and delete those nodes?

If this can't be scripted I would be interested to hear what others are doing to streamline this process as much as possible.

Thanks,

 

[marclant]

This has been requested many times, it's finally available. The 7.1.3 server has a new feature to decommission nodes:
http://www-01.ibm.com/support/knowl...mmon/r_techchg_srv_decommission_node_713.html

 

[darbronnoco]

!!! Nice thanks for finding that. Not sure how I missed that one.

 

[moon-buddy]

!!! Nice thanks for finding that. Not sure how I missed that one.

Nice to have but I think this does not 100% satisfy your needs.

You said "...we remove the schedule and have to set a calendar reminder in outlook to go back and delete the file spaces after the retention has passed."

Using this new command does all in one sweep. It does not set a future time after retention has passed when the schedule has been deleted.

I really wish it could do this in one command.

1. delete the schedule
2. set when (a future time) to delete the file spaces
3. delete the node

 

[darbronnoco]

Per IBM "When you start the decommission process, the server locks the client node to prevent it from accessing the server. Files that belong to the client node are gradually deleted, and then the client node is deleted" Would the node being deleted not removed the schedule as a result?

If I understand this decommission right it looks like the gradually delete part would be removing the file spaces? Am I missing something? I'm on 6.3.x now so I have a big upgrade to do before I can even test the decommission process. Thank you

 

[marclant]

Nice to have but I think this does not 100% satisfy your needs.

You said "...we remove the schedule and have to set a calendar reminder in outlook to go back and delete the file spaces after the retention has passed."

Using this new command does all in one sweep. It does not set a future time after retention has passed when the schedule has been deleted.

I really wish it could do this in one command.

1. delete the schedule
2. set when (a future time) to delete the file spaces
3. delete the node

It does all that. Well, for 1, it deletes the association, not the schedule because a schedule could be used by multiple nodes.

When a client node is no longer needed in the production environment, you can issue this command to initiate a gradual, controlled decommission operation. The command completes the following actions:

• Deletes all schedule associations for the client node. Schedules are no longer run on the client node. This action is equivalent to issuing the DELETE ASSOCIATION command for every schedule with which the client node is associated.
• Prevents the client from accessing the server. This action is equivalent to issuing the LOCK NODE command.

After the command finishes, client node data is no longer backed up to the server. Data that was backed up before the client node was decommissioned is not immediately deleted from the server. However, all backup file versions, including the most recent backup, are now inactive copies. The client files are retained on the server according to your storage management policies.

After all data retention periods expire, and all client backup and archive file copies are removed from server storage, Tivoli Storage Manager deletes the file spaces that belong to the decommissioned node. This action is equivalent to issuing the DELETE FILESPACE command.

After the file spaces for the decommissioned node are deleted, the node definition is deleted from the server. This action is equivalent to issuing the REMOVE NODE command.

source: http://www-01.ibm.com/support/knowl....3/srv.reference/r_cmd_node_decommission.html

 

[moon-buddy]

It does all that. Well, for 1, it deletes the association, not the schedule because a schedule could be used by multiple nodes.
source: http://www-01.ibm.com/support/knowl....3/srv.reference/r_cmd_node_decommission.html

Not quite the outcome some wants.

What I think is a better alternative is to have an option 1) to delete schedule associations, 2) set a date into the future to have the file spaces deleted, and 3) delete the node.

Here is where this one applies:

Let's say that the retention policy for a node is 1 year, and you only need to keep the file spaces for 6 months which is a compliance requirement and "for just in case". Using this command will default deletion to the retention requirements which means that you will have to go back 6 months later to manually delete the file.

I have encountered cases like this and that is why I say that this does not 100% cut it.

 

[marclant]

Valid case. You may want to submit an RFE.

 

[marclant]

Let's say that the retention policy for a node is 1 year, and you only need to keep the file spaces for 6 months which is a compliance requirement and "for just in case". Using this command will default deletion to the retention requirements which means that you will have to go back 6 months later to manually delete the file.

A workaround for that would be to create a new domain and set the default management class to how long you want before a node is deleted and move the node to the new domain before decommissioning it. That way, it will use the retention of the new domain as opposed to the longer retention from the original domain.

 

[moon-buddy]

A workaround for that would be to create a new domain and set the default management class to how long you want before a node is deleted and move the node to the new domain before decommissioning it. That way, it will use the retention of the new domain as opposed to the longer retention from the original domain.

Nice workaround but still burdens admins. Too much work.

What I believe the developers should have done is to add an optional date switch to the decommission command like:

decommission node xxxx date=12/31/2015 ....

without the switch, the action will be the default: delete after retention is met.

 

[moon-buddy]

FYI, I submitted a RFE for this.

Hopefully, the development team can add the option to the decommission command easily!

 

[marclant]

FYI, I submitted a RFE for this.

Hopefully, the development team can add the option to the decommission command easily!

Do you have a link to it? I'll vote for it.

 

[moon-buddy]

Do you have a link to it? I'll vote for it.

This is all that I have:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=77681

 

[marclant]

Thanks, I voted.