Backups backups backups.
The recent “issue” of installing TBSM v4.2 IF1 and having it wipe out your customizations is a prime example of why you need to implement your own software versioning and backup process for your TBSM environment. Trust me, it even touched me in my excitement to get IF1 applied, I hadn’t done a backup first and now get the experience of uninstalling and patching things back together.
TBSM v4.2 is an amalgamation of software components across many different development groups within Tivoli. Off the top of my head I see core TBSM, OMNIbus, OMNIbus Probes (EIF Probe), WebTop, TIP/ISC, eWAS, TCR, ITM (BSM Agent), etc. This many core components and dependencies requires a lot of coordination to make sure that one doesn’t adversely impact the other. I’m sure we’ve got all our testing and QA bases covered to some degree, but nobody’s perfect. There’s no possible way they can account for how you’re using TBSM. The software is way too flexible and allows smart folks like yourself to do some pretty creative things.
So, the standard disclaimer is that before you apply any interim fix or fix pack is, you guessed it, back up your environment. The easiest way is to tar up the entire directory structure for your data server and dashboard server.
The TBSM v4.2 manual only makes a few simple suggestions, outlined here.
TBSM v4.2 Backing Up Database
If you’re using TBSM SLAs, backup the following files:
* $TBSM_DATA_SERVER_HOME/xml/cumulTimeSLA.xml
* $TBSM_DATA_SERVER_HOME/xml/scheduleTime.xml
If you have created view definitions, or custom service trees, backup the entire contents of the $TBSM_DATA_SERVER_HOME/av/xmlconfig/.
If you have created custom static canvases, backup the entire contents of the file $TBSM_DATA_SERVER_HOME/av/canvas/.
If you have created custom charts, backup the entire contents of the $TBSM_DATA_SERVER_HOME/dashboard/chartconfig/.
There are so many more things you should also be thinking about. Unfortunately, nearly all of these are undocumented. I’m poking around the inside to figure these out and will update the post as I learn more for these.
- TBSM – Custom images, icons, backgrounds
- TBSM – Custom policies, code, integration, drivers
- Deployment Engine (DE)
- Netcool/Webtop: entities, filters, views, maps, groups, etc.
- BSM Agent
- Netcool/OMNIbus
- Netcool/OMNIbus Probes
- TIP
- TIP ISC/eWAS
- TIP AAA: users, groups, roles, LDAP/AD/OMNIbus integrations and configurations
- TIP Derby Database
- TIP DB2 for “Load Balancing”
- IBM HTTP Server for “Load Balancing”
- TIP Charting: Chart/Report templates, user/default preferences
- TIP TCR: Reports, Charts, Schedules, User Preferences, Distribution
- TIP Portlets – events, wires, translations
How do you back up TBSM? Do you have your favorite script, tool or process? Share your tips, tricks and lessons learned on backing up and restoring software. I’ll get all of this summarized and on its own page on the blog and TBSM Wiki in the future.
Comments on this entry are closed.
Hi Doug,
There’s also the XMLToolkit for TADDM integration – that’s also got it’s own configuration which should be be saved.
Hi there Doug!
By any chance you have managed to configure a system wire in TBSM? I’ve been searching around endlessly for some documentation / steps, but its very much a dark science =(
System wires are not editable. You can disable them, but that’s it. You can only edit Custom Wires (ones you’ve added yourself).
The same holds for anything you see in TIP that’s a Core or System resource like views, pages, portlets, etc. When you add your own content, it’s classified as a Custom resource.
HTH! What’s going on in your TBSM world?
Doug
Dear Doug,
Thanks for the info!
I have TADDM and TBSM working hand-in-hand for event management, But also some KPI service desk configuration needed via Remedy – Currently trying to add a wire to display detailed ticket information on a separate page when user right clicks on an application. Is this an out-of-the-box feature?
Looks promising!
But the main obstacle appears to be passing a parameter across.. How can I pass the name of the node I clicked on and let the target portlet filter by this node name??
What does the “Event” term here means?? I see NodeClickedOn and FindService.. What about transformation?? Whats the deal with it? Wires are not documented at all!
Events from a portlet perspective are hard coded and internally developed for each type of portlet. Typically, when you click on something such as an instance in the service tree portlet, that click emits an event that contains specific attributes about what you clicked on. Portlets are dynamically or manually wired together either by us based on how we think the product to work together or how you want it to behave based on what you develop. For example, if you create a new page and place a service tree and service viewer portlet on that page, we assume you want the service viewer portlet update/paint the model when you click on something in the service tree.
Correct, transformations are not documented. The challenge today is that you need to emit an event from a certain portlet, then transform/map it into another portlet. The only portlet you can come close to is the Inline Frame portlet but this portlet doesn’t accept any incoming events today.
Your only option is to create a right click or single/double click tool that contains an action which will launch a new browser window and pass in a structured URL containing parameters from your service instance such as Node Name or any others you register.
If you / your client are willing, I know our TIP developers are very interested in building out a more formal launch in context / 3rd party portlet scenario from TBSM/TIP to Remedy. Please email me direct if you are interested.
Doug