vania-janet/multiturn-rag-retrieval-data huggingface dataset:
A single-use credential is used by the Veeam backup server to initially configure the Linux hardened repository. This credential is not stored by Veeam. During the initial configuration, certificate-based authentication is established between the Veeam backup server and the Veeam Transport Service.

After the initial configuration, Secure Shell (SSH) access is not required for Veeam operations. However, it is required for server updates and other maintenance tasks, unless all console access is done through the server IPMI port.

During initial configuration, when the "Make recent backup immutable for x days" is set, all compatible new backups to this repository become immutable for at least the number of "x days". The immutable time can be longer. For example, earlier incremental backups in a backup chain are immutable for longer. This action ensures that entire backup chain has the same immutable time as incremental backup files depend on each other in a backup chain.

When no backups or restores run, only the TCP 6162 inbound port is opened on the Linux hardened repository to allow the Veeam Transport Service to communicate with other Veeam components.

ufw status
Status: active
To Action From
-- ------ ----
6162/tcp ALLOW 10.38.207.157 Allow Veeam Mgmt from Veeam BUR server
6162/tcp ALLOW OUT Anywhere Veeam transport rule

The Veeam Transport Service opens extra ports, such as TCP 2500 - 3300, temporarily. This action allows data to be received from the proxy servers during backup and restore processes.

ufw status
Status: active
To Action From
-- ------ ----
6162/tcp ALLOW 10.38.207.157 Allow Veeam Mgmt from Veeam BUR server
2500/tcp ALLOW Anywhere Veeam rule 876f0752-7209-4e8b-8b34-fa0af7dbced4
* UI
* CLI
* API







 Point-in-time Recovery 

IBM Cloud® Databases for EnterpriseDB 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 of your PITR information under Point-in-Time.

Zoom

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

Figure 1. PITR section of the Backups tab

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>

To discover the earliest recovery point through the API, use the [/deployments/{id}/point_in_time_recovery_data](https://cloud.ibm.com/apidocs/cloud-databases-apiget-earliest-point-in-time-recovery-timestamp) endpoint to find the earliest PITR time.

{
"point_in_time_recovery_data": {
"earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
}
}



 Recovery 

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.
A backup CRN is in the format crn:v1:<...>:backup:<uuid>. If omitted, the database is provisioned empty.





* backup_location - The location of the deployment's backups.
* disk_encryption_key_crn - The CRN of a [KMS key](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-provisioning), which is then used for disk encryption. A KMS CRN is in the format crn:v1:<...>:key:<id>.
* backup_encryption_key_crn - The CRN of a [KMS key](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-provisioning), which is then used for backup encryption. A KMS CRN is in the format crn:v1:<...>:key:<id>. To use a key for your backups, you must first enable the [service-to-service delegation](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-provisioning).





* members_cpu_allocation_count - Enables and allocates the number of specified dedicated cores to your deployment. For example, to use two dedicated cores per member, use "members_cpu_allocation_count":"2". If omitted, the default value "Shared CPU" uses compute resources on shared hosts.
* service-endpoints - Selects the types [Service Endpoints](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-provisioning) supported on your deployment. Options are public, private, or public-and-private. If omitted, the default is public. Note that in the CLI, service-endpoints is a flag, and not a parameter.
Why doesn't my app ever become ready? 

 What’s happening 

After you deploy an app, the app does not achieve a ready status.

 Why it’s happening 

If your app is waiting and does not achieve a ready status, determine whether one of the following cases is true.



1. By default, Code Engine apps listen for incoming connections on port 8080. Your app might listen on a different port if you receive the following error message,

Internal error:
RevisionFailed: Revision "myapp-1" failed with message: Initial scale was never achieved
2. Your app is deployed from repository source code and the app displays a waiting status.
3. Your app is deployed from local source code and the app displays a waiting status.



 How to fix it 

Try using the following information to resolve your problem.



1. Code Engine requires that you have an HTTP endpoint that Code Engine uses to check the health of your app. If your app doesn't respond to the configured endpoint port, the app is never marked as ready. To remedy this case,



1. Code Engine sets the PORT environment variable to the port value that the application listens to receive HTTP requests. Use this environment variable to set the listening port. See [Automatically injected environment variables for apps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-inside-env-varsinside-env-vars-app).
2. If your app listens on a port other than port 8080, deploy your app from the console and specify the correct port. Or, use the [ibmcloud ce app create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create) command in the CLI and specify the port with the --port option. Note that the following ports are reserved by Code Engine: 8022, 8008, 8012, 9090, 9091, and 15090.



2. If your app is deployed from repository source code, check the status of the image build. The image build completes before the app is deployed.
Why isn't my API key working? 

  What’s happening 

My API key is not working.

  How to fix it 

If your SATELLITE_CONNECTOR_IAM_APIKEY environment variable is set to a local path that contains your API key, verify if the following requirements are met:



*  The file must contain only a single line with your API key. Comment lines and additional lines are not supported.
*  The value of the SATELLITE_CONNECTOR_IAM_KEY is the file path that is mounted inside your container.



A common mistake is specifying the local host path to the API key file. However, this needs to be set to the mounted file path inside the container, which is specified via the -v option on the docker run command. For example, suppose you have a file called /env-files/api-key that contains your API key on your local file system. The SATELLITE_CONNECTOR_API_KEY environment variable needs be set to the path that is mounted to the Docker container specified on the -v option to make this file available to the container. For example, if you are using the following docker run command:

docker run -d --env-file /agent/env-files/env.txt -v /agent/env-files:/agent-env-files icr.io/ibm/satellite-connector/satellite-connector-agent:v1.0.3

The local file system path /agent/env-files is mounted to the container path /agent-env-files. Therefore, the SATELLITE_CONNECTOR_IAM_APIKEY environment variable value must be set to /agent-env-files/api-key instead of /agent/env-files/api-key. For example, SATELLITE_CONNECTOR_IAM_APIKEY=/agent-env-files/api-key.
* [Configure Autoscaling](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-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. For more information, see [Managing Backups](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-dashboard-backups).





 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-redis?topic=cloud-databases-activity-tracker)
* [IBM® Log Analysis](https://cloud.ibm.com/docs/databases-for-redis?topic=cloud-databases-logging)
* [IBM Cloud® Monitoring](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-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 Redis deployments. If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-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-redis?topic=databases-for-redis-admin-password)
* [scale disk, memory, and CPU](https://cloud.ibm.com/docs/databases-for-mysql?topic=databases-for-mysql-resources-scaling)
* [configure Autoscaling](https://cloud.ibm.com/docs/databases-for-mysql?topic=databases-for-mysql-autoscaling)







 Backups 

The Backups tab is the UI for managing your deployment backups. All 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-mysql?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-mysql?topic=cloud-databases-activity-tracker)
* [IBM® Log Analysis](https://cloud.ibm.com/docs/databases-for-mysql?topic=cloud-databases-logging)
* [IBM Cloud® Monitoring](https://cloud.ibm.com/docs/databases-for-mysql?topic=databases-for-mysql-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 MySQL deployments. If you brought your own encryption key from [Key Protect](https://cloud.ibm.com/docs/databases-for-mysql?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.
If you're using CouchDB, which is mounted in a separate container in the peer pod, back up the persistent volume associated with CouchDB before the volume associated with the peer pod. This is because the peer checks on CouchDB after booting and if anything is missing from CouchDB, the peer can push transactions to it which CouchDB integrates into the database. However, any transactions in the state database cannot be pushed back to the peer.

As a rule, it is a good practice to schedule backups (also known as "snapshots") to happen at the same time across the network. For example, if all of the peers in the network are using CouchDB, schedule all of the CouchDB persistent volumes to be backed up at the same time, followed by all of the peer persistent volumes (again, at the same time), and then the ordering node persistent volumes (if multiple organizations are contributing ordering nodes, these snapshots must be coordinated with other organizations). For an example of a backup schedule a network might choose to adopt, check out [Scheduling snapshots](https://cloud.ibm.com/docs/blockchain?topic=blockchain-backup-restorebackup-restore-schedule-snapshot).

While it is a best practice to periodically back up your Certificate Authority, these backups do not have to be coordinated with the rest of the network. CAs with a local database have a single persistent volume. If you are using PostgreSQL, the CA has an additional persistent volume associated with it that must also be backed up. For information about how to take backups of a PostgreSQL database, check out [Managing Backups](https://cloud.ibm.com/docs/databases-for-postgresql?topic=cloud-databases-dashboard-backups) from the Databases for PostgreSQL documentation.

The following node-specific guidance is provided to help plan your disaster recovery strategy.



 Backup considerations for each node type 

Consult the following chart to help you plan your strategy for taking backups:

Certificate Authority (CA)

Peers

Ordering service



Table 1. Considerations for node backup and restore - CA

 Backup Restore
Keycloak is packaged as software, which means that you, as the developer, are responsible for maintaining functionality of the product after you download it. You're responsible for hosting, high-availability, compliance, backups, DDoS protection, load balancing, web firewalls, databases, and more.

App ID is a fully managed offering that is provided "as-a-service". This means that IBM takes care of the operation of the service, handles compliancy, availability in multiple zones, SLA, and more. App ID also has an integrated experience with the IBM Cloud Platform that includes native runtimes and services such as the Kubernetes Service, Cloud Functions, and Activity Tracker.
* Can I use the same client ID in more than one application?

While you technically _can_ use the same credentials in more than one application, it is highly recommended that you do not for several reasons. Foremost, because when you're sharing your ID across applications any type of attack or compromise then affects your entire environment rather than one application. For example, if you're using your ID across three applications and one of them becomes compromised, all three are then compromised. An attacker is able to impersonate any of your apps. The second reason is that when you're using the same client ID in multiple apps, there is no way to differentiate between applications. For example, you're unable to tell which app was used to generate a token.



Hyper Protect Crypto Services



* What's IBM Cloud Hyper Protect Crypto Services?

IBM Cloud Hyper Protect Crypto Services is a dedicated key management service and cloud Hardware Security Module (HSM) A physical appliance that provides on-demand encryption, key management, and key storage as a managed service. service that provides the following features:



* Keep Your Own Key (KYOK) with the FIPS 140-2 Level 4 certified HSM that ensures your full control of the entire key hierarchy where no IBM Cloud administrators have access to your keys.
* Single-tenant key management system to create, import, rotate, and manage keys with the standardized API.
[View of the backup initiation](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/images/backup_initiated_v2.png)

Figure 3. View of the backup initiation
4. After backup completion, a new backup entry in the list of backups appears as a Full (Manual) type. The new backup is in an available state.

Zoom

![View of completed backup](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/images/backup_completed_v2.png)

Figure 4. View of a completed backup









 Restore 

All paid plans make use of Cross-Regional IBM Cloud Object Storage (COS), by default, to keep backups offsite.

For information about point-in-time restores, see [Point-in-time restore](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-bnrpoint-in-time).



 End-of-backup restore 



 Enterprise and Standard plans 

The following is an example of the end-of-backup restore operation in the web console UI:



1. Click Administration in the left menu and select the Backups tab. Select a backup that you want to restore to end-of-backup and click Restore.

Zoom

![View of the highlighted selection of the end-of-backup restore option](https://cloud.ibm.com/docs-content/v1/content/2a59ee244ed61eb35ab50e45757b42d22f720132/Db2onCloud/images/eobrestore_selection_v2.png)

Figure 5. View of the selection of the end-of-backup restore option
2. Click Restore to initiate the restore.

Zoom
Why can't I create a standard key after I load another master key? 

You are not able to create a standard key through either the Hyper Protect Crypto Services user interface or the API after you load another master key to the service instance.

  What’s happening 

You see the following error message when you try to create a standard key:

> The service was not able to add key "<key_ID>". The HTTP status is 500.

  Why it’s happening 

You load another master key to your service instance after you create the root key. Because of this, the root key fails to wrap the standard key, and the standard key creation fails.

If you want to change the master key in a regular basis for security reasons, rotate the master key by following [the instructions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-rotate-master-key-cli-key-part).

  How to fix it 

Load the original master key that is used to wrap the root key to the service instance again by following [the instructions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsmload-master-keys).
[PKCS #11 standard](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html). PKCS #11 is a cryptographic standard for secure operations, generation, and storage of keys.

The ability to configure a node to use HSM is available only in paid clusters.



 What capability does HSM add to my blockchain node? 

When a CA, peer, or ordering node is configured to use an HSM, their private key is generated by and protected inside the HSM. Only the private keys of node identities are secured in the HSM. When a CA is configured to use HSM, the CA root private key is stored in the HSM. This is the key that is used to sign enrollment requests. After a peer or ordering node is configured to use HSM, the nodes are able to sign and endorse transactions without ever exposing their private key. It is important to understand though that when you register other node admin or client application identities with a CA by using the console, their private keys are not stored inside the HSM because they will need their private key to transact on the network.





 Considerations when using HSM 



* When you configure your HSM, you will create a partition and a PIN for the slot on the HSM.
* A single partition can be used to generate and store multiple keys.
* Multiple blockchain nodes can share an HSM configuration, however it is recommended that one HSM is configured per organization.
* An HSM is not configured for an ordering service. Rather it is configured at the ordering node level inside the ordering service. Consider the case when different organizations contribute ordering nodes to an ordering service, it is possible that some organizations may want to use an HSM for the private key for their ordering node, while other organizations may not have that requirement. But all of the ordering nodes can still function together in the ordering service nonetheless.
* The use of an HSM introduces an increase in transaction processing, therefore you can expect a performance hit when using an HSM to manage the private keys for your nodes.
8. Verify that the vSphere server is successfully added by clicking Managed Servers > VMware vSphere.







 Adding a Backup Repository to Veeam Backup & Replication 

Follow these steps to create a new backup repository to store restored backups on the AltaVault appliance. Note: A CIFS/SMB share is used for the example because the Veeam Backup & Replication backup server must be hosted on a machine that is running Windows. The share protocol that is used for restoring backups in the IBM Cloud AltaVault appliance must be identical to the share protocol that is used for those same backups in the on-premises AltaVault appliance, a CIFS/SMB share is used.



1. In the lower-left, click Backup Infrastructure > Backup Repositories.
2. From the ribbon menu, click Add Repository.
3. Give the repository a unique Name and give an appropriate Description. Click Next.
4. Select the share type that corresponds to the share type that is used in the on-premises AltaVault appliance. Example: if the share type that is used in the on-premises AltaVault appliance is CIFS/SMB, select Shared folder.
5. Specify the location where you want the backups of the CIFS/SMB share to be restored on the AltaVault appliance. The share has the same name as the share through which backups were processed on the on-premises AltaVault appliance. For example, if the share named cifs_test1 is used for backups in the on-premises AltaVault appliance, then specify the location of the cifs_test1 share on the IBM Cloud AltaVault appliance.



* Open a web browser and enter the IP address of the AltaVault appliance to determine the location.
* Go to Storage > CIFS and take note of the Share Path of the share. Note: This is NOT the same as the local path of the share. The share path format is \<AltaVault appliance hostname><share name>.
Why is my instance of Secrets Manager stuck on provisioning? 

You try to create an instance of IBM Cloud® Secrets Manager, but the provisioning doesn't complete.

  What’s happening 

When you try to create an instance of the service in the IBM Cloud console, you see the Provisioning... status in your resource list, but the status never transitions to an Active state.

  Why it’s happening 

Because an instance of the service is created that is dedicated only to you, provisioning might take a few minutes to complete. Or, there might be an error in the provisioning process.

  How to fix it 

To resolve the issue, try waiting 5 - 15 minutes and refreshing your web browser. If the problem persists, contact IBM Cloud support.