vania-janet/multiturn-rag-retrieval-data huggingface dataset:
There is a tradeoff between the cost of maintaining preprovisioned compute, such as IBM Cloud Code Engine or Kubernetes Service, capacity and the risk of it taking longer than the RTO to provision or scale up the capacity needed.

Cloud capacity is not infinite. It is important to consider the possibility of capacity constraints in the backup MZR in the event the entire primary MZR is lost.

Recovery times for databases that use backup and restore depends on the size of the backup. Application owners need to take this into account when determining their RTO requirements.



 Advanced recovery profile application - MongoDB 

Zoom

![MongoDB advanced recovery application example](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/BCDR-Architecture-Diagram-image11.svg)

Figure 10. An architecture diagram showing a MongoDB advanced recovery application example

In this scenario, the data is not replicated to the backup MZR. When a disaster is declared the application team will need to create a new database instance in the backup MZR by restoring the data from backup.

The backup from the database instance in the primary MZR is available in the backup MZR even if the primary MZR is completely unavailable.

After the data is restored, the only other change that is needed is to change the DNS routing to point to the backup MZR.





 Advanced Recovery Profile Application - Bare Metal Servers and Virtual Servers on Classic Infrastructure 

Virtual Servers and Bare Metal Servers offer the capability to achieve a multi-region architecture. You can provision servers in multiple locations on IBM Cloud.

Zoom

![Server locations](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/ServersLocation.png)

Figure 11. Server locations
Geo-replicated disaster recovery (DR) 

Db2 on Cloud leverages Db2 HADR technology and gives you the ability to add a DR node, on demand, in an offsite data center of your choice. In an unlikely event that the primary data server is affected by external circumstances such as a natural disaster, you can failover to your Geo-Replicated Disaster Recovery node with a few clicks. You can also fail back to your primary site just as easily.

Admin functionality is not available on the DR node. Any admin functions must be run on the primary instance while it's Active.

DR nodes are currently set up to adopt the KMS instance and disk encrption key of the primary data server in the case that the primary data server uses Hyper Protect Crypto Services for encryption.

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

Failover to the DR site is not automatic. You must initiate the failover.

Deleting a DR configuration is currently not supported on the IBM Cloud dashboard. To delete the DR configuration, you must open a support ticket. Deleting a DR configuration removes both the primary and DR sites.

[Creating a DR node](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-dr_gendr_create_dr_node)

[Forcing a failover to the DR site](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-dr_gendr_force_failover)

[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).
Availability zones for Event Notifications 

The following table lists the high-availability (HA) status for the regions (locations) where the Event Notifications service is available:



Table 1. HA status for the regions

 Geography Region HA Status 

 Asia-Pacific Sydney (au-syd) MZR 
 Europe London (eu-gb) MZR 
 Europe Frankfurt (eu-de) MZR 
 North America Dallas (us-south) MZR 



Where:



* A geography is a geographic area or larger political body that contains one or more regions.
* A region is a defined geographic territory.



* A region might be a specific postal code area, a town, a city, a state, a group of states, or even a group of countries.
* A region contains [multiple availability zones](https://www.ibm.com/cloud/data-centers/) to meet local access, low latency, and security requirements for the region.



* MZR means multi-zone region. [Learn more](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table).







 Disaster recovery (DR) for Event Notifications service in a region 

Event Notifications service is a regional service. It does not provide automated cross-regional failover or cross-regional disaster recovery. If a regional disaster occurs, all the data might not be recovered. However, a location recovery is possible and data can be restored from that location.

If an entire MZR becomes inoperative (usually due to a catastrophic disaster or failure), IBM runs disaster-recovery plans to restore service within 24 hours or less. IBM restores the service in an alternative MZR from an IBM-managed backup. Existing DNS names are migrated to the backup deployment. When the disaster recovery process is complete, API traffic resumes automatically.

When the primary MZR is restored, the secondary deployment is migrated back to the primary site. After the migration is complete, the DNS is restored to its original routing.

For regional disaster recovery, you must create and maintain backup instances in other regions.
Understanding business continuity and disaster recovery for Netezza Performance Server 

IBM® Netezza® Performance Server for IBM Cloud Pak® for Data as a Service service gets deployed in a single zone. When a zone goes down, Netezza Performance Server service is brought online into another zone by a recovery strategy.



  Disaster recovery strategy 

Netezza Performance Server uses the cloud storage snapshot technology to provide support for business continuity and disaster recovery. A snapshot is taken every day at 2 AM. Snapshots are available across three cloud zones within the same geographical region to ensure availability if a single zone fails.

If a zone failure occurs, the disaster recovery process is automatically triggered to quickly start the service in one of the remaining zones with the latest snapshot available.
* By deploying two remote collector nodes per region, the load is removed from the analytics cluster from collecting metrics from applications that do not fail over between regions.
* The use of Veeam Replication provides a replica of the VMware Aria Operations analytics cluster to allow recovery at the recovery region.
* Only the Analytics cluster needs to be backed up with Veeam, as remote collectors do not store data, however, for ease of redeployment a backup is taken.







 AD, DNS, and NTP 

The VMware Regulated Workloads automation deploys a pair of Microsoft® Windows VMs in each instance. These VMs are configured as AD, DNS, and NTP servers. These services are independent in each region, a separate AD forest for each region, and recovery of the protected region services to the recovery region is not required.

vSphere HA provides availability of the VMs themselves and the Microsoft domain concept provides the availability of the Microsoft Windows services that runs on them. For business resiliency, configure image-level backups of the VMs and store them in the region's Veeam repository server. Configure a Veeam backup copy job to copy the backup to the other site so you can provide an off-site copy of the backup.





 Veeam 

The following use cases are expected for Veeam Backup & Replication in IBM Cloud for VMware® Regulated Workloads dual region:



* Case 1. Backup and replication of management components only.
* Case 2. Backup and replication of management components and backup of workloads.
* Case 3. Backup and replication of management components and backup and replication of workloads.



The IBM Cloud for VMware® Regulated Workloads dual region design focuses on use case 1. However, guidelines are provided so that use cases 2 and 3 can be solved for the individual needs of workload backup and replication.

Configure Veeam encryption for data at rest and data in transit so that VM data is not stored or transmitted unencrypted (which is the default setting). Veeam encryption requires the use of a password or passphrase and does not use the HPCS instance for the management of keys.
If you are running Red Hat OpenShift on IBM Cloud and not trying to get your application designated as Financial Services Validated, then you can consider [Portworx](https://portworx.com/products/portworx-enterprise//). Portworx is a highly available software-defined storage solution that you can use to manage local persistent storage for your containerized databases and other stateful apps, or to share data between pods across multiple zones.

See [Storing data on software-defined storage (SDS) with Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-portworx) for more information.







 Backup and disaster recovery for IBM Cloud services 

In addition to backing up your workloads and having the capability 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)
They are single-tenant and data plane products. They are accessed locally in customer accounts, data plane hosted on virtual resources in the customer's account, control plane security owned by IBM, and data plane security owned by the customer. IBM Cloud products of this type include IBM Cloud Kubernetes Service on classic infrastructure and Red Hat® OpenShift® on IBM Cloud® on classic infrastructure.



Table 3. Shared responsibilities for self-managed products

 Resource Incident and Operations Management Change Management Identity and Access Management Security and Regulation Compliance Disaster Recovery 

 Data Customer Customer Customer Customer Customer 
 Application Customer Customer Customer Customer Customer 
 Service instance Shared Shared Shared Shared Shared 
 Operating system Shared Shared Shared Shared Shared 
 Virtual and bare metal servers Shared Shared Shared Shared Shared 
 Virtual storage Shared Shared Shared Shared Shared 
 Virtual network Shared Shared Shared Shared Shared 
 Hypervisor IBM IBM IBM IBM IBM 
 Physical servers and memory IBM IBM IBM IBM IBM 
 Physical storage IBM IBM IBM IBM IBM 
 Physical network and devices IBM IBM IBM IBM IBM 
 Facilities and data centers IBM IBM IBM IBM IBM 



For areas marked as shared responsibilities, the customer is responsible for all the configurations, and IBM is responsible for all underlying management. For disaster recovery, the customer is responsible for creating resources in a secondary region and managing the application and data disaster recovery.





 Software packages 

Software packages are deployed by IBM as single tenant instances, and they are accessed locally in the customer account. The software instance is hosted on resources in the customer's accounts. The software deployment control plane security is owned by IBM, and the software instance security is owned by the customer.

A generic software deployment control plane manages the lifecycle of deployed software package instances. At a minimum, it manages the deployment, upgrade, and delete actions. As the packages become smarter, the generic control plane might also manage the start, stop, migration, scaling, monitoring, backup, and restore tasks.

You can find a list of software in the IBM Cloud catalog on the Software tab.



Table 4. Shared responsiblities for software packages

 Resource Incident and Operations Management Change Management Identity and Access Management Security and Regulation Compliance Disaster Recovery 

 Data Customer Customer Customer Customer Customer 
 Application Customer Customer Customer Customer Customer 
 Software packages Shared Shared Customer Customer Shared 
 Operating system Shared Shared Customer Customer Shared
IBM is responsible for the security and compliance of IBM Cloud Monitoring. You are responsible for ensuring that metrics, that contain regulated data, are not provided to the IBM Cloud Monitoring service.



Table 4. Responsibilities for security and regulation compliance

 Task IBM Responsibilities Your Responsibilities 

 Meet security and compliance objectives Maintain controls that are commensurate to supported industry compliance standards, such as SOC. Ensure that regulated data is not provided to the IBM Cloud Monitoring service. 







 Disaster recovery 

IBM is responsible for the recovery of IBM Cloud Monitoring components in case of disaster.



Table 5. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Service Automatically recover and restart service components after any disaster event. 
 Data Extract and save data, dashboards definitions, and alert definitions if you cannot afford for it to be lost in the event of an un-recoverable event. 
 monitoring agent Recovery of the monitoring agents running in your environment should they be impacted by a disaster.
As the packages become smarter, the generic control plane might also manage the start, stop, migration, scaling, monitoring, backup, and restore tasks.

You can find a list of software in the IBM Cloud catalog on the Software tab.



Table 4. Shared responsiblities for software packages

 Resource Incident and Operations Management Change Management Identity and Access Management Security and Regulation Compliance Disaster Recovery 

 Data Customer Customer Customer Customer Customer 
 Application Customer Customer Customer Customer Customer 
 Software packages Shared Shared Customer Customer Shared 
 Operating system Shared Shared Customer Customer Shared 
 Virtual and bare metal servers Shared Shared Shared Shared Shared 
 Virtual storage Shared Shared Shared Shared Shared 
 Virtual network Shared Shared Shared Shared Shared 
 Hypervisor IBM IBM IBM IBM IBM 
 Physical servers and memory IBM IBM IBM IBM IBM 
 Physical storage IBM IBM IBM IBM IBM 
 Physical network and devices IBM IBM IBM IBM IBM 
 Facilities and data centers IBM IBM IBM IBM IBM 



For areas marked as shared responsibilities, the customer is responsible for all the configurations, and IBM is responsible for all underlying management. For disaster recovery, the customer is responsible for creating resources in a secondary region and managing the application and data disaster recovery.





 Deployable architectures 

Deployable architectures can be comprised of infrastructure-as-a-service, managed products, and software. For more information about the specific responsibilities for you and for IBM when you use a deployable architecture, see [Understanding your responsibilities when using deployable architectures](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-responsibilities-deployable-architectures).
Applications that work within an active-active configuration must have a [strategy for handling conflicts](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-document-versioning-and-mvccdistributed-databases-and-conflicts) to avoid problems with multiple copies of data.
* Applications can request data from a single region by default. If the region isn't available, the application can switch to requesting data from another region. This configuration is referred to as an "Active-Passive" method. An active-passive method is characterized by the active use of only one set of data at a time.
* An application might use a hybrid configuration, where a single account is used for all data write requests, and other locations as used exclusively for read-only requests. This configuration is considered Active-Active for reads.
* In a disaster scenario, your application must reroute data requests to access the accounts that are hosted in the regions that are still online. This requirement means that your application must detect the loss of a region, and then reroute data requests.



In summary, cross-region redundancy is similar to a high availability capability, but applies to failures that affect an entire region. Configuring your applications to work correctly with cross-redundancy configurations provides real disaster recovery capability. Therefore, the applications can continue working if the data in one region isn't available for an amount of time. IBM Cloudant replication helps ensure data synchronization between regions. Your applications must "fail over" to copies of your data that is stored in other regions.





 Database backup and recovery 

[In-region automatic data redundancy](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-disaster-recovery-and-backupin-region-automatic-data-redundancy) provides applications with high availability access to data. [Cross-region redundancy for disaster recovery](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-disaster-recovery-and-backupcross-region-redundancy-for-disaster-recovery) provides applications with a means of recovering from a disaster.
The SQL Server instance from which the transaction log backup is shipping from is called the primary and the SQL Server instance where the transaction log backup is being shipped to is called the secondary. Before configuring log shipping, the database must be in full recovery model or bulk-logged mode.

The SQL Server transaction log backup settings allows addressing to a network path and backup job scheduler can be defined to run a backup job, by default, the setting is to run a backup job every 15 minutes. Once the database backup is scheduled, it creates one full backup of the database which will need to be recovered on the secondary server. During maintenance hours, a switch over from the primary server to the secondary server can be performed, log shipping disabled and the primary server decommissioned.





 Always On availability groups 

SQL Server Always On availability groups provides high availability and disaster recovery solutions and available in versions of SQL Server 2012 and later. This feature can be used to migrate your existing SQL Server databases to IBM Cloud with minimal downtime. If you have an existing Windows Server Failover Cluster with Always On availability groups, you are able to extend the cluster temporarily during migration by creating an additional secondary replica with asynchronous replication. During a maintenance window, a manual failover can be performed to enable the cut-over.





 Always On distributed availability groups 

A SQL Server Always On distributed availability group spans two distinct availability groups. Each availability group is configured on two different Windows Server Failover Clusters (WSFC), one at the source location and one in IBM Cloud VPC. The operating systems and SQL Server versions do not have to be the same version, as long as they are able to support WSFC and availability groups. This migration method is suited to re-host mission-critical SQL Server databases. The distributed availability group architecture is an efficient data transfer method as the primary replica transfers data just the forwarder replica in IBM Cloud, and then the forwarder is responsible for synchronizing data with the secondary replicas in IBM Cloud. A typical architecture is as follows:



* The source WSFC cluster hosts an Always On availability group, and has two nodes and uses synchronous replication, with automatic failover.
[Learn more about controlling access using Workload Protection teams](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-iam_grant_team).





 Security and regulation compliance 

IBM is responsible for the security and compliance of IBM Cloud Security and Compliance Center Workload Protection. You are responsible for ensuring that regulated data is not provided to the IBM Cloud Security and Compliance Center Workload Protection service.



Table 4. Responsibilities for security and regulation compliance

 Task IBM Responsibilities Your Responsibilities 

 Meet security and compliance objectives Maintain controls that are commensurate to supported industry compliance standards, such as SOC. Ensure that regulated data is not provided to the IBM Cloud Security and Compliance Center Workload Protection service. 







 Disaster recovery 

IBM is responsible for the recovery of IBM Cloud Security and Compliance Center Workload Protection components in case of disaster.



Table 5. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Service Automatically recover and restart service components after any disaster event. 
 Data Extract and save data and alert definitions if you cannot afford for it to be lost in the event of an un-recoverable event. 
 Agent Recovery of the agents running in your environment should they be impacted by a disaster.
Understanding your responsibilities when you use Hyper Protect Virtual Servers 

Find out more about the management responsibilities and terms and conditions that you have when you use Hyper Protect Virtual Servers.

For a high-level view of the service types in IBM Cloud® and the breakdown of how the responsibilities are shared between the customer and IBM for each service type, see [Shared responsibilities for using IBM Cloud offerings](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

Review the following sections for the specific responsibilities for you and for IBM when you use Hyper Protect Virtual Servers. For the overall terms of use, see [IBM Cloud® Terms and Notices](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms).



  Disaster recovery 

Data is stored on a high available storage unit within the data center only.



Table 1. Responsibilities for disaster recovery

 Task             IBM Responsibilities  Your Responsibilities         

 Virtual Server                         Backup and restore strategy.  
 Virtual Storage                        Backup and restore strategy.