Guidance around how to represent backup and retention using CMDB

[Steve Kelly]

Hello ITOM community,

I am looking for some guidance around how to represent backup, retention, and disaster recovery information in the CMDB. We have not yet implemented Discovery. Right now, we have been leveraging the Application and Business Application table to store information about the applications and systems in our organization. We have a request to add quite a few new fields to the Business Applications table to store the following kinds of information:

• How many years of data are retained for the system.
• Is our organization or the vendor responsible for backup.
• How many years backup is kept.
• Is there disaster recovery available.
• etc.

I am wondering if we should be using different CMDB class(es) to store some of this data and then establishing relationships from the application records, rather than adding too many fields to the applications tables.

Let me know if anyone has ideas around this. Thank you.

[vNick]

Hello,

I want to make sure I fully understand the requirement.  Are you saying you only need to store policy level information about backups and not actual records of the backups for certain device / application?

If yes, let's take and example where I assume you have a process that "maps" certain types of CIs (say Windows servers or all servers) to a business service (of type technical).  That business service would effectively say "all servers must have X retention, by Y vendor, etc, etc" as you state.  There's not really anything OOTB in this regard, but you may consider something around the "Information Object" class that ties to Business Application (see CSDM modeling) as Info Object stores data like data sensitivity and such.

I could see it being complex to truly manage unless you somehow integrate your backup solution to automate this type of data exchange (and possibly store the individual backups and their status as a related list to the actual CI that had the backup performed).

[Steve Kelly]

This is helpful! Yes, we would mostly be storing policy level information about what backs up what, if its us or the vendor, what is the disaster recovery importance, things of that nature. Definitely more so informational than actual records of the backups, which is not in scope for this.

We are more so interested in storing information about our actual applications/systems at this point than servers, we have not gotten that granular with our CMDB yet. But each application might have different data around its backup and retention schedule and disaster recovery importance etc. So do you think an approach of creating an information object for each application and establishing a relationship to said object would be one approach? 

Right now, the data we are trying to move to ServiceNow is stored in an Excel spreadsheet. And the people requesting this want all the data to just live on the application table. But we are pushing back on this as we do not want to overload the Business Applications table with too many custom fields (especially now that there is a limit on those). So if we were to create a separate class and establish the relationship, I assume we could then build reports using those relationships anyway.

[vNick · Accepted solution]

Yes, I would explore extending Information Object if you don't want to modify it directly.  If you have a look at the latest CSDM model you will see that it is meant to be related to Business Application in the design stage.

https://community.servicenow.com/community?id=community_article&sys_id=b96b84e7db5fd85011762183ca9619c9 

[Steve Kelly]

Thanks again for pointing me in the right direction.