vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Understanding disaster recovery 

When dealing with improved resilience, it important to make some distinctions between

high availability(HA) anddisaster recovery(DR).

HA is mainly about keeping the service available to the users when ordinary activities are performed on the system like deploying updates, rebooting the hosting virtual machines, applying security patches to the hosting OS, and so on. For our purposes, high availability within a single cloud region (

MZR) can be achieved by eliminating single points of failure. For more information on HA, see [Considerations for high availability](https://cloud.ibm.com/docs/overview?topic=overview-ha-considerations).

HA usually doesn’t deal with major unplanned or planned issues, such as complete site loss because of major power outages, earthquakes, severe hardware failures, full site connectivity loss, and more. In such cases, if the service must meet strict Service Level Objectives (SLO), you should make the whole application stack (infrastructure, services, and application components) redundant by deploying it in at least two different cloud regions. This is typically defined as a DR architecture.

The benefits of using a [DR orchestrator](https://cloud.ibm.com/docs/overview?topic=overview-cloud-resiliency-orchestrator) are covered in the context of a cloud environment and its fast changing behavior. You might require several integrations with management tools and services in IBM Cloud®. Examples throughout these best practices are provided to demonstrate the native capabilities and documentation currently available to implement DR for IBM Cloud services and suggest additional services that are often required to implement an enterprise-level resiliency solution.

The best practices in this section are based on the services and features currently available and might change over time. We recommend that you verify possible changes or additional features that might apply to your environment.



 General disaster recovery strategy 

The approach to defining your DR strategy needs to be systematic and start with the application or service, which is defined as a set of compute resources, for example Kubernetes apps, virtual machines, services, and more, that make up a business application.

While a holistic approach might be wanted, the reality is that each business application (cloud service) is independent, with its own
Business continuity and disaster recovery for Satellite reference architecture 

As described in [Business continuity and disaster recovery (BCDR) overview](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdr), BCDR is important for all cloud-based applications. You will learn about specifics of BCDR in the Satellite reference architecture.



  BCDR in your Satellite location 

See the [Disaster recovery](https://cloud.ibm.com/docs/satellite?topic=satellite-responsibilitiesdisaster-recovery) section of Satellite for more information.





  Backup and disaster recovery for IBM Cloud services 

In addition to backing up your workloads and being able to restore service in the face of a disaster, your BCDR strategy needs to consider all of the IBM Cloud services in your deployment. See [Backup and disaster recovery for IBM Cloud services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdribm-cloud-services).





  Related controls in IBM Cloud Framework for Financial Services 

See [related controls for backup and recovery](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdrrelated-controls).





  Next steps 



*  [High availability overview](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-high-availability)
Backing up your data in Watson Discovery 

There are several methods for backing up the data 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



Some data you cannot back up and must be recreated. For example, feedback events.



 Ingested documents 

Your uploaded documents are converted, enriched, and stored in the search index. In the event of a disaster, the search index is not recoverable. Store a backup of all your source documents in a safe place.

If you also import documents by doing scheduled crawls of external data sources, you might want to retain your data source credentials externally so that you can re-establish your data sources quickly. For the list of available sources and the credentials needed for each one, see [Connecting to data sources](https://cloud.ibm.com/docs/discovery?topic=discovery-sources).





 Configurations 

Back up your instance configurations, and store them locally.

To back up these configurations, first [list your configurations](https://cloud.ibm.com/apidocs/discoverylist-configurations) for each instance.

After obtaining the list of configurations, [get the details](https://cloud.ibm.com/apidocs/discoveryget-configuration-details) for each configuration.





 Training data 

Back up your training data for each trained collection, and store it locally.

Training data is used for explicit training of your collections and is stored on a per collection basis.

To extract the training data, use the API to download the queries and the ratings from Discovery.



1. [List the training data](https://cloud.ibm.com/apidocs/discoverylist-training-data)
2. [List the examples](https://cloud.ibm.com/apidocs/discoverylist-examples-for-a-training-data-query) for each query.
3.
Includes tasks such as monitoring, event management, high availability, problem determination, recovery, and full state backup and recovery.





 Change management 

Includes tasks such as deployment, configuration, upgrades, patching, configuration changes, and deletion.





 Identity and access management 

Includes tasks such as authentication, authorization, access control policies, and approving, granting, and revoking access.





 Security and regulation compliance 

Includes tasks such as security controls implementation and compliance certification.





 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.
High availability and disaster recovery 

IBM Watson® Assistant 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 Watson Assistant. 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 

Watson Assistant supports high availability with no single point of failure. The service achieves high availability automatically and transparently by using the multi-zone region 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 the multi-zone region feature 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. See [Backing up and restoring data](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-backup-restore) for information about how to back up your service instances.
This applies to every aspect of the managed cloud services, such as backup policies and frequency, committed RPO/RTO if you used for example a database as a service option, and so on. This could generate relevant savings in the costs of the DR solution.





 Resources for disaster recovery implementations 

It is important to have a clear view of the ownership or control of the DR implementation. Check [Shared responsibilities](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities) for a detailed outline for the responsibilities and roles for each service offered by IBM Cloud.

The [IBM Cloud service level objectives](https://cloud.ibm.com/docs/overview?topic=overview-slo) documentation provides links to the available high availability, DR, and backup information for the IBM Cloud services that can be used as reference documentation in designing and implementing the DR plan.

More documentation resources:



* [Designing an architecture for your application resiliency objectives](https://cloud.ibm.com/docs/overview?topic=overview-bcdr-app-recovery)
* [Build resilient applications on the cloud](https://www.ibm.com/cloud/architecture/architectures/resilience/overview)
* [Secure web applications across multiple regions](https://cloud.ibm.com/docs/tutorials?topic=solution-tutorials-multi-region-webappsecure-web-application-across-multiple-regions)
* [Resilient and secure multi-region Kubernetes clusters with IBM Cloud Internet Services](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-multi-region-k8s-cis)
Regional resiliency will spread data across a single metropolitan area.

A Single Data Center will only distribute data across devices within a single site.

For more information, see [Select regions and endpoints](https://cloud.ibm.com/docs/services/cloud-object-storage?topic=cloud-object-storage-endpoints).
6. Choose the type of Storage class.

You can create buckets with different storage classes. Choose the storage class for your bucket based on your requirements to retrieve data. For more information, see [Use storage classes](https://cloud.ibm.com/docs/services/cloud-object-storage?topic=cloud-object-storage-classes).

Note: It is not possible to change the storage class of a bucket once the bucket is created. If objects need to be reclassified, it is necessary to move the data to another bucket with the wanted storage class.
7. Optionally, add a Key Protect Key to encrypt data at rest.

All objects are encrypted by default using randomly generated keys and an all-or-nothing-transform. While this default encryption model provides at-rest security, some workloads need to be in possession of the encryption keys used. For more information, see [Manage encryption](https://cloud.ibm.com/docs/services/cloud-object-storage?topic=cloud-object-storage-encryption).







 Step 4. Create a service ID for the IBM Cloud Object Storage instance 

A service ID identifies a service similar to how a user ID identifies a user. Service IDs are not tied to a specific user. If the user that creates the service ID leaves your organization and is deleted from the account, the service ID remains.

You must create a service ID for your IBM Cloud Object Storage instance. This service ID is used by the IBM Cloud Activity Tracker instance to authenticate with your IBM Cloud Object Storage instance.

You must assign specific access policies to the service ID that restrict permissions for using specific services, or even combine permissions for accessing different services.

Complete the following steps to create a service ID with writing permissions for the IBM Cloud Object Storage instance:



1.
BCDR networking aspects 

Review the key aspects in network design that might impact the disaster recovery (DR) solution, including the common five network types, local area network (LAN) and wide area network (WAN) considerations, and the impact of partial failover.

In a DR solution, we can basically classify the networks in five types:



* Management/Monitoring
* Replication
* Disaster recovery test
* Failover (or emergency)
* Fallback



In the cloud, the concept of these networks continues to be valid but might need to be implemented considering the specific network services and policies.



 Management/Monitoring 

The management/monitoring network type is the least demanding connectivity in terms of bandwidth since it must sustain only the following:



* Administrator access to remote systems
* Monitoring, logging, and support activities (SNMP, traps, logging, and so on)
* Antivirus and security patches



You can normally create network tunnels within the replication network to sustain these functionas.





 Replication 

Replication is the connectivity that is required to duplicate data from a primary to a DR site. It’s mainly determined by the synchronization method:

Online full synchronization
: In the online synchronization, a full copy of the entire volume, including empty spaces, is transmitted over the network to the DR site with delta updates that are captured and sent too. In the online synchronization, you should consider that this might not be a one-shot operation. Sometimes, you need to periodically perform a full-refresh of the replicated data, or perform bulk-transfer of a good portion of your source data.

Offline synchronization
: In the offline synchronization, most of the data is made available at the DR site through alternative means (disk images), therefore only delta updates that are captured and sent will traverse the network. If this meets the network requirement for replication, you should pay attention to the frequency that you need for the periodic refresh since this might impact yourrecovery time objective(RTO) andrecovery point objective(RPO).

Another consideration is that a replication network must work in two ways:



1. To the DR site.
The RPO for DR backups on IBM Cloud is 1 week. The RTO if a disaster occurs is dependent upon the size of the database – 1.5 hours per terabyte of data.





 Amazon Web Services 

When deployed on Amazon Web Services, a full backup of the database is taken once a day for disaster recovery. This DR backup is encrypted and stored in Amazon Web Services S3.

DR backups of the last 7 days are retained by default. The RPO for DR backups on Amazon Web Services is 24 hours. The RTO if a disaster occurs is 4 hours.





 Brazil: Supplementary Rule 14 (applies to systems provisioned for the Brazilian federal government) 

At this time, the disaster recovery (DR) option for Db2 Warehouse on Cloud offerings is not available in Brazil for the federal government due to Supplementary Rule 14.
[Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-about-cloud-object-storage) stores encrypted and dispersed data across multiple geographic locations. Object Storage is available with three types of resiliency: Cross Region, Regional, and Single Data Center. Cross Region provides higher durability and availability than using a single region at the cost of slightly higher latency. Regional service reverses those tradeoffs, and distributes objects across multiple availability zones within a single region. If a given region or availability zone is unavailable, the object store continues to function without impediment. Single Data Center distributes objects across multiple machines within the same physical location.

Users of Object Storage refer to their binary data, such as files, images, media, archives, or even entire databases as objects. Objects are stored in a bucket, the container for their unstructured data. Buckets contain both inherent and user-defined metadata. Finally, objects are defined by a globally unique combination of the bucket name and the object key, or name.

All Object Storage buckets must be encrypted with KYOK by using keys that are managed by Hyper Protect Crypto Services. For more information, see [Encryption at rest](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-encryption-at-rest). In addition, a geographically separate region should be used as an [alternative storage site](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-bcdryour-workloads-requirements-alternate-storage-site). This means you should use [cross region resiliency](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints-geo) for all of your Object Storage buckets.

To start working with Object Storage, see the following instructions:
You can manage your keys manually by supplying your own encryption keys - referred to as Server-Side Encryption with Customer-Provided Keys (SSE-C).





 Archive rules 

IBM Cloud® Object Storage Archive is a low-cost option for data that is rarely accessed. You can migrate data from any of the storage tiers (Standard, Vault, Cold Vault, and Flex) to a long-term offline archive.





 Retention policies 

Immutable Object Storage maintains data integrity in a WORM (Write-Once-Read-Many) manner. Objects can't be modified until the end of their retention period and the removal of any legal holds.





 Aspera high-speed transfer 

Aspera high-speed transfer improves data transfer performance under most conditions, especially in networks with high latency or packet loss. Instead of the standard HTTP PUT, Aspera high-speed transfer uploads the object by using the [FASP protocol](https://www.ibm.com/products/aspera/technology).
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 the 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.

 Task IBM Responsibilities Your Responsibilities 

 General <br><br> * Restore or rebuild the provisioning environments in the affected regions.<br> * Restore existing Spark clusters, where possible.<br><br><br> <br><br> * Track instance state.<br> * Provision new Spark instances in alternatively available regions.<br> * Ensure that the Spark instance is stateless by making sure that all data, metadata and applications reside outside of the cluster. This activity must be completed before disaster recovery can be initiated.<br> * Provision a new service instance in an alternatively available region if the current instances can't be accessed.<br> * Track instance state.<br><br><br>
[Forcing a failback to the primary site](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-dr_gendr_force_failback)



 High Availability vs. Disaster Recovery 

Db2 on Cloud High Availability plan offers Db2 HADR SYNC and ASYNC nodes technology to deliver superior availability and reliability, within the same region. When required, failover to the HA nodes is managed seamlessly and automatically by IBM using automatic client reroute (ACR). HA plans reside within a single MZR or SZR region.

With the introduction of Geo-Replicated Disaster Recovery nodes, you are now able to extend that availability to an entirely different region by adding an on-demand Disaster Recovery node. This ability ensures that you can still access your data in the unlikely event of an outage in your primary region. For example, primary instance: Dallas; DR node: London.





 Enterprise and Standard HADR plans 

DR nodes are now available for Enterprise and Standard HADR plans only. DR nodes are currently not supported in single node plans or in EU-Cloud.



 Creating a DR node 



1. Select Administration from the left menu, then select the Disaster recovery tab.

Zoom

![View of the Disaster Recovery page](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/images/dr_1_v2.jpg)

Figure 1. View of the DR page
2. Select a data center for the DR node and click Enable disaster recovery.

Zoom

![Select a DR data center](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/images/dr_2_v2.jpg)

Figure 2. Select a data center for the recovery node
3.
You don't need to do anything to enable this internal data replication.

In-region data redundancy enables high availability protection. Specifically, in-region data redundancy provides protection for your data against hardware failure within the region. When a hardware unit within the region fails, only the copy of your data that is stored on that unit is no longer available. Your applications stay usable because IBM Cloudant automatically routes requests to the copies of your data that is still available on other hardware units within the region. Meanwhile, automatic monitoring of systems detects the hardware unit failure, prompting action and subsequent restoration of full redundancy.

IBM Cloudant accounts are located within a single region, which means the data that you store within your account is stored across separate servers, each of which is hosted within that single region.

In-region automatic data redundancy is limited to the following functions:



1. Providing protection within a single region only.
2. Maintaining current data.



To provide protection across more than the single region associated with your account, use [Cross-region redundancy for disaster recovery](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-disaster-recovery-and-backupcross-region-redundancy-for-disaster-recovery). To provide protection for the "history" of your data, use data snapshots that are created by [database backup and recovery](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-disaster-recovery-and-backupdatabase-backup-and-recovery) tools. For example, you can enable auditing of changes that are made to data by applications.

In-region data redundancy enables a High Availability capability that provides tolerance for failures that affect single systems within the region.





 Cross-region redundancy for disaster recovery 

The IBM Cloudant replication feature helps you build a flexible disaster recovery capability into your applications. The main way to enable disaster recovery is to use IBM Cloudant replication to create redundancy across regions. The result is that your application can tolerate the situation where one or more regions isn't available.

The basic steps in creating cross-region redundancy are included in the following list:



1.