• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Decomissioning server: final DRP volumes

vegivamp

Active Newcomer
#1
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

ADSM.ORG Moderator
#2
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

Active Newcomer
#3
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

ADSM.ORG Moderator
#4
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

ADSM.ORG Moderator
#5
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 Newcomer
#6
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

Active Newcomer
#7
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 :)
 

vegivamp

Active Newcomer
#10
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

Active Newcomer
#11
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

ADSM.ORG Moderator
#12
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

Active Newcomer
#13
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 :p

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

vegivamp

Active Newcomer
#15
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

ADSM.ORG Member
#16
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

Active Newcomer
#17
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 :p

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

ADSM.ORG Member
#18
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 :p


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

Active Newcomer
#19
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.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 10 16.7%
  • Keep using TSM for Spectrum Protect.

    Votes: 35 58.3%
  • Let's be formal and just say Spectrum Protect

    Votes: 9 15.0%
  • Other (please comement)

    Votes: 6 10.0%

Forum statistics

Threads
31,185
Messages
132,720
Members
21,341
Latest member
sskkss
Top