Modern enterprises require continuous access to data and processes. Yet, shockingly, only around half (54%) of technical and business decision-makers report having a disaster recovery and business continuity plan (DR/BC), even though 73% have experienced a failure or outage at some point. Two-thirds even reported that it occurred in the past year.
Configuration management databases (CMDBs) are software solutions that use automation to capture asset data, including changes and configurations. As such, they serve as a valuable resource to DR/BC teams seeking to navigate a disaster, stabilize operational processes, and recover data and infrastructure.
This article will explore:
- CMDB capabilities: Key capabilities CMDBs provide that streamline IT management and operations work.
- The importance of DR/BC: Why leaders should implement, test, and improve DR and BC plans.
- How to use a CMDB to strengthen DR/BC: How CMDB capabilities, such as auto-discovery and dependency mapping, improve DR/BC planning, processes, and execution.
- Best practices: What teams should consider as they purchase, deploy, and use a CMDB to meet DR/BC requirements.
- Future trends and technologies: How CMDBs evolve to keep pace with new DR/BC requirements.
With this information, readers can select the right CMDB and use their CMDB to improve DR/BC processes, reducing the risk of outages and failures that cause business disruption and customer harm.
Understanding CMDB Capabilities
Leading CMDBs use agentless and agent-based processes to discover all hardware, software, virtualized, and cloud assets across hybrid cloud infrastructures. They also often provide automated dependency mapping, helping teams visualize how applications support upstream and downstream services and processes.
This information is invaluable to many teams, including IT management and operations, IT service management (ITSM), DC/BR, and application modernization and cloud migration teams. In addition, business heads and leaders often consume CMDB reporting data, using this information to plan strategy and future IT investments.
Read:
What is a CMDB? Configuration Management Databases 101
The Importance of Disaster Recovery Planning
DR teams seek to recover data and infrastructure after an outage or failure. Defective equipment, power outages, application and business process failures, third-party issues, fast-paced regulatory changes, data breaches, natural disasters, extreme weather, and other issues can cause disasters that organizations must recover from.
Because disasters are inherently unknown, DR teams must consider and develop strategies and plans considering various risks. Critical components of an effective disaster recovery plan include:
- Setting up the team and goals: Leaders will want to create the DR team, outline roles and responsibilities, describe tools and processes used for DR activities, specify communication plans, and decide on key goals.
- Assessing risks: Teams will want to audit all assets to discover and quantify all risks, prioritize them by business impact, and develop remediation strategies for high-impact gaps and weaknesses. They should consider hardware, software, business processes, infrastructure, data, and connectivity importance and possible losses as they quantify impacts.
- Quantifying metrics: Teams use metrics such as service-level agreements (SLAs), recovery time objectives (RTOs), and recovery point objectives (RPOs) to quantify goals. SLAs often provide high availability and infrastructure and application performance objectives that organizations must meet for their customers. RTOs determine which applications need to fail over seamlessly and which ones can have longer recovery times. And RPOs define how much data can be lost before it causes business harm.
- Developing a data backup and restoration strategy: Most organizations back up or replicate data to one or more data centers, typically in a different geography. Replication enables immediate access to current data, whereas data backups provide delayed access to stale data.
In addition, DR plans outline policies and processes that govern teamwork during testing and actual disasters. A well-defined plan enables teams to focus on restoring the most critical data, such as business and customer information, and follow consistent procedures to ensure success. - Using predefined communication plans: DR teams communicate plans and progress to internal stakeholders, who will communicate with leaders, customers, and the media. Having clear lines of accountability and playbooks ensures that communicators get the information they need while everyone stays on script.
- Testing and validating plans: Teams can test DR plans in multiple ways. They can simply read playbooks to review processes. They can create simulations and involve all key parties in testing processes and data and infrastructure recovery. They can test systems in parallel or take primary systems down and failover to recovery systems.
Teams should test DR plans in-depth at least once yearly, and many organizations will want to test more frequently to ensure they address emerging and changing risks.
How CMDBs Support Disaster Recovery Planning
Teams will use specialized DR technology that provides workflows, metrics, and key activities. However, a CMDB provides invaluable data that support DR activities, including:
- Identifying and tracking assets: CMDBs auto-discover all assets wherever they are located, enabling teams to obtain a real-time lens into hybrid cloud infrastructures. The CMDB also serves as a single source of truth for all devices, dependencies, changes, and configurations, enabling teams to make confident decisions about DR activities. Teams must keep CMDBs up-to-date and validate data to accomplish this goal.
Leading CMDBs normalize and enrich data using artificial intelligence, reducing team strain. - Mapping dependencies: CMDBs map upstream and downstream dependencies, enabling teams to see which applications and processes are in scope for tests or actual disasters, alert affected stakeholders, and quantify business impacts. This information also helps teams focus on restoring the most critical applications first.
- Reviewing change and configuration histories: The CMDB provides a living history of all changes and configurations. DR teams can see what work has been done, zeroing in on changes that may have caused unintended impacts. They can also see what’s been neglected, such as patches creating security risks or implicated in data breaches. BC/DR, ITSM, and other teams can use this information to restore assets to full performance.
Read:
Why Your Disaster Recovery Plan Must Include Inventory Tracking
Disaster Recovery Planning in a Multi-Cloud Environment
How to Harness the Power of Cloud Disaster Recovery Without Sacrificing Security
Strengthening Business Continuity Planning with a CMDB
Business continuity is the ability to maintain core operations during a disaster, as DR teams work to recover data and infrastructure. DR is part of BC, and BC teams will use DR information to craft the best strategy for maintaining operational continuity.
So, how do teams develop BC plans? They:
- Identify critical business processes: BC teams use CMDB data to identify the business processes applications support and their criticality. As with infrastructure, BC teams prioritize processes that must maintain continuity and others where slower restoration timeframes are acceptable.
- Establishing RTO and RPO objectives: BC teams also use RTO and RPO objectives. Each process will have a documented RTO and RPO that teams will measure during testing and actual disaster recovery.
CMDBs provide data for real-time monitoring and automated processes for failover that support DR and BC activities. - Creating redundancy and failover strategies: Businesses will develop redundancy and failover strategies that consider their role in providing critical infrastructure or services to other organizations, RTO/RPO objectives, and budget.
For example, critical infrastructure providers such as government agencies, utilities, or cloud providers will likely pay for greater redundancy and failover capabilities. One common best practice is to use the 3:2:1 rule for data storage: keeping three copies of all data, two of which are maintained on separate media and one kept offsite. For example, organizations could elect to replicate data to two different cloud providers.
How CMDBs Support BC Plans and Activities
CMDBs help teams develop BC plans and maintain continuity during disasters by:
- Mapping dependencies: Teams can auto-discover all dependencies between applications, services, and processes, using this data to develop and refine BC plans.
- Identifying single points of failure: Auto-discovery of assets and dependencies can reveal weak links, such as systems that aren’t replicated, data that isn’t backed up, or end-of-life systems that create outsize risks. Teams can use this information to mitigate issues so that they don’t cause a disaster.
- Automating failover: Leading CMDBs allow users to put appliances in standby mode and do periodic restorations to devices to support failover activities. Teams simply set up automated restores and set the backup appliance to production if the primary device fails.
Read:
Best practices for using a CMDB for BC/DR Planning and Processes
CMDBs can be extremely valuable to BC/DR teams. Here are some best practices to govern their use:
- Deploy the CMDB before a disaster occurs: Many organizations track asset data manually across spreadsheets and other tools. This can create out-of-date data and lagging processes that break amidst a disaster.
As a result, teams need to implement a CMDB, create an asset inventory, set up auto-discovery schedules, and train teams on how to use it before disaster strikes. - Leverage automation and extend capabilities: Teams can leverage automation to discover all assets, changes, and configurations and improve data. They can make CMDBs even more valuable by integrating them with IT asset management, IP address management, and data center infrastructure management solutions, gaining holistic visibility into IT operations.
- Commit to maintaining data: Data is only valuable for infrastructure mapping if it’s up-to-date and comprehensive. While CMDBs automate discovery, dependency mapping, and data normalization, teams must enforce business rules for application naming, configuration item management, and asset discovery to ensure data accuracy.
- Enforce roles: CMDB data is valuable, so teams will want to limit access and privileges to those needing insights and reporting to do their jobs. CMDBs enable teams to restrict access by location, department, device type, and more, segmenting access further.
- Maintain data sovereignty with an on-premises solution: When IT teams purchase and deploy CMDB solutions on-premises, they maintain control over their data, improving its security and privacy. When they opt for SaaS solutions, they can experience potential data exposure risks if providers don’t configure or patch systems correctly. This is an important choice, as losing control over IT management and operations data provides adversaries with the keys to the kingdom — creating the very issue that DR/BC teams seek to avoid.
Leaders of organizations governed by data privacy and security regulations and requirements may want to choose on-premises solutions to reduce unnecessary risks: maintaining compliance and avoiding leaks of IT operations data that can be used to breach networks and systems.
Executives at a technology company with $1 billion in annual revenues realized they needed to improve their DR processes. The DR team lacked centralized documentation of resources, as well as a real-time understanding of applications, processes, and dependencies. The company owns and operates intelligent commerce networks serving customers across different industries, meaning customers could experience outsized impacts if the firm can’t recover quickly during a disaster.
By deploying Device42, the company has been able to reduce the number of days to recover from a major disaster from seven to two to three and decrease the DR team size from 65 to 25 employees. All data needed to recover from a disaster is stored in near-real-time in Device42 and represents actual infrastructure data, enabling DR teams to communicate and collaborate effectively.
“Device42 is really critical for us because we store all of our service account information, all the admin accounts, validation IPs, and other resources in [the CMDB]. We literally, from an infrastructure standpoint, can’t tell you how many teams are relying on Device42,” says the incident manager of the company’s platform engineering and shared services group.
Future Trends and Technologies
So, how are organizations evolving BC and DR capabilities with the support of CMDB data?
Advanced CMDBs discover assets across the hybrid cloud — including unknown data stores and ephemeral assets such as containers. This capability enables teams to get a better picture of how infrastructure is changing over time, as well as mitigate shadow IT risks.
CMDBs also use AI to streamline DR/BC processes, increasing operational efficiency. For example, AI can identify and delete duplicative devices, reveal misconfigurations to fix, and prioritize changes and configurations by risk level.
Leaders may also seek to improve BC and DR strategies and plans by replicating data and applications across another cloud provider, increasing network connectivity, and testing plans more frequently.
Improve DR/BC Processes with a CMDB, Starting Today
If your organization lacks a comprehensive DR/BC plan, there’s no time like the present to develop one. Deploy a CMDB to discover and capture all asset data and dependencies, identify critical processes and infrastructure, and develop and test your DR/BC plan and processes.
In addition, you can use CMDB insights to identify and remediate gaps and weaknesses before they cause disasters, strengthening your DR/BC posture proactively.
