Disaster Recovery Documentation for Bold BI

Overview

Disaster recovery (DR) is a critical part of enterprise applications, ensuring business continuity and reducing downtime during unexpected events like hardware failures, software crashes, or natural disasters. Therefore, having a robust disaster recovery (DR) plan for Bold BI applications is essential. One of the key aspects of DR is ensuring that you have an efficient Backup and Restore process.

This guide outlines the steps for creating backups, restoring data, and reconfiguring the BI application to point to restored resources. It emphasizes the importance of regularly backing up application data, metadata, and the IMDB database to ensure seamless recovery in the event of a disaster. Understanding where Bold BI stores its persistent data is crucial for developing effective backup strategies. The diagram below illustrates the infrastructure architecture of Bold BI, providing a clear overview of how components like the load balancer, services, app data storage, and database server interact within the system.

As shown in the diagram, Bold BI’s persistent data is stored in the App_Data directory and a database server. The next section provides detailed information on what is stored in these locations and their importance in disaster recovery.

Bold BI Persistent Data

Bold BI persistent data, which includes users, groups, dashboards, schedules, and application-related data, is saved in the following resources:

1. App_Data
2. Database Server

App_Data

All dashboard resource information is saved in the App_Data location and can be saved in any of the following supported options:

1. File Storage
2. Azure Blob storage

File Storage

The File Storage typically refers to the storage that contains Bold BI application data. It can be a local file storage or managed cloud storage based on the deployment environment.

Azure Blob storage

By selecting this option, the APP_Data information will be saved in the designated Azure blob storage.

Database Server

The metadata and intermediate data details of the Bold BI site will be saved on the database server. Bold BI supports the following databases for use as Meta and IMDB servers:

1. My SQL
2. MS SQL
3. Postgres SQL

The upcoming section will provide guidance on how to take backup and restore Bold BI persistent resources.

Backup and Restore Persistent Data

This section will explore how to take backup and restore Bold BI persistent resources. From the infrastructure diagram and persistent data saving location, you can understand that Bold BI persistent information can be saved in:

1. Physical or Virtual Machine - File System/Mounted Path
2. DB Server - MS SQL/ Postgres SQL/ My SQL
3. Azure Blob Storage
4. ReadWriteMany Storage- SMB/NFS/EFS/File Store

Physical or Virtual Machine

When using the App_Data storage type as File Storage, the App_Data information will be saved on the hosting machine itself. Therefore, it is important to take a backup of the App_Data location or the entire machine as needed. For a physical machine, you can take a backup from the following location:

If you are using a virtual machine (VM), you can either take a complete snapshot of the VM or only back up the directory mentioned above. Find the help links below to take a snapshot of the VM.

Database Server

For DB server backup and restore, refer to the following documentation link based on your DB kind and type.

On-premise DB Server

Managed DB Server

Azure Blob Storage

If you have configured Azure Blob storage when setting up the site, it is necessary to back up the Azure Blob.

ReadWriteMany Storage

For Kubernetes deployment, you need to mount the ReadWriteMany persistent volume to store Bold BI App_Data information. You can find the documentation link for backing up and restoring the ReadWriteMany storage volume based on your cloud provider.

List of Changes Required for Using Restored Resources

This section describes the list of possible changes required in the environment and Bold BI application level for using restored persistent data resources.

Restore the App_Data

Update Database Connection String

To update the database connection string, please refer to the guidance document below to reset the database connection for different environments.

If you have backed up the database on another server and the database name remains the same, following this KB article is sufficient to update both the UMS and tenant databases. How to update the tenant database information in bulk in on-premise deployments.

If you have backed up the databases on another server with different names, you need to follow both the above KB article and the documentation below.

Reset Application Database.

Change Domain Mapping or IP Binding

• If you use a domain name and restore the server from the snapshot, you can map the new IP with the same domain name.
• If you are hosting the application using the IP address and the server IP has changed, you need to update the IP address in the UMS administration page. Navigate to URL/ums/administration in the browser and ensure that the new URL is updated. If not, update the new URL on the administration page and save the changes.