vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Understanding disaster recovery for IBM Cloud Data Security Broker 

Components of the Data Security Broker data protection services do not require any protected data to be stored or cached to operate. This guarantees that the data is not lost if any Data Security Broker component fails or goes down. In Data Security Broker components, only policy configurations and metadata is stored, and all this data is recoverable.

It is possible to back up the configurations and metadata stored in a Data Security Broker deployment and recover them after a significant outage, facilitating quick service restoration in a disaster recovery scenario. This section outlines the procedures for backing up and restoring the Data Security Broker deployment.



 Backup considerations 

The following services are required for a complete Data Security Broker deployment:



* Key management services
* Database
* IBM Cloud® Object Storage



Ensure that the backup schedule for these services align with the Data Security Broker backups. Additionally, administrators must keep records which are used for linking the Data Security Broker backup and the backups of the other services, as well as all backups for the Data Security Broker deployment and the above mentioned services, in a secure location.





 Backup procedure 

In Data Security Broker Manager, all configuration and metadata data needed for a Data Security Broker deployment is stored. Data Security Broker Manager's most recent configuration is always accessible to Data Security Broker Shields. As a result, Data Security Broker Manager is the only part of Data Security Broker that requires backup.





 Backing up Data Security Broker Manager deployed on IBM Cloud cluster or (Red Hat OpenShift) cluster 

Data Security Broker Manager instances running in a Kubernetes cluster or Red Hat OpenShift cluster require network access to the cluster as well as access to the workstation with permission to execute Kubernetes or Red Hat OpenShift command line tools. Additionally, the workstation must have a directory with write permissions and sufficient storage to store the backup. 125GB of storage space is sufficient for all deployments.

To take a backup, follow these steps:



1. Access the cluster where Data Security Broker Manager is deployed by logging into a Kubernetes or Red Hat OpenShift workstation.
2. To back up the MongoDB collections and Data Security Broker Manager configuration files, create the script provided below and execute it.
12. Implement business continuity and disaster recovery 

Requirement: Implement a system for business continuity and disaster recovery (BCDR). Define Recovery Point Objective (RPO), Recovery Time Objective (RTO), and Maximum Tolerable Downtime (MTD) metrics for essential business functions. Implement your application so that the metrics are achieved.

Purpose & value: Unfortunately, disasters occur that can make some or all of the data centers in a region unavailable. To avoid data loss, you must ensure all important data is backed up to a separate multizone region that can be used to restore service. However, your consumers must be able to opt out of having their data stored in the alternate region based on their data residency requirements.

In addition, you must follow best practices for BCDR as defined by the specific managed services that you use. For example, Direct Link, Hyper Protect Crypto Services, etc.

Implementation guidance:



* [VPC reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-bcdr)
* [Satellite reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-bcdr)



Most Relevant Controls:



Table 12. Related controls for business continuity and disaster recovery

 Family Control
Disaster recovery and backup 

IBM Cloud® Data Engine stores information about submitted jobs, such as SQL statements, job status, job IDs, and database catalog information like table and views. If a disaster occurs, the regular backups ensure that no more than 24 hours of data are at risk of loss. Backups are done automatically, so no action is required on your side.

The job results are stored in IBM Cloud® Object Storage and are independent of any Data Engine disaster recovery.

If a region becomes unavailable due to a disaster, the IBM Cloud® team works to get the region available again. You can route your workload to a different region by creating a new instance in an available region. In case you worked with tables or views, you must create those tables in the new instance and region again. Indexes are still available, if they are saved in available buckets, such as cross region buckets, but you must set the corresponding base location. Depending on the location and size of your data, it is possible that the jobs take longer.

Until recovery completes, you cannot use your instances that were created in the affected location. When data recovery completes, job history is available for the instances again.



  Restoring a deleted service instance 

After you delete an instance of the Data Engine service, you can restore the deleted service instance within the data retention period of seven days. After the seven-day period expires, the service instance is permanently deleted.

To view which service instances are available for restoration, use the [ibmcloud resource reclamations](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamations) command. To restore a deleted service, use the [ibmcloud resource reclamation-restore](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamation_restore) command. To view the details of a resource reclamation, use the [ibmcloud resource reclamation](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_reclamation) command, with the --output JSON option.
IBM Cloud Disaster Recovery (DR) and Backup and Restore 

Local service interruption can be caused by many things: hardware failures, bugs, power failures, planned and unplanned maintenance. To minimize a single point of failure, IBM Cloud® architects create resilient designs that have multiple virtual server instances to provide the highest availability.

However, extreme failure events, such as data center wide failures due to network outages, natural disasters, or ransomware are harder to anticipate and plan for. Your Business Continuity and Disaster Recovery (BCDR) plan becomes a critical part of recovering from these types of events. Business continuity focuses on the processes and procedures that you implement to help your people minimize interruptions to business operations. Disaster recovery focuses on the IT components and restoring systems after a disaster.



 Disaster recovery components 

The DR model has two main components that deal with what can be tolerated:



* Recovery Time Objective (RTO) - the maximum time that the service can be down.
* Recovery Point Objective (RPO) - the maximum amount of data loss.



Zoom

![DR backup diagram.](https://cloud.ibm.com/docs-content/v1/content/df269b100c3499f1efcbb7d030dce8dec25c539b/ha-infrastructure/images/ha-DR-backup-diagram.svg)

Figure 1. DR backup diagram

These values are directly correlated to both cost and complexity. A lower amount of time and data loss equates to higher cost and complexity.





 DR Strategies 

You can implement your DR strategy in one of two ways:



 Strategy Description Benefits 

 Cold (Active/Standby) With a Cold DR strategy, your solution is running in one environment and duplicate resources are available on standby. When an event occurs, you react and build up the standby site. A cold strategy is a reactive approach, where the upfront cost is minimal, other than storage costs for snapshots and backups. The cold approach typically entails higher RPO/RTO times and is simple to implement.
* A design document explains how load balancing is used to keep a service highly available.
* Where multi-site failover occurs, the disaster recovery plan must explain who does what to cause the failover and ensure restart.
* The disaster recovery plan must define how the solution works and include restore point objectives that clearly explain how much data might be lost in the outage, if any. The disaster recovery plan also includes a detailed recovery workflow for restoring services and data if a multi-availability zone failure.
* It must confirm how the Maximum Tolerable Downtime is met and be stored on the Disaster Recovery Plan database.
* The disaster recovery plan specifies the security controls for running in Disaster mode, if they are different from what's running in production.







 Management of the disaster recovery plan 

The requirements that IBM Cloud follows are:



* The disaster recovery plan must be updated after any major infrastructure change, major application release, and after any test.
* It must be approved annually.
The first column describes the task that a customer or IBM might be responsibility for. The second column describes IBM responsibilities for that task. The third column describes your responsibilities as the customer for that task.

 Item IBM responsibilities Your responsibilities 

 Encryption Provide secure SSL connections to administration portals and replication endpoints. Workload can be deployed by using AES 256-bit encrypted data stores with unique key per customer instance. Backups are encrypted uniquely per customer. Choose encrypted data stores when you are deploying workloads into the environment where appropriate. Use encrypted networking for workload to workload and workload to IBM Cloud Service connections. Use the IBM Cloud private network where appropriate. 







 Disaster recovery 

Disaster recovery includes tasks such as providing dependencies on disaster recovery sites, provision disaster recovery environments, data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.



Table 5. Responsibilities for disaster recovery
The rows are read from left to right. The first column describes the task that a customer or IBM might be responsibility for. The second column describes IBM responsibilities for that task. The third column describes your responsibilities as the customer for that task.

 Item IBM responsibilities Your responsibilities 

 Backup of management configuration data Conduct backups of the management component configurations. These backups include single-tenant vCenter Server, VMware NSX-T, VMware Cloud Director™, and service configurations. Offsite immutable backup copies are enabled in an independent backup account and they run daily. 
 Backup of workloads Enable backup services for customer workload. Choose and implement a backup provider for critical workloads. For more information, see [Understanding business continuity and disaster recovery](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-bc-dr). 
 Recovery of configuration Conduct recovery in the original data center after the infrastructure is available. 
 Recovery of workloads Restore capabilities are available in normal operations. For configuration restores, provide customer restore services after the infrastructure is available. If an offsite recovery is required, IBM works with the customer to help recover.
Your disaster recovery plan includes knowing, preserving, and being prepared to restore all data that is maintained on IBM Cloud.





 Backing up your data in Watson Discovery 

There are several methods for backing up the data that is stored in IBM Watson® Discovery. Consider including these methods in your disaster recovery plan. Also, consider backing up the following data types:



* Data that you might want a copy of, such as source documents
* Data that Discovery stores and that you want to extract and back up



The following table shows the resources that you can download and re-upload to and from an instance.



Resource recovery support details
This table has row and column headers. The row headers identify resources. The column headers identify the different types of recovery support. To understand which recovery methods are supported for a resource, go to the row that describes the resource, and find the column for the recovery method that you are interested in.

 Resource Download/Re-upload from the UI API support 

 Uploaded and crawled files See note. 
 Relevancy training data ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/icons/checkmark-icon.svg) 
 Expansion list ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/icons/checkmark-icon.svg) 
 Stop words list ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f16b1f78a92498247223b337bd9303c2758b9ba8/icons/checkmark-icon.svg) 
 Smart Document Understanding user-trained model !
Understanding business continuity and disaster recovery for Planning Analytics as a Service 

Disaster recoveryinvolves a set of policies, tools, and procedures for returning a system, an application, or an entire data center to full operation after a catastrophic interruption. It includes procedures for copying and storing an installed system's essential data in a secure location, and for recovering that data to restore normalcy of operation.



  Responsibilities 

See [Shared responsibilities for IBM products.](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities) for details on responsibility ownership between IBM and the customer when using Planning Analytics as a Service.





  Disaster recovery strategy 

IBM Cloud has

business continuityplans in place to provide for the recovery of services within hours if a disaster occurs. You are responsible for your data backup and associated recovery of your content.

Planning Analytics as a Service provides mechanisms to protect your data and restore service functions. Business continuity plans are in place to achieve targeted

recovery point objective(RPO) andrecovery time objective(RTO) for the service. The following table outlines the targets for Planning Analytics as a Service.



Table 1. RPO and RTO for Planning Analytics as a Service

 Disaster recovery objective  Target Value 

 RPO                          24 hours     
 RTO                          4 hours
Managing your data in VMware Shared 

Review the following data storage, high availability, and disaster recovery considerations before you order IBM Cloud® for VMware Solutions Shared.



 Data security 

VMware Shared supports data storage in the form of:



* VMware Cloud Director virtual machine (VM) instances
* VMware Cloud Director customer media uploads
* VMware Cloud Director customer templates
* VMware Cloud Director independent disks
* Veeam® backups



All VMware Cloud Director data is stored in multitenant datastores where the datastores are secured by VMware Cloud Director. A significant portion of VMware Cloud Director security, especially in protecting cloud tenants from internal threats, comes from the security of the underlying virtualization layer. This includes VMware vSphere®, the additional security of VMware Cloud Director, and the security of the ESXi™ hosts themselves. The VMware Cloud Director abstraction separates different organizations from each other. Different organizations cannot modify or see each other's organizations data at rest or data in motion.

VMware Cloud Director data storage uses IBM Cloud Infrastructure Endurance File Storage, which is encrypted at rest to Endurance File Storage specifications. When VMware Cloud Director data is deleted, it becomes available for reallocation where it is then zeroed out and instantiated for the next use case.

Veeam service backups are to both IBM Cloud Infrastructure Endurance File Storage and Cloud Object Storage for longer term storage. When the first VMware Shared virtual data center is created, a unique encryption key is generated for each customer organization. It is used to encrypt all Veeam backups for that specific customer's organization. The encryption key is not stored and is unavailable to IBM. After the VMware Cloud Director Data Center is deleted, all backups are deleted, and cannot be recovered.





 High availability and disaster recovery 

The VMware Shared management service is initially only offered in the IBM Cloud NA South and Europe regions. Recovering from potential disasters that affect an entire location requires planning and preparation.



* You are responsible for understanding your configuration, customization, and usage of the service.
In all cases, after the infrastructure is available, data is then restored from backup before activating the passive deployment.





 Activating the alternative region 

Should a regional outage occur, an alternative region can be activated following pre-established and tested procedures. These procedures can include deploying infrastructure in the region by using project configurations that were created and tested in advance so that error free deployments can readily be accomplished. If pre-existing projects are not maintained, project configurations can be restored from backup and modified to target the alternative region.

Platform services such as enterprise accounts, accounts, IAM, and catalog are global and thus are not affected by regional outages. The enterprise account hierarchy, private catalogs, and all IAM configuration can continue to be used unchanged during a disaster recovery process. Regional service instances that include networking, VPC, various compute, storage, and databases must be recovered in the new region.









 Backups 

Backups must be stored in a different region from the workload, and ideally in a separate backup account. This separation in location and management domain (account) minimizes the chances that an outage, operational error, or security breach that affect the workload will also affect the backup. Backup regions should be multi-zone IBM Cloud regions or highly available Satellite regions. However, each family of services on IBM Cloud has its own backup mechanism that introduces some limitations that impact this overall strategy. For more information, see [service considerations](https://cloud.ibm.com/docs/enterprise-account-architecture?topic=enterprise-account-architecture-bcdrservice-considerations).

In addition, a "disaster recovery kit" should be developed and stored outside of IBM Cloud. The disaster recovery kit is an off-site and protected repository that includes hardware, software, and system secure configurations, one-time keys, and the disaster recovery plan. Use this disaster recovery kit during an incident response to restore services.



 Infrastructure as code 

Infrastructure as code ensures that good backup practices are implemented in a uniform way across the organization. Include implementation of backups as part of deployable architectures. Keep backup configuration close to provisioning code so that it is easier to ensure that backups are adjusted as information system changes occur. Create and configure backup accounts as code.
Business continuity and disaster recovery overview 

Business continuity and disaster recovery (BCDR) is important for all cloud-based applications, and it is all the more critical for the kind of regulated workloads that the IBM Cloud for Financial Services is intended to host. In the event of a disaster, consumers depend on service being restored quickly without loss of data. Using the VPC reference architecture and following the controls of the IBM Cloud Framework for Financial Services help you achieve that goal. When building a BCDR solution in IBM Cloud, you need to consider your workloads that run in virtual servers or Red Hat OpenShift on IBM Cloud and the BCDR characteristics of all of the other IBM Cloud services your solution depends on.



 Requirements 

The following sections describe some of the requirements that you must follow for BCDR of your workloads.



 Alternative storage site 

You must establish and configure an alternative storage site in at least one geographically separate IBM Cloud multizone region. So, if the storage in one region becomes unavailable, you can use storage from another region.





 Information system backup 

As the provider, you must:



* Conduct backups of user-level information contained in the information system
* Conduct backups of system-level information contained in the information system
* Conduct backups of information system documentation, including security-related documentation
* Protect the confidentiality, integrity, and availability of backup information at storage locations



The different levels of information are defined as follows:



* User-level information - Consumer/consumer-managed data
* System-level information - Data you manage that is necessary to meet your service's Recovery Point Objective (RPO). For example, system-state information, operating system and application software, licenses, and so on.
* System documentation - External documentation, internal architecture documentation, run books, and so on.



Other requirements:



* Backups must be at least incremental daily and full weekly.
* Backups must be monitored. Failed backups must be investigated and corrective action that is documented as necessary to maintain the service's RPO.
* Backups and backup logs should be accessible only to authorized individuals who need access to do their jobs.
* Transaction-based systems must implement transaction recovery.
High availability and disaster recovery 

IBM Watson® Knowledge Studio is highly available within multiple IBM Cloud locations (for example, Dallas and Washington, DC). However, recovering from potential disasters that affect an entire location requires planning and preparation.

You are responsible for understanding your configuration, customization, and usage of the service. You are also responsible for being ready to re-create an instance of the service in a new location and to restore your data in any location. See [How do I ensure zero downtime?](https://cloud.ibm.com/docs/overview?topic=overview-zero-downtimezero-downtime) for more information.



 High availability 

Knowledge Studio supports high availability with no single point of failure. The service achieves high availability automatically and transparently by using the multi-zone region (MZR) feature provided by IBM Cloud.

IBM Cloud enables multiple zones that do not share a single point of failure within a single location. It also provides automatic load balancing across the zones within a region.





 Disaster recovery 

Disaster recovery can become an issue if an IBM Cloud location experiences a significant failure that includes the potential loss of data. Because MZR is not available across locations, you must wait for IBM to bring a location back online if it becomes unavailable. If underlying data services are compromised by the failure, you must also wait for IBM to restore those data services.

If a catastrophic failure occurs, IBM might not be able to recover data from database backups. In this case, you need to restore your data to return your service instance to its most recent state. You can restore the data to the same or to a different location.

Your disaster recovery plan includes knowing, preserving, and being prepared to restore all data that is maintained on IBM Cloud. This stored data includes the training data for your models.

Re-creating models from saved data takes time. You can maintain parallel service configurations in multiple locations to help eliminate the turnaround time associated with disaster recovery.



 Disaster recovery for models 

For models, understand which data can be backed up, restore and re-create necessary artifacts, and then retrain and redeploy the models.



 Backing up data 

Some data can be backed up, and some must be re-created: