This article outlines what to consider when planning disaster recovery (DR) for an on-premises Snow environment, including:

• Snow License Manager (SLM)
• Snow Inventory Server (INV)
• Snow Integration Manager (SIM)

Plan disaster recovery

Before investigating Snow in a disaster recovery scenario, inform all business stakeholders, including the Disaster Response Team, about the planning activity. Hold internal meetings with your stakeholders to discuss the following:

• Your current disaster recovery strategy
• Recovery Point Objective (RPO)
• Recovery Time Objective (RTO)
• How complex is your current infrastructure setup?
• What is your current backup and restore solution?
• What is the minimum backup retention period?
• What processes are followed for other applications in the data center?
• Have disaster recovery test plans been created?
• Has a risk management matrix been created?
• How will you communicate with users during a disaster recovery outage?
• Have disaster recovery procedures or protocols already been created?
• Can you create a test environment to replicate the scenario?
• What components sit between the systems, such as load balancers?

We recommend that customers follow their internal disaster recovery strategy and plan in conjunction with their Business Continuity Management Plan.

Snow products do not currently support high availability (HA) for Snow License Manager 8, 9, and Snow Inventory Server 5, and should be removed from SQL Always On because it is not officially supported. For versions not listed, check the Snow System Requirements for further advice.

As part of database maintenance and good practice, we recommend daily incremental backups and weekly full backups for all Snow databases. Add these jobs to your SQL monitoring tool and check that they have run successfully each day.

Test core functionality

As part of your overall disaster recovery planning and strategy, create sufficient test plans to test core product functionality. Coordinate these plans with your organization's Snow administrator, who will have the best knowledge of which functionality to test within the platform.

Example use cases to test after failover and after failback include:

• Is the Snow License Manager UI accessible? (Y/N)
• Are agents successfully communicating with the secondary node, for example, does Scan & Send work? (Y/N)
• Are snowpacks successfully processing on the secondary node? (Y/N)
• Can the Snow administrator sign in to the SMACC console? (Y/N)
• Can the Snow administrator sign in to the Snow Inventory Administration Console? (Y/N)
• Are dashboards visible within the console? (Y/N)
• Have the Snow Integration Manager connectors successfully aggregated? (Y/N)
• Have all microservices successfully started on the SLM server? (Y/N)
  • Create sub-use cases for each microservice to verify its functionality.
• Are reports accessible from the Snow UI?
• Do email notifications send successfully?
• Did the Snow Data Update Job run successfully?
• Is other core functionality accessible? Consult your Snow administrator for more details. This may include the ability to:
  • Upload entitlements
  • Archive devices
  • Remove devices
  • Create new users or change user permissions

Test the same scenarios after failback.

Where possible, review disaster recovery scenarios in a test environment with disaster recovery and mitigation plans in place, following your organization's Business Continuity Management Plan. These are guidelines; consult your internal teams for further details.