• 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.

Clients at risk in OC

combato

ADSM.ORG Member
#1
Hi Pro's

I have OC v.8.1.3.

My problem is that I have a lot of systems that has the OC status "At risk". This is because I have a bunch of nodes that I have locked down and does not run any more backups (not for a couple of years back in time).
This due to I need to save the node and data for some years ahead.

Does anyone know if there is another way of saving the node and it's data (keep all versions until the last backup was made) and get rid of the "At risk" in OC?

If I pick the "decommission node" I understand that the node gets the the attibute "Decommissioned=yes" and that all data gets expired according to the policy (my one is 90 - 90 -90 -90) and that seems to not be soo good in my case.

Any ideas of some workaround to get a better status in OC?

/C
 

marclant

ADSM.ORG Moderator
#2
Very easy:

In OC, in the Clients view, select one or many nodes, then click on upload_2017-11-30_11-59-22.png on the toolbar. This dialog box will appear and you can bypass warnings for these nodes.

upload_2017-11-30_11-57-15.png

Or from a command line:
set nodeatriskinterval NODENAME type=bypassed
 

ILCattivo

ADSM.ORG Senior Member
#4
Its a shame there is no more granularity to this setting.
I would like the option for the OC to report completed backups with RC=4 0r RC=8 to show as GREEN. These kinds of Return Codes can often come about due to repeated corrupted files or locked files (in use).

Completely Missed scheduled Backups should display as RED [At Risk - SEVERE]
Part Failed scheduled backups should display as YELLOW [At Risk - DATA]
Pending or Started scheduled backups should display as BLUE - as they currently do ;)

Apologies to those amongst us who are colour blind.. :oops:
 

marclant

ADSM.ORG Moderator
#5
You can, to some extent.

If you click on the settings (gear icon) in the top right corner and select Settings, you can set to be at-risk for skipped files (RC=4) or not.
upload_2017-12-6_12-48-36.png

You probably understood that part, but this doesn't look at schedules at all. Just if a successful back occurred during the "at-risk" criteria, doesn't matter if it's scheduled or manual. For example, if you would use a different scheduler, like cron or AT, it would still pick those up here. It will show green if it had a successful backup within the threshold, or red if it didn't
 

ILCattivo

ADSM.ORG Senior Member
#6
Thanks Marclant,

Yep, so this is close but yeah, I find it turns the previously 'At-Risk' Red client backup nodes with an RC=4 or 8 to yellow (Warning) on the OC dashboard, which can result in a not too impressive looking Client tile. :(

For Example...


upload_2017-12-6_17-7-49.png

The At-Risk %, as you say, does come down, but management and customers like to see more GREEN than anything else. :cool:
Be interesting to see how the daily Data Protection email report looks in terms of Backup success rate after this change.
 

marclant

ADSM.ORG Moderator
#7
What I find is that many of the "at-risk" are repeat offenders. I always recommend to my customers to go for the low hanging fruits to make the biggest dent in the success rate. Best way it to get a list of nodes and filespaces and the last time they had a successful backup. I use this query to find out filespaces that either never had a backup or not had a successful backup in more than a week. That tells me they are repeat offenders and not exceptions:

Protect: SERVER1>select cast(node_name as char(25)) as Node,cast(filespace_name as char(50)) as Filespace,backup_end as "Last successful backup" from filespaces where backup_end<current_timestamp-7 days or backup_end is null order by backup_end desc

Fix the issues with the repeat offenders and that will improve the success rate.

What many also do is set the "at-risk" for the server at 2 or 3 days. So if you have a client that misses or fails one day, it's not counted, but if it fails or miss more than 2 or 3 days in a row, then it's at risk. For the majority of systems it's usually acceptable. And then manually set it to 1 day for highly critical nodes (Tier 1), so that you know right away when they miss or fail.
 

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: 9 20.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 23 52.3%
  • Let's be formal and just say Spectrum Protect

    Votes: 8 18.2%
  • Other (please comement)

    Votes: 4 9.1%

Forum statistics

Threads
31,055
Messages
132,235
Members
21,274
Latest member
ctauber
Top