vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In the event of a disaster, the only change that is needed will be to reconfigure DNS to point to the cluster in US East.

Benefits
: Fastest recovery time, dependent only on the time it takes to verify that the data was replicated and make the DNS switch.

Impacts
: Cost. To support the RTO, the only viable option is the active/hot-standby model.
: Development teams need to update their deployment pipelines to also deploy their apps to the standby IBM Cloud Code Engine project every time they deploy to production. And, validate that it was successful.





 Continuous Availability profile application - PostgreSQL 

Zoom

![PostgreSQL example application architecture](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/BCDR-Architecture-Diagram-Image9.svg)

Figure 8. PostgreSQL example application architecture

In this scenario, the data is replicated automatically by IBM Cloud Databases to a read-only replica in the backup MZR. In the event of a disaster, the application team needs to manually trigger a promotion of the read-only replica to become the leader. This action will take some time as a read-only replica of the service instance is not configured using a high availability (HA) topology. When the promotion occurs, several steps happen to elevate the instance to an HA configuration.

The only other change that is needed is to reconfigure DNS to point to the cluster in US East when the database promotion is complete.

Benefits
: Faster recovery time, as the data is already replicated to the backup MZR. There is still some latency related to the time it takes to reconfigure the database to an HA configuration.

Impacts
: Cost. To support the recovery time objective the only viable option is the active/hot standby model.
: Development teams need to update their deployment pipelines to also deploy their apps to the standby IBM Cloud Code Engine project every time they deploy to production.
Use the API, SDK, CLI, or console tools to apply the provided updates for the local entities (app code, CLI, and SDK). 







 Identity and access management 

You and IBM share responsibilities for controlling access to your IBM Cloud App Configuration instances and resources.

You are responsible for identity and access management to your application and application data.



Table 3. Responsibilities for identity and access management

 Task IBM Responsibilities Your Responsibilities 

 Applications Restrict access to resources. Depending on your needs, restrict access to resources and service functions by using Cloud IAM access policies. For more information, see [Managing user access](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-service-access-management). 







 Security and regulation compliance 

IBM is responsible for the security and compliance of IBM Cloud App Configuration.

You are responsible for the security and compliance of your application and application data.



Table 4. Responsibilities for security and regulation compliance

 Task IBM Responsibilities Your Responsibilities 

 Encryption <br><br> * Automatically apply security patch updates for infrastructure.<br> * Enable certain security settings, such as encrypted disks.<br> * Disable certain insecure actions, such as allowing users to SSH into the host.<br> * Encrypt communication with TLS.<br> * Continuously monitor IBM Cloud App Configuration entities to detect vulnerability and security compliance issues.<br> * Integrate IBM Cloud App Configuration with IBM Cloud Identity and Access Management (IAM).<br><br><br> Manage IBM Cloud credentials, and keep credentials secure. 







 Disaster recovery 

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

You are responsible for the recovery of the workloads that run IBM Cloud App Configuration and your application and application data.



Table 5. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities
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 recover, the customer is responsible for creating resources in a secondary region and managing the application and data disaster recovery.





 Managed products 

Products that are managed by IBM require customer responsibilities only for the data or applications that customers add to the service. They are multi-tenant, accessed remotely, hosted on IBM virtual resources, created in IBM-owned accounts, and have control plane and data plane security that is owned by IBM. Examples of this product type are IBM Cloud databases or IBM Cloudant database instances. You can find a list of these types of products in the IBM Cloud catalog on the Services tab. However, any products that are listed in an infrastructure subcategory are infrastructure-as-a-service type products.



Table 2. Shared responsibilities for fully-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 IBM IBM IBM IBM Shared 
 Virtual and bare metal servers IBM IBM IBM IBM IBM 
 Virtual storage IBM IBM IBM IBM IBM 
 Virtual network IBM IBM IBM IBM IBM 
 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 disaster recovery, IBM is responsible to ensure that other regions that are not impacted by the disaster are fully operational and will recover the impacted region by the disaster as quickly as possible.





 Managed products on customer's resources 

Managed products on customer's resources are orchestrated by IBM. 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
For information on collecting a performance baseline, refer to [Creating a baseline](https://cloud.ibm.com/docs/vlans?topic=vlans-mssql-baseline).

This documentation focuses on three deployment patterns in IBM Cloud VPC leveraging Availability Zones (AZ) and Multi Zone Regions (MZR):



* Single AZ deployment pattern - This pattern is suitable for development or test databases that do not require high availability or rapid disaster recovery. Backups taken, using products like IBM Spectrum Protect or Veeam, can be used if required, to restore databases on failure.
* Dual AZ deployment pattern - This pattern is suitable for production databases that require high availability and leverages Always On availability group across two AZs in the same MZR.
* Dual MZR deployment pattern - This pattern extends the dual AZ pattern to make it suitable for production databases that require both HA and disaster recovery and leverages an Always On availability group across two MZRs.







 About SQL Server high availability and disaster recovery 

Microsoft SQL Server has a number of supported replication technologies to achieve high availability and disaster recovery including; Always On availability groups, log shipping, database mirroring, and Always On Failover Cluster Instances. The SQL on VPC deployment patterns leverage Always On availability groups:



* Always On availability groups - SQL Server Always On availability groups can provide both high availability and disaster recovery for SQL Server databases. Conceptually, it consists of a single set of primary read/write databases and multiple (from one to eight) sets of related, secondary databases. The secondary databases can be made available as read-only copies of the primary databases for read workloads, including database backup. Always On availability groups are leveraged in the Dual AZ and the Dual MZR deployment patterns. SQL Server Always On availability groups support both synchronous and asynchronous commit modes:



* Synchronous - The primary replica commits database transactions after the changes are committed, or written to the log of the secondary replica. Using this mode, you can perform planned manual failover and automatic failover if the replicas synchronized. This mode is best suited for instances in the same AZ or MZR.
Disaster Recovery 

In the event of a DR issue with the TRIRIGA Application Suite Managed Service offering for a specific customer, IBM's focus will be in the following order:

Recover the existing infrastructure in place. Recover within the same IBM Cloud data center to a new infrastructure. Recover to a secondary IBM Cloud data center.

In the event a disaster is declared, the base parameters are:

Recovery Time Objective (RTO)  - 72 hours

Recovery Point Objective (RPO) - 24 hours

RTO is the longest possible time needed to make the application available. RPO is the longest possible time since data was last backed up.

These are Service Level Objectives (SLO's) and not Service Level Agreements.

For information on IBM business continuity, please refer to IBM's Business Continuity Management Position Paper:

[https://www.ibm.com/downloads/cas/81M5VGP7](https://www.ibm.com/downloads/cas/81M5VGP7)
Only once it has been determined that the original infrastructure cannot be recovered in an acceptable timeframe will the Cold DR process be activated.

Once the decision has been made to trigger the Cold DR process IBM will launch new infrastructure in a different data center to host the paid queue managers, and use the configuration backup for each paid queue manager to recreate a copy of the queue manager deployed in the new infrastructure. Finally the DNS hostname that is used by applications to access the queue manager is updated to point to the new infrastructure deployment.





 RTO and RPO (recovery time objective and recovery point objective) 



* RTO is 24 hours
* RPO is 24 hours



![IBM MQ on Cloud disaster recovery](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_ha_dr.png)



Table 1. IBM MQ on Cloud processing and backup locations

 Queue manager region Processing availability zone Alternate availability zone Backup multi-az region 

 us-south dal12 dal13 us-south 
 us-east wdc04 wdc06 us-east 
 eu-de fra02 fra05 eu-de 
 eu-gb lon04 lon02 eu-gb 
 AWS us-east-1 us-east-1d us-east-1b us-east 
 AWS eu-west-1 eu-west-1c eu-west-1b eu-west 







 Customer Responsibilities 

Since the cold restore of the queue manager does not retain runtime state such as channel sequence state there may be some administrative action that you will need to take to re-integrate the restored queue manager with your other infrastructure, for example by resetting channel sequence numbers so that channels will successfully communicate.
You can implement disaster recovery mechanisms between two IBM i virtual server instances by using PowerHA geographic mirroring. For a complete tutorial, see [IBM i Disaster Recovery with IBM Power Systems Virtual Servers](https://cloud.ibm.com/media/docs/downloads/power-iaas-tutorials/PowerVS_IBMi_DR_Tutorial_v1.pdf).





 Business Continuity through backup and restore 

Your Power Systems Virtual Server configuration and data are not backed up automatically. You can back up your virtual server to [Cloud Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage) as explained in [Backup strategies for Power Systems Virtual Server](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-backup-strategies). You can also restore your virtual server in case a critical failure occurs.

Importing and exporting images requires a considerable amount of processing power and network bandwidth. As a result, you can submit only one import or export request before it is queued. Typically, users import or export system disks (AIX rootvg disks) that are smaller in size (less than 1 TB) to facilitate the transfer to and from Cloud Object Storage. If your image size is greater than 1 TB, your transfer might take a long time and is prone to failure. The maximum image size that you can import or export is 10 TB.
For example, choose how to set up your [cluster network](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters), [protect sensitive information](https://cloud.ibm.com/docs/containers?topic=containers-encryption) such as with IBM Key Protect encryption, and configure further [security settings](https://cloud.ibm.com/docs/containers?topic=containers-securitysecurity) to meet your workload's security and compliance needs. If applicable, configure your [firewall](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall).<br><br><br> 
 Worker nodes <br><br> * Monitor and report the health of the master and worker nodes in the various interfaces.<br> * Automatically apply master security patch updates, and provide worker node security patch updates.<br> * Enable certain security settings, such as encrypted disks on worker nodes<br> * Disable certain insecure actions for worker nodes, such as not permitting users to SSH into the host.<br> * Encrypt communication between the master and worker nodes with TLS.<br> * Provide CIS-compliant Linux images for worker node operating systems.<br> * Continuously monitor master and worker node images to detect vulnerability and security compliance issues.<br> * Provision worker nodes with two local SSD, AES 256-bit encrypted data partitions.<br><br><br> As part of your incident and operations management responsibilities for the worker nodes, apply the provided security patch updates. 







 Disaster recovery 

IBM is responsible for the recovery of IBM Cloud Kubernetes Service components in case of disaster. You are responsible for the recovery of the workloads that run the cluster and your application data. If you integrate with other IBM Cloud services such as file, block, object, cloud database, logging, or audit event services, consult those services' disaster recovery information.



Table 6. Responsibilities for disaster recovery

 Resource IBM responsibilities Your responsibilities
For example, choose how to set up your [cluster network](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_clusters), [protect sensitive information](https://cloud.ibm.com/docs/openshift?topic=openshift-encryption) such as with IBM Key Protect encryption, and configure further [security settings](https://cloud.ibm.com/docs/openshift?topic=openshift-securitysecurity) to meet your workload's security and compliance needs. If applicable, configure your [firewall](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall).<br><br><br> 
 Worker nodes <br><br> * Monitor and report the health of the master and worker nodes in the various interfaces.<br> * Automatically apply master security patch updates, and provide worker node security patch updates.<br> * Enable certain security settings, such as encrypted disks on worker nodes<br> * Disable certain insecure actions for worker nodes, such as not permitting users to SSH into the host.<br> * Encrypt communication between the master and worker nodes with TLS.<br> * Provide CIS-compliant Linux images for worker node operating systems.<br> * Continuously monitor master and worker node images to detect vulnerability and security compliance issues.<br> * Provision worker nodes with two local SSD, AES 256-bit encrypted data partitions.<br><br><br> As part of your incident and operations management responsibilities for the worker nodes, apply the provided security patch updates. 







 Disaster recovery 

IBM is responsible for the recovery of Red Hat OpenShift on IBM Cloud components in case of disaster. You are responsible for the recovery of the workloads that run the cluster and your application data. If you integrate with other IBM Cloud services such as file, block, object, cloud database, logging, or audit event services, consult those services' disaster recovery information.



Table 6. Responsibilities for disaster recovery

 Resource IBM responsibilities Your responsibilities
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. Create IBM Cloudant accounts in two or more regions.
2. Create databases in each region as needed.
3. For databases that must be stored with cross-region redundancy, set up bidirectional continuous replications between the corresponding databases in each account.
4. Design and implement your applications so that data requests are routed depending on whether your environment is an Active-Passive or Active-Active configuration. For more information about setting up cross-region redundancy, see [Configuring IBM Cloudant for cross-region disaster recovery](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-configuring-ibm-cloudant-for-cross-region-disaster-recoveryconfiguring-ibm-cloudant-for-cross-region-disaster-recovery).



When you design your applications to work with data across multiple regions, consider the following points:



* Applications can send requests to the database hosted nearest to their physical location. This use of proximity can reduce network latency and improve response times. This configuration is referred to as an "Active-Active" method. An actve-active method is characterized by the concurrent use of multiple copies of data. 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.
Third-party vendors and tools 

Customers can use third-party tools to perform data migration. The following third-party tools are commonly used for data migration:



* [Falconstor StorSafe VTL](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migration-strategies-powerfalconstor-storsafe-vtl)
* iCluster
* MIMIX from Syncsort
* Double-Take® MoveTM for AIX
* Maxava HA





 FalconStor StorSafe VTL 

StorSafe VTL is an IBM-certified solution for migration, backup optimization, archive and data recovery (DR).

StorSafe VTL is software that emulates physical tape drives and libraries to optimize backup and recovery both on-premises and in the cloud, as well as enable simple and easy migration from on-premises to IBM® Power® Systems Virtual Server. StorSafe VTL can backup IBM i or AIX workloads on-premises, replicate to a cloud-resident StorSafe VTL, and then restore to a Power Systems Virtual Server. Legacy tapes can be handled similarly. Here are some of the features of StorSafe VTL:



* Non-disruptive and secure process that can scale to PB-sized workloads.
* Deduplication & replication improves performance and reduces storage capacity.
* The same tool for on-premise and cloud that enables both workload and tape migrations.
* System and application data is deduplicated and compressed before transmitting over the network, thereby accelerating migration, even on the initial baseline transfer.
* Replicated tapes land in Cloud Object Storage (COS) and can be used by the cloud VTL as a backup baseline without copying the data.
* Migration leverages existing backup processes and tools leveraging existing environment and knowledge.
* Data replication can occur over time as part of the backups with final sync replication completed fast during regular backup windows.
* FalconStor StorSafe VTL for Power Systems Virtual Server can take advantage of IBM low-cost COS storage for its repository.





 Migrating an IBM i system
Database restore can only be done to one of the previous daily backups (cannot restore to point in time).





 Disaster Recovery 

In the event of a DR issue with the Maximo Application Suite SaaS offering for a specific customer, IBM's focus will be in the following order:



1. Recover the existing infrastructure in place
2. Recover within the same AWS data center to a new infrastructure
3. Recover to a secondary AWS data center



In the event a disaster is declared, the base parameters are:

Recovery Time Objective (RTO) - 72 hours Recovery Point Objective (RPO) - 24 hours

RTO is the longest possible time needed to make the application available. RPO is the longest possible time since data was last backed up.

These are Service Level Objectives (SLO's) and not Service Level Agreements.

For information on IBM business continuity, please refer to IBM's Business Continuity Management Position Paper:

[https://www.ibm.com/downloads/cas/81M5VGP7](https://www.ibm.com/downloads/cas/81M5VGP7)
: The following upgrades are applied to newly deployed instances, clusters, and hosts.



* VMware vCenter Server Appliance 7.0 Update 3k (build 21290409)
* VMware vSAN Witness 7.0 Update 3c (build 19193900)



Veeam 12 availability
: Veeam® Backup and Replication 12 (Veeam 12) is now available for deployment with VMware vCenter Server, Cyber Recovery, and VMware Regulated Workloads offerings. Veeam 12 allows you to write directly to IBM Cloud® Object Storage and it provides other features, such as data protection, improved Recovery Point Objective using Continuous Data Protection for disaster recovery purposes, and general operational efficiency. For more information, see the [Veeam Backup and Replication 12 release notes](https://www.veeam.com/veeam_backup_12_release_notes_rn.pdf).

New and updated documentation
: The table of contents is updated for topic rearrangement and removal of outdated content.

User interface updates and enhancements
: The user interface is updated with various messages and tooltips, and provides the following enhancements.



* The term edge gateway cluster is updated to gateway cluster throughout the UI, user documentation, and REST APIs.
* You can check the prices for VMware Solutions offerings without having to sign in to IBM Cloud. However, you might have limited access to some sections of the ordering pages. To place an order, or for a complete access to the ordering pages, you must log in to IBM Cloud.
* The page titles and labels for adding clusters, storage, and services are updated for consistency throughout the user interface.
* The status of instances and clusters when they are ready to use is updated to Available.
* The UI controls for the separate workload cluster, gateway cluster, and file shares are changed to switches instead of checkboxes.
* Guidance is provided on the UI for the workload and gateway cluster configuration.
* A side panel is displayed when you add hosts to vCenter Server, Cyber Recovery, and VMware Regulated Workloads instances.







 8 March 2023 

VMware Cloud Director upgrade for VMware Shared