Decomissioning server: final DRP volumes

[vegivamp]

Hey,

I'm in the process of decomissioning a tsm server, but I can't seem to find a way to clear the volumes used by the last DBBACKUP. Neither del vol nor del volhist wants to, as per documentation; and an ancient thread mentioned an undocumented force=yes parameter, but that seems to have gone as well.

Can anyone point me to the right resources on how to go about that? In as far as it's relevant, this particular server is a library client.

Possibly relatedly, the library master also has a few records of volumes from servers that have long been decomissioned by my precedessor - is there a way to get rid of those, too?

Thanks,
/Johan

 

[marclant]

You can't delete the most recent database backup, it's made that way so you don't accidentally shoot yourself in the foot.

However, keep in mind that deleting the db backups from the volhist doesn't actually delete them, it only deletes the volume from the inventory and the tape return to scratch. If it's going to a file device class, then the file(s) will for that volume(s) will be deleted.

Since you are decommissioning the server, I don't see the need to clean everything up. If there is server to server communication involved, you should delete those server definitions first. But other than that, I'd just delete the instance, once you delete the instance, all that stuff will be gone anyway. Then delete all the directories used by Spectrum Protect (DB, log, pools).

 

[vegivamp]

Hey Marclant,

Thank you for your answer. Are you saying that by deleting the client server's definition on the library master, it'll simply drop all volumes belonging to that client? The documentation seems to make no mention of that.

It also raises the question why I still have volumes from an old server registered; when that server definition is already gone

I realise that it doesn't technically matter that I logically delete the data; but as long as the library master is aware that the volumes hold data they'll never be reused; and by clearing them on the library client, they'll also get retrieved from the remote location automatically, instead of me having to figure out which ones and fetch them manually.

/Johan

 

[LED888]

It also raises the question why I still have volumes from an old server registered; when that server definition is already gone

The most current backup version of a file is called the active version.
Active version never expire. This is the cause as to why we still have volumes even though the server is gone.

Good Luck,
Sias

 

[marclant]

Oh, sorry. I thought you were decommissioning the library manager (or master like you say) after all the library clients were decommissioned.

You are correct that you will need to clean those out manually. If you remove everything (or as much as possible) from the library client, it will make less to clean up on the library manager.

 

[vegivamp]

Active version never expire. This is the cause as to why we still have volumes even though the server is gone.

What's on the tape is irrelevant - the problem here is that the tape is known to the library manager as belonging to a library client that no longer exists.

 

[vegivamp]

You are correct that you will need to clean those out manually. If you remove everything (or as much as possible) from the library client, it will make less to clean up on the library manager.

And this is where we get to the brunt of the matter - how do I tell the library manager that those tapes are no longer in use, since I have no way of telling the library client that it can delete it's final DRP volumes

 

[marclant]

Just a theory here. Why not do one last backup DB to a file devclass, that way you would be able to delete the one on tape.

 

[vegivamp]

Just a theory here. Why not do one last backup DB to a file devclass, that way you would be able to delete the one on tape.

Now there's a great idea I'll give it a go later today and report back.

 

[vegivamp]

Works, files are on disk, but it doesn't seem to pick up that the other ones may go, even after I've set dbbackup expiredays to 0.

I'll look some more after the weekend; I do feel this is the right track

 

[vegivamp]

Just a theory here. Why not do one last backup DB to a file devclass, that way you would be able to delete the one on tape.

Alas, it seems that Tivoli is too smart for it's own good - it knows about the dbbackups to file as witnessed by the volhist, but it doesn't take them into account when I q drm - presumably it realises they're not removable.

Trying to use move drm on them also doesn't work. Currently diving into the docs on handling file class - never used it before, but surely it should be possible to use them for drm by copying them to another system...

 

[marclant]

Probably because the dbrecovery options still point to tape. You might have to change that too.

but surely it should be possible to use them for drm by copying them to another system...

It is, there are various ways to do it:
- some use the Spectrum Protect Client to back them up to a different server.
- replication at the disk level
- a script that copies it

 

[vegivamp]

Probably because the dbrecovery options still point to tape. You might have to change that too.

I did set the dbrecovery to the new devclass, after which the backup db command stopped warning me about it

It is, there are various ways to do it

That was more a general remark, doesn't help in freeing the last 12 tapes

Currently trying to predefine file volumes in a storagepool and telling dbbackup to use those.

 

[marclant]

Currently trying to predefine file volumes in a storagepool and telling dbbackup to use those.

The database backup doesn't use storage pools volumes, only scratch volumes from a device class.

 

[vegivamp]

The database backup doesn't use storage pools volumes, only scratch volumes from a device class.

Riiiiight, that was the bit I was missing. The remaining drm volumes were copy, not dbbackup. Manually set them onsite and then deleted them - so the dbbackup to file did in fact clear the last tape backup.

Now I'm just left with six volumes that the library manager thinks are still owned by the library client (both dbbackup and data ones); but the library client doesn't list.

When I try to define them in a storagepool (so I can delete them again), but def vol gives me an ANR2400E to say they're still in use, despite not showing in q vol, q drm or q volhist - I assume it's the LM reporting that then.

Do you have any ideas about how to fix that last bit?

 

[shcart]

I believe you can check them out / eject them, this should delete the library manager history (LIBVOL) of the tapes. After you have deleted / disconnected the TSM server that owns them you should be able to label them back in as scratch tapes with no owner.

There are ways to update libvolumes to make private tapes scratch and unowned but I also suggest you should only do this after the Owning server no longer exists on the libmanager.

I Haven't touched tape carts for 6 years so I no longer have a play area to test in but we used to do stuff like this all the time.

 

[vegivamp]

I believe you can check them out / eject them, this should delete the library manager history (LIBVOL) of the tapes. After you have deleted / disconnected the TSM server that owns them you should be able to label them back in as scratch tapes with no owner.

I would prefer not relabeling them, as particular labelranges are relevant for various scripts - I've got about 10k tapes in circulation, so I'd like to keep it simple

There are ways to update libvolumes to make private tapes scratch and unowned but I also suggest you should only do this after the Owning server no longer exists on the libmanager.

If you're referring to update libvol, that refuses to update tapes from private to scratch unless it is already aware the tape no longer holds data, but the LM is currently convinced that they do

 

[shcart]

I would prefer not relabeling them, as particular labelranges are relevant for various scripts - I've got about 10k tapes in circulation, so I'd like to keep it simple


If you're referring to update libvol, that refuses to update tapes from private to scratch unless it is already aware the tape no longer holds data, but the LM is currently convinced that they do

All the information about who owns what tapes and their last use is held in the volume history table on the library client. In addition there is a volume history table on the library manager. After you decomm the server you no longer need, then you can then carefully delete the residual volhist entries for those tapes in the library manager volume history (Be Afraid). If I remember correctly you can use "force=yes", which is a hidden option for a good reason (Be Very Afraid). After that you can either update the libvol entries manually to return them to scratch with no owner or simply check out the tapes (remove = yes) and then check them back in as scratch,

Relabel can, and for barcode tapes should, use the same volume name and is mandatory to free up previously allocated space if you use a VTL.

 

[vegivamp]

After you decomm the server you no longer need, then you can then carefully delete the residual volhist entries for those tapes in the library manager volume history (Be Afraid).

As far as I'm aware, you can not delete volhist for individual volumes; you can only select by date and by type. That being said, it's certainly worth looking at; any volumes still in use will still remain in the volumes table anyway.

 

[vegivamp]

Well that took a while, but the last of the unwanted tapes has finally disappeared.

The final solutions:
- audit library can also be run on a library client; this serves to synchronize inventory with the master. This cleared all but one tape, for which the LC was long decomissioned
- that last tape was eventually cleared by deleting it's particular volhistory entries with a few undocumented parameters to the DEL VOLHIST command:
DEL VOLHIST VOLUME=<label> TYPE=REMOTE FORCE=YES TODATE=-1

Other variations of that last command as found in other threads didn't work; but this exact invocation did. Afterwards I could succesfully check the volume in again (it got checked out during the course of the IBM case) without complaints that it already belonged to an LC.