vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Install the Windows® IBM Cloud Backup for Classic Agent and plug-in on a server where a secondary replica is hosted. This backup strategy offloads backup processing to a nonprimary server. You can run a copy-only backup of the secondary database, followed by copy-only or transaction log backups. If the secondary replica becomes the primary replica after a failover, the IBM Cloud Backup for Classic Agent automatically runs full backups instead of copy-only backups. Transaction log backups remain the same.

If the availability mode of the secondary replica is asynchronous-commit, transaction logs on the secondary database might lag behind the primary replica database. If the secondary database is being backed up, data loss might occur.
* Install the Windows® IBM Cloud Backup for Classic Agent and plug-in on the primary replica server and on secondary replica servers. This strategy ensures that backups continue even if one of the replicas is down. You can run a full backup on the primary replica, followed by full or transaction log backups. You can also run copy-only backups on the secondary replicas, followed by copy-only or transaction log backups.



If an SQL database in an AlwaysOn Availability Group is hosted on an SQL Server Failover Cluster Instance, install the Agent, SQL Server plug-in, and Cluster plug-in on each physical node. Then, configure the jobs on the virtual node. Full backups run if the database is a primary database. Copy-only backups run if the database is a secondary database.





 Protecting SQL Server Clusters 

To protect an SQL Server cluster, you must install the Windows® IBM Cloud Backup for Classic Agent with the Cluster Support plug-in and SQL Server plug-in on each node in the cluster. Then, you can register a virtual server for the SQL Server role in the Portal and create and run backup jobs on the virtual server. Backup jobs on a virtual server are automatically directed to the active cluster node and do not reseed after a failover.

To fully protect an SQL Server cluster, you must back up:



* The quorum disk,
* Each physical node in the cluster,
* Cluster volumes,
* The SQL Server databases to provide point-in-time database recovery.
The --plan-delete-after option indicates the maximum number of days that the backups are to be kept and the --plan-delete-over-count option defines the maximum number of recent backups to keep. The -plan-clone-policy-zones option specifies that after the backup snapshot is created and stored in Object Storage regionally, a full copy of the backup is stored in the us-south-1 region of the availability zone. The --plan-clone-policy-max-snapshots option changes the number of cached backups that are stored in the AZ to 4. The default value is 5.

cloudshell:$ ibmcloud is backup-policy-create --match-tags dev:test --name my-backup-policy-v2 --plan-name my-plan-b --plan-attach-tags bkp:test --plan-copy-tags false --plan-delete-after 60 --plan-cron-spec '45 09 * * ' --plan-active --plan-clone-policy-max-snapshots 4 --plan-clone-policy-zones eu-de-1,eu-de-2 --plan-delete-over-count 2
Creating backup policy my-backup-policy-v2 under account Test Account as user test.user@ibm.com...

ID r138-5c719085-cf26-456e-9216-984866659e29
Name my-backup-policy-v2
CRN crn:v1:bluemix:public:is:eu-de:a/a10d63fa66daffc9b9b5286ce1533080::backup-policy:r138-5c719085-cf26-456e-9216-984866659e29
Status pending
Plans ID Name Resource type
r138-07200396-ba41-4d8b-a094-89ab5fadc879 my-plan-b backup_policy_plan

Backup tags dev:test
Backup resource type volume
Resource group defaults
ibmcloud cdb read-replica-resync 

Short version - rr-resync

Resyncs the read-only replica.

ibmcloud cdb read-replica-resync <deployment name or CRN> [--json] [--nowait]



 Command options 



* --json or -j Return the results as JSON.
* --nowait or -n Do not wait for command completion.







 Examples 

Resyncs a PostgreSQL read-only replica deployment named "MyPGSQL-replica".

ibmcloud cdb read-replica-resync MyPGSQL-replica









 Backups 

Manage the backups on your deployment or take an on-demand backup.



 ibmcloud cdb deployment-backups-list 

Short version - backups

Displays a list of backups that are associated with a deployment. The result is a table that is composed of the backups ID, type, status, and date of creation. The results are sorted with most recent backups first.

ibmcloud cdb deployment-backups-list <deployment name or CRN> [--scheduled] [--first] [--json]



 Command options 



* --scheduled or -s Output only scheduled backups.
* --first or -f Output only the first (or most recent) backup found.
* --json or -j Display results as JSON.







 Examples 

Display the backups available on a deployment named "Postgres2000"

ibmcloud cdb backups Postgres2000







 ibmcloud cdb backup-show 

Show details about a backup. The backup is identified by its CRN ID as shown with the deployment-backups-list command.

ibmcloud cdb backup-show <CRN> [--json]



 Command options 



* --json or -j Display results as JSON.







 Examples 

Show details of a particular backup.
During the apply plan process, the Spectrum Scale automation is integrated with trusted profiles, which is used for authorization purposes to provide permissions for the bootstrap node to create compute resources.

 How to fix it 

Contact your administrator to provide the required set of permissions on the trusted profile for the deployment to happen. For more support, you can raise a request with IBM support.





 Why does the health of the PERFMON show a failed state? 

 What’s happening 

After the cluster setup is done and you run the command mmhealth node show or mmhealth cluster show to validate the health of the node, the PERFMON node is in a failed state.

 Why it’s happening 

The PERFMON node makes use of one of the pmsensors for the setup, and the pmsensors service might not come up as expected.

 How to fix it 

Run the following commands to see the specific logs to fix the issue:



1. Run the following command to check the status of pmsensors:

systemctl status pmsensors

Sample Response

pmsensors.service - zimon sensor daemon
Loaded: loaded (/usr/lib/systemd/system/pmsensors.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Wed 2022-05-11 11:13:44 UTC; 2h 5min ago
Main PID: 19206 (code=exited, status=78)
May 11 11:13:44 anbu-scale-r4-compute-1 systemd[1]: pmsensors.service failed.
2. Run the following command to restart the pmsensors service:

systemctl restart pmsensors



The logs can be checked at cd /var/adm/ras and cat mmsysmonitor.log.





 Why does my cluster deployment fail in Schematics with a signal KILL error? 

 What’s happening 

While Schematics sets up the cluster, the deployment fails with an error similar to: Error: error executing "/tmp/terraform_516879781.sh": Process exited with status 137 from signal KILL
* UI
* CLI
* API







 Managing Cloud Databases backups 

Backups for Cloud Databases deployments are accessible from the Backups tab of your deployment's dashboard. Here is some additional general information about backups:



* One backup is taken every day.
* Backups are available for 30 days.
* Backups cannot be deleted.
* If you delete your deployment, its backups are deleted automatically.
* Daily backup scheduling is not configurable.
* Backups are restorable to other regions, except for eu-de and par-01, which can restore backups only between each other. For example, par-01 backups can be restored to eu-de, and vice versa.
* Backup storage is encrypted. To manage the encryption keys, see [Key Protect integration](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-key-protectbyok-for-backups). Otherwise, backups are encrypted with a key that is automatically generated for your deployment.
* Backups are restorable across accounts, but only through the API and only if the user that is running the restore has access to both the source and destination accounts.
* Cloud Databases backups are not downloadable. If you need a local backup, use the appropriate software. For example, [pg_dump](https://www.postgresql.org/docs/9.6/static/backup-dump.html) is an effective tool for managing PostgreSQL backups.
* IBM Cloud® Databases for DataStax does not support reenablement. After a deployment is disabled, that deployment must be restored from a backup.



For information on taking an on-demand backup, see [Taking an on-demand backup](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups&interface=cliondemand-backup).



 Backups in the UI 

The backup types have their respective tabs, either On-demand or Automatic. Each backup is listed with its type and when the backup was taken.
Overview 

IBM® Netezza® Performance Server for IBM Cloud Pak® for Data as a Service supports full, differential, and cumulative backups that can be performed on demand or according to a schedule. You can run differential and/or cumulative backups only after you run a full backup first. You can restore differential and/or cumulative backups only after you restore a full backup first.

You cannot backup (nzbackup) and restore (nzrestore) external data source objects.



 Scheduled backups 

A scheduled backup is a backup of the existing database that runs on a schedule.

You can configure your backup schedule based on the following factors.



* Frequency (in order of priority)



1. Monthly
2. Weekly
3. Daily



* Level (in order of priority)



1. Full
2. Differential
3. Cumulative





If there is a schedule overlap, you are notified about it. You also receive information about which schedule takes precedence and why. You cannot schedule backups for the same frequency to start at the same time if there is any intersection of databases between the backup schedules. If there is no preexisting full backup to reference, you cannot perform a differential or cumulative backup.





 On demand backups 

An on demand (ad hoc) backup is a backup of the existing databases that runs only once and on demand. You can create on demand backups before you do any alterations on your system.

On demand backups support different backup levels:



* Full
* Differential
* Cumulative







 Destination buckets 

To create backups, you must have a destination bucket setup created.

For Netezza Performance Server, you can choose between the following destinations.



* Amazon S3
* Azure Blob Storage
* IBM Cloud Object Storage





 Creating destination buckets 

You can create a destination bucket for Amazon S3, Azure Blob Storage, and IBM Cloud Object Storage by using the web console.



 For Amazon S3 



1. Log in to the web console.
2. Go to the Backup and restore > Destinations.
3. Select Amazon S3 as your destination bucket.
4.
Domains are added into different certificates in a well-proportioned manner, so we cannot guarantee that all of your domains are on the same certificate.





 Why do I see "wildcard" when I perform a dig or when I try to access content when my CDN is in Requesting Certificate, Domain Validation pending or Deploying Certificate status? 

During the DV SAN certificate requesting process, the DNS record chain for your CDN is chained to a wildcard certificate, temporarily. Until the process is complete, content temporarily is served through this wildcard certificate. Once the requesting process is complete, the DNS record chain is updated to chain to your CDN's DV SAN certificate.





 Is HTTP2 protocol supported for HTTPS requests? 

CDNs created with HTTPS protocol support HTTP2 for TLS secured traffic.





 Why is the newly created wildcard CDN status CNAME configuration required if we don't need to set the DNS record to point the domain to IBM CNAME? 

For the wildcard CDN, you don't need to set the DNS record to point the domain to IBM CNAME. As you create the CDN, the system creates a new DNS record to point the IBM CNAME (xxx.cdn.appdomain.cloud.) to Akamai endpoint (wildcard.appdomain.mdc.edgekey.net.), and it needs some time to finish the record propagation. The CDN status is shown as CNAME configuration required until the record is propagated. After the propagation is done, refresh the mapping status by clicking the Get status button. The CDN status then changes to Running.



Contribute in GitHub

Open doc issue

Edit topic





On this page[For my CDN, what is the difference between HTTPS with a Wildcard certificate and HTTPS with SAN certificate?](https://cloud.ibm.com/docs/CDN?topic=CDN-faq-for-httpsfor-my-cdn-what-is-the-difference-between-https-with-wildcard-certificate-and-https-with-san-certificate)[How is Domain Validation with redirect accomplished?]
Where is my job run? 

  What’s happening 

When I display my job runs, some of my job runs are deleted after a period of time.

  Why it’s happening 

If your job run is created by a subscription, then your job run is deleted after 10 minutes.

  How to fix it 

If you need an instance of your job run that was created by a subscription, trigger another event from your subscription event producer.

For example, if you are using an IBM Cloud Object Storage subscription, you can update your Object Storage bucket, considering the watched event types for your subscription. If you are using a Periodic timer (cron) subscription, you can either wait for the next scheduled event, or modify the schedule of the Periodic timer (cron) to meet your needs.

For more information about running jobs, see [Running jobs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan).
Why is back-end member health under my pool faulted? 

Use the information in this topic to troubleshoot a back-end member in your pool with a status of faulted.

  What’s happening 

The back-end member under your pool displays a status of faulted.

  Why it’s happening 

The faulted status suually results from a misconfigured back-end pool.

  How to fix it 

Verify the following configurations:



*  Does the port of the configured back-end protocol match the port that the application is listening on?
*  Does the configured health-check have the correct protocol (TCP or HTTP), port, and URL (for HTTP) information? For HTTP, make sure that your application responds with 200 OK for the configured health check URL.
*  Is the back-end server a virtual server with an enabled security group? If so, make sure that the security group rules allow traffic between the load balancer and the virtual server.



For more information, refer to [Health Checks](https://cloud.ibm.com/docs/vpc?topic=vpc-troubleshoot-lb-faultedhealth-checks).
If you plan to make major changes to your deployment, like scaling or removing databases, tables, collections, on-demand backups are useful. It can also be useful if you need to back up on a schedule. On-demand backups are kept for 30 days.

Deployments come with backup storage equal to their total disk space at no cost. If your backup storage usage is greater than total disk space, each gigabyte is charged at an overage of $0.03/month. Backups are compressed, so even if you use on-demand backups, most deployments do not exceed the allotted credit.

To create a manual backup in the UI, go to the Backups tab of your deployment then click Back up now. A message is displayed that a backup is in progress, and an on-demand backup is added to the list of available backups.

In the CLI, an on-demand backup is triggered with the [cdb deployment-backup-now](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referencedeployment-backup-now) command.

ibmcloud cdb deployment-backup-now example-deployment

In the API, sending a POST to the [/deployments/{id}/backups](https://cloud.ibm.com/apidocs/cloud-databases-apiinitiate-an-on-demand-backup) endpoint triggers an on-demand backup.





 Restoring a backup 

Backups are restored to a new deployment. After the new deployment finishes provisioning, your data in the backup file is restored into the new deployment.

By default, the new deployment is auto-sized to the same disk and memory allocation as the source deployment at the time of the backup from which you are restoring. To adjust the resources that are allocated to the new deployment, use the optional fields in the UI, CLI, or API to resize the new deployment. Be sure to allocate enough for your data and workload; if the deployment is not given enough resources, the restore fails.

Do not delete the source deployment while the backup is restoring.
* UI
* CLI
* API







 Point-in-time Recovery 

IBM Cloud® Databases for PostgreSQL offers Point-In-Time Recovery (PITR) for any time in the last 7 days. The deployment performs continuous incremental backups and can replay transactions to bring a new deployment that is restored from a backup to any point in that 7-day window you need.

The Backups tab of your deployment's UI keeps all your PITR information under Point-in-Time.

Zoom

![PITR section of the Backups tab](https://cloud.ibm.com/docs-content/v1/content/3505da55c475bf1edbe3eb3496324ba13941b783/databases-for-postgresql/images/pitr-backups-tab.png)

PITR section of the Backups tab

In PostgreSQL versions 13 and later, when restoring to a specific point within the last seven days, with a restore time after the last transaction, your restore fails with the message recovery ended before configured recovery target is reached. Before PostgreSQL v13, when restoring to a specific point within the last seven days, with a restore time after the last transaction, the latest restore point is used. If your restore fails for this reason, then Restore to last available point or choose an earlier date/time for Restore to a specific point in the last 7 days.

Included information is the earliest time for a PITR. To discover the earliest recovery point through the CLI, use the [cdb postgresql earliest-pitr-timestamp](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referencepostgresql-earliest-pitr-timestamp) command.

ibmcloud cdb postgresql earliest-pitr-timestamp <deployment name or CRN>
Why can't I display details of my configured service binding operations? 

When you configure project-wide settings with the Integrations page from the console, Code Engine automatically sets up the necessary credentials so that Code Engine can perform service binding operations for you. Sometimes, the service binding operations are configured, but details cannot be displayed about the settings.

 What’s happening 

After successfully configuring service binding operations, the status shows configured; however, you receive a warning message that details of the current service binding operations cannot be displayed. A warning that is similar to the following text appears on the Project settings > Integrations > Service binding operations page, Cannot display details of the current configuration.

 Why it’s happening 

When you create the first service binding in a specific Code Engine project, or you run the project update CLI command, Code Engine creates the operator secret (ibmcloud-operator-secret) for service binding operations for the project. The operator secret is a Code Engine generated and managed secret that includes the service ID and an autogenerated API key for it. Code Engine uses the service ID to perform binding operations on behalf of the user, instead of using the identity of the user that is logged in. The service ID creates credentials for a specific IBM Cloud service instance. After this operator secret is created, Code Engine uses this secret for the life of the project for service binding operations.

However, the operator secret might not contain the necessary information about the service ID so that details about the service binding configuration cannot be displayed from the Integrations page for project-wide settings.

The operator secret that was created because one of the following scenarios might not have the service ID information.



1. If the [project update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-project-update) CLI command was run with the --binding-service-id option.
2.
* [Scale disk, memory, and CPU](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-resources-scaling)
* [Configure Autoscaling](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-autoscaling)







 Backups 

The Backups tab is the UI for managing your deployments backups. All of the available backups are listed with their timestamps. Click a backup to grab its ID or to restore it into a new deployment. More information is on the [Managing Backups](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-dashboard-backups) page.





 Observability 

The Observability tab provides access to the IBM Cloud Monitoring, logging, and event tracking integrations available for your deployment.



* [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-activity-tracker)
* [IBM® Log Analysis](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-logging)
* [IBM Cloud® Monitoring](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-monitoring)







 Settings 

The Settings tab contains the UI for many of the tunable settings for your deployment. You can



* view encryption details. Encryption at rest is enabled for all Messages for RabbitMQ deployments. If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-key-protect), the panel provides a link to your Key Protect instance and the Encryption Key field has the name of the key.
* [Scale disk, memory, and CPU](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-resources-scaling)
* [Configure Autoscaling](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-autoscaling)







 Backups 

The Backups tab is the UI for managing your deployments backups. All of the available backups are listed with their timestamps. Click a backup to grab its ID or to restore it into a new deployment. More information is on the [Managing Backups](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-dashboard-backups) page.





 Observability 

The Observability tab provides access to the IBM Cloud Monitoring, logging, and event tracking integrations available for your deployment.



* [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-activity-tracker)
* [IBM® Log Analysis](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-logging)
* [IBM Cloud® Monitoring](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-monitoring)







 Settings 

The Settings tab contains the UI for many of the tunable settings for your deployment. You can



* view encryption details. Encryption at rest is enabled for all Databases for etcd deployments. If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-key-protect), the panel provides a link to your Key Protect instance and the Encryption Key field has the name of the key.
* [Change the admin password](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-admin-password)