vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* The solution architecture supports only production data that is hosted in a VMware vSphere® environment. It does not support physical servers or other hypervisors.
* The Veeam service in the isolated recovery environment provides a cyber-recovery backup of the specified production virtual machines (VMs). It writes the backup data to the Linux hardened backup repository in the isolated recovery environment.
* Cyber-recovery backup proxies, managed by the Veeam service in the isolated recovery environment, are required to be hosted in the production site. These proxies can be Windows® or Linux based and virtual or physical.
* The solution architecture is independent of existing production backup environment and does not integrate to any production systems except for the production vCenter and vSphere hosts.
* For cyber-recovery tasks, the Veeam service enables the mounting of the cyber-recovery backup files from the Linux hardened repository in read-only mode into a sandbox. The sandbox is hosted on the vSphere Server instance.
* There can be many sandboxes, for example:



* One can be used daily to scan cyber-recovery backup files.
* One or more can be used as required for cyber-recovery tasks.



* The sandboxes are for forensic scanning, analytics, or for other cyber-recovery tasks, such as investigations. The sandboxes are not meant to run production workloads. For recovery, the customer VMs must be moved back to either the production environment or to other customer-specified environment by using Veeam recovery methods.
* All devices are reconfigured to use the ADDNS servers for DNS and NTP requests.
* Sizing of the isolated recovery environment depends on the maximum size of the backup footprint. Also, on the number of sandboxes that are needed, and the number of recovered VMs to be instantiated at any time.





 Production environment 

The production environment is the vSphere environment that hosts the production data. The production environment can be in IBM Cloud or elsewhere. This site hosts:



* Production data refers specifically to the VM images (VMDKs) of the VMs running in the production environment.
* Production backup infrastructure is existing backup applications and infrastructure that are used to protect the production data.
* Nondisruptively create point-in-time recovery points,
* Revert volumes to previous points-in-time.



You must purchase some amount of snapshot space for your volume first so you can take snapshots of it. The snapshot space can be added during the initial order or afterward through the Volume Details page. Scheduled and manual snapshots share the snapshot space, so make sure you order enough Snapshot space. For more information, see [Ordering Snapshots](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-orderingsnapshots).



 Snapshot best practices 

Snapshot design depends on the customer’s environment. The following design considerations can help you to plan and implement Snapshot copies:



* Up to 50 snapshots can be created through a schedule and up to 50 manually on each volume or LUN.
* Don't over snap. Make sure that your scheduled snapshot frequency meets your RTO and RPO needs and your application business requirements by scheduling hourly, daily, or weekly snapshots.
* Snapshot AutoDelete can be used to control the growth of storage consumption.

The AutoDelete threshold is fixed at 95 percent.



Snapshots are not replacements for actual off-site Disaster Recovery replication or long-retention backup.





 Security 

All snapshots and replicas of encrypted Block Storage for Classic are also encrypted by default. This feature can't be turned off on a volume basis. For more information about provider-managed encryption-at-rest, see [Securing your data](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-mng-data).





 How Snapshots affect the disk space 

Snapshot copies minimize disk consumption by preserving individual blocks rather than whole files. Snapshot copies use extra space only when files in the active file system are changed or deleted.

In the active file system, the changed blocks are rewritten to different locations on the disk or removed as active file blocks entirely. When files are changed or deleted, the original file blocks are preserved as part of one or more Snapshot copies.
* Specify the minute each hour that a snapshot is to be taken. The default is the current minute.
* Specify the number of hourly snapshots to be retained before the oldest is discarded.



* Daily



* Specify the hour and minute that a snapshot is to be taken. The default is the current hour and minute.
* Select the number of hourly snapshots to be retained before the oldest is discarded.



* Weekly



* Specify the day of the week, hour, and minute that a snapshot is to be taken. The default is the current day, hour, and minute.
* Select the number of weekly snapshots to be retained before the oldest is discarded.





3. Click Save. Then, you can create another schedule with a different frequency. If the total number of scheduled snapshots is over 50, you receive a warning message and you are not going to be able to save another snapshot.



The list of the snapshots is displayed as they're taken in the Snapshots section of the Block Storage for Classic Detail page.





 Adding a Snapshot schedule from the SLCLI 

You decide how often and when you want to create a point in time reference of your storage volume with Snapshot schedules. You can have a maximum of 50 snapshots per storage volume. Schedules are managed through the Storage > Block Storage for Classic tab of the [IBM Cloud® console](https://cloud.ibm.com/classic-gen1).

Before you can set up your initial schedule, you must first purchase snapshot space if you didn't purchase it during the initial provisioning of the storage volume. For more information, see [Ordering Snapshots](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-orderingsnapshots).

To create a snapshot schedule, use the following command.

 slcli block snapshot-enable --help
Usage: slcli block snapshot-enable [OPTIONS] VOLUME_ID

Enables snapshots for a given volume on the specified schedule

Options:
--schedule-type TEXT Snapshot schedule [INTERVAL|HOURLY|DAILY|WEEKLY]
[required]
volume_encryption_key_not_active 

Message: The volume encryption key specified in the request is not active.

Activate the exising key or provide a new key. If you cannot activate your own key, contact your system administrator or [customer support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 volume_encryption_key_not_authorized 

Message: You are not authorized to access the provided volume encryption key.

Provide another encryption key for which you have access, or contact your system administrator to obtain access to the current key.





 volume_encryption_key_not_implemented 

Message: The volume encryption key feature is not supported.

A volume could not be created using your encryption key. This version supports volumes with provider-managed encryption only. To use your own encryption key, use a version of Block Storage for VPC that supports customer-managed encryption. Contact [customer support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support) for more information.





 volume_id_invalid 

Message: The volume ID specified in the request parameter is not valid.

The volume ID you specified is not in the correct format. Verify that you correctly entered the volume ID and try again. If you're not sure of the volume ID, specify ibmcloud is volumes in the CLI or GET volumes in the API and search the list of volumes.





 volume_id_missing 

Message: The volume ID is missing in the request parameter.

You must provide the volume ID in the request parameter when getting a specific volume.





 volume_id_not_found 

Message: Volume not found. Volume ID <volume_id> does not exist, where <volume_id> is the provided volume ID.

The specified volume ID does not exist. Provide a valid volume ID.





 volume_iops_zero_or_negative 

Message: The volume IOPS should be greater than zero.

When creating a volume, the IOPS value specified in the request must be a positive number.
(https://cloud.ibm.com/docs-content/v1/content/e9cda99c64ea1ee68cf0eda257d6a1de69ddbc4e/citrix-daas/images/dedicated-deployment-std.png)

Figure 3. Dedicated Host standard deployment

With the shared dedicated option, the control plane is also provisioned to the dedicated hosts.

Zoom

![Dedicated Host shared deployment diagram.](https://cloud.ibm.com/docs-content/v1/content/e9cda99c64ea1ee68cf0eda257d6a1de69ddbc4e/citrix-daas/images/dedicated-deployment-shared.png)

Figure 4. Dedicated Host shared deployment





 Volume Worker 

Volume Worker distributes the work of the Citrix identity disk creation. The volume worker consists of 4 components:



* A Cloud Object Storage bucket, used to store the jobs, (data) identity disks, and the completion logs. Work is added to the Cloud Object Storage bucket in the form of JSON metadata.
* The volume worker manager, used to creating the job in the database and creating an appropriate number of worker VSIs to complete the jobs. The volume manager is an IBM Cloud Function Action.
* VSIs with the volume worker agent, used to claim work in the database, create, and write the volume, and then log the result into the Cloud Object Storage bucket.
* A Redis database.



This diagram shows the order of operations in volume worker:

Zoom

![Volume Worker flow.](https://cloud.ibm.com/docs-content/v1/content/e9cda99c64ea1ee68cf0eda257d6a1de69ddbc4e/citrix-daas/images/volume-worker.png)

Figure 5. Volume Worker flow

The operation order that is shown in the diagram is:



1. The cloud connector plug-in writes job metadata and identity disk data to the Cloud Object Storage bucket.
2.
You can change the default values for these settings by adding them to the install-override.yaml file and changing their default values when you deploy the service. Or you can edit these settings by editing the cron job after the service is deployed by using the oc edit cronjob $INSTANCE-store-cronjob command.



Cron job variables

 Variable Description Default value 

 store.backup.suspend If True, the cron job does not create any backup jobs. False 
 store.backup.schedule Specifies the time of day at which to run the backup jobs. Specify the schedule by using a cron expression. For example {minute} {hour} {day} {month} {day-of-week} where {day-of-week} is specified as 0=Sunday, 1=Monday, and so on. The default schedule is to run every day at 11 PM. 0 23 * * * 
 store.backup.history.jobs.success The number of successful jobs to keep. 30 
 store.backup.history.jobs.failed The number of failed jobs to keep in the job logs. 10 
 store.backup.history.files.weekly_backup_day A day of the week is designated as the weekly backup day. 0=Sunday, 1=Monday and so on. 0 
 store.backup.history.files.keep_weekly The number of backups to keep that were taken on weekly_backup_day. 4 
 store.backup.history.files.keep_daily The number of backups to keep that were taken on all the other days of the week 6 





 Accessing backed-up files from Portworx 

To access the backup files from Portworx, complete the following steps:



1. Get the name of the persistent volume that is used for the Postgres backup:

oc get pv |grep $INSTANCE-store

This command returns the name of the persistent volume claim where the store backup is located, such as pvc-d2b7aa93-3602-4617-acea-e05baba94de3. The name is referred to later in this procedure as the $pv_name.
2.
* UI
* CLI
* API







 Resizing a virtual server instance 

You can resize your virtual server instance and vertically scale to any supported profile size in minutes. You can increase or decrease the amount of vCPU and RAM available for greater flexibility in workload management to address resource requirement changes, optimize cost or workload performance.

Virtual servers are configured by using profiles, or a combination of instance attributes, such as the number of vCPUs, amount of RAM, network bandwidth, and more that define the size and capabilities of the virtual server instance. When you upgrade or downgrade an existing server, you choose another profile that has the pre-defined specifications that you need. You cannot customize the configuration of a virtual server. The virtual server profile that you select determines the valid cores, RAM, bandwidth, and disk sizes on the resized instance. For more information about profiles, see [Instance Profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles).

When you resize an instance, keep the following information in mind:



* You need to stop, update, and start the instance that you want to resize
* Data isn't deleted from the primary volume or the data volume
* RAM is wiped from the resized instance
* All network configurations are maintained, such as private IPs, floating IPs, vNICs, and security groups
* The instance name doesn't change
* The data center location doesn't change
* An instance with a profile that does not include instance storage cannot be resized to a profile that does include instance storage.
* You must select a secure execution enabled profile when you want to resize an IBM Cloud Hyper Protect Virtual Servers for IBM Cloud® Virtual Private Cloud instance. Selecting a profile that is not secure execution enabled will cause the provisioning to fail.



After the instance is resized, you are billed the hourly rate of the new instance profile.

You can track the instance resize in Activity Tracker and IBM® Log Analysis for troubleshooting and audit purposes.



 Resizing virtual servers on dedicated hosts 

Virtual servers that run on dedicated hosts can be resized only to profiles that are supported by the dedicated host that the instance is hosted on.
* UI
* CLI
* API







 Creating and managing duplicate volumes 

You can create a duplicate of an existing IBM Cloud® Block Storage for Classic. The duplicate volume inherits the capacity and performance options of the original volume by default. However, both attributes can be changed manually. The duplicate has a copy of the data up to the point-in-time of the snapshot that was used to create it. The duplicate volume can be dependent or independent from the original volume.

If you are a Dedicated account user of IBM Cloud® Kubernetes Service, see your options for duplicating a volume in the [IBM Cloud Kubernetes Service Documentation](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_backup_restore).

Because the duplicate is based on the data in a point-in-time snapshot, snapshot space is required on the original volume before you can create a duplicate. For more information about snapshots and how to order snapshot space, see the [Snapshot Documentation](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-snapshots).



 Types of duplicate volumes 



 Independent duplicate 

Independent duplicates can be created from both primary and replica volumes. The duplicate is created in the same data center as the original volume. If you create a duplicate from a replica volume, the duplicate volume is created in the same data center as the replica volume.



 Common uses for an independent duplicate volume 



* Golden Copy. Use a storage volume as golden copy that you can create multiple instances from for various uses.
* Data refreshes. Create a copy of your production data to mount to your nonproduction environment for testing.
* Development and Testing. Create up to four simultaneous duplicates of a volume at one time to create duplicate data for development and testing.









 Dependent duplicate 

Dependent duplicate volumes are created by using a snapshot from the primary volume. Replica volumes cannot be used to create or update dependent duplicates.



 Common uses for a dependent duplicate volume 



* Disaster Recovery Testing. Create a duplicate of your source volume and compare it to the replica.
* UI
* CLI
* API







 Creating and managing duplicate volumes 

You can create a duplicate of an existing IBM Cloud® File Storage for Classic. The duplicate volume inherits the capacity and performance options of the original volume by default. However, both attributes can be changed. The duplicate has a copy of the data up to the point-in-time of the snapshot that was used to create it. The duplicate volume can be dependent or independent from the original volume.

If you are a Dedicated account user of IBM Cloud® Kubernetes Service, see your options for duplicating a volume in the [IBM Cloud Kubernetes Service Documentation](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_backup_restore).

Because the duplicate is based on the data in a point-in-time snapshot, snapshot space is required on the original volume before you can create a duplicate. For more information about snapshots and how to order snapshot space, see the [Snapshot Documentation](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-snapshots).



 Types of duplicate volumes 



 Independent duplicate 

Independent duplicates can be created from both primary and replica volumes. The new duplicate is created in the same data center as the original volume. If you create a duplicate from a replica volume, the duplicate volume is created in the same data center as the replica.



 Common uses for an independent duplicate volume 



* Golden Copy. Use a storage volume as golden copy that you can create multiple instances from for various uses.
* Data refreshes. Create a copy of your production data to mount to your nonproduction environment for testing.
* Development and Testing. Create up to four simultaneous duplicates of a volume at one time to create duplicate data for development and testing.









 Dependent duplicate 

Dependent duplicate volumes are created by using a snapshot from the primary volume. Replica volumes cannot be used to create or update dependent duplicate volumes.



 Common uses for a dependent duplicate volume 



* Disaster Recovery Testing. Create a duplicate of your source volume and compare it to the replica.
As another example, if a particular service provider’s network selects a network route that is not optimal, data packets can be sent hundreds or thousands of miles away from their destination while getting to their destination! These kinds of delays and detours are the causes of higher network latency—and slower data transfers.

We express network latency in milliseconds (that’s 1,000 milliseconds per second). A few thousandths of a second might not mean much to us as we’re living our daily lives, but milliseconds often become a deciding factor in our web browsing or in our business transactions. For example, in the financial sector, milliseconds can mean billions of dollars of difference in gains or losses from trade transactions on a day-to-day basis.





 Common approaches that minimize network latency 

Given that our shared goal is to minimize latency, it makes sense to limit the number of potential variables that can affect the speed of the data’s movement. No provider can achieve complete control over how data travels across the internet, but there are some best practices to minimize network latency:



* Distribute data around the world: Customers in different locations can pull data from a location that’s geographically close to them. Because the data is closer to the customers, it is handed off fewer times. When data has a shorter distance to travel, routing is less likely to cause a significant performance impact.
* Provision servers with high-capacity network ports: Huge volumes of data can travel across a server every second. If packets are delayed due to fully saturated ports, milliseconds of time pass, pages load more slowly, download speeds drop, and users become unhappy.
* Understand how your providers route traffic: When you know more details about how your data is transferred to customers around the world, you can make better decisions about where you host your data.







 How IBM Cloud minimizes network latency 

To minimize latency, IBM Cloud took a unique approach to building our network. All of our data centers are connected to network points of presence (PoPs), and all of our network points of presence are connected to each other through our global backbone network.
How Snapshots affect the disk space 

Snapshot copies minimize disk consumption by preserving individual blocks rather than whole files. Snapshot copies use extra space only when files in the active file system are changed or deleted.

In the active file system, the changed blocks are rewritten to different locations on the disk or removed as active file blocks entirely. When files are changed or deleted, the original file blocks are preserved as part of one or more Snapshot copies. As a result, disk space that is used by the original blocks is still reserved to reflect the status of the active file system before the change. This space is reserved in addition to the disk space that is used by blocks in the modified active file system.



Table 1 shows how snapshots affect the space usage on the Storage.

 Disk space usage 

 ![The space that is used before a snapshot copy is taken.](https://cloud.ibm.com/docs-content/v1/content/14cf2f2f32b430cf4ed67ad14b3cecc010f91c45/BlockStorage//images/bfcircle1.svg) Before any Snapshot copy is created, disk space is used by the active file system only. 
 ![The space that is used when a snapshot copy is taken.](https://cloud.ibm.com/docs-content/v1/content/14cf2f2f32b430cf4ed67ad14b3cecc010f91c45/BlockStorage//images/bfcircle3.svg) After a Snapshot copy is created, the active file system and Snapshot copy point to the same disk blocks. The Snapshot copy doesn't use extra disk space. 
 ![The space that is used when something changes after a snapshot copy was taken.]
How Snapshots affect the disk space 

Snapshot copies minimize disk consumption by preserving individual blocks rather than whole files. Snapshot copies use extra space only when files in the active file system are changed or deleted.

In the active file system, the changed blocks are rewritten to different locations on the disk or removed as active file blocks entirely. When files are changed or deleted, the original file blocks are preserved as part of one or more Snapshot copies. As a result, disk space that is used by the original blocks is still reserved to reflect the status of the active file system before the change. This space is reserved in addition to the disk space that is used by blocks in the modified active file system.



Table 1 shows how snapshots affect the space usage on the Storage.

 Disk space usage 

 ![The space that is used before a snapshot copy is taken.](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/FileStorage//images/bfcircle1.svg) Before any Snapshot copy is created, disk space is used by the active file system only. 
 ![The space that is used when a snapshot copy is taken.](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/FileStorage//images/bfcircle3.svg) After a Snapshot copy is created, the active file system and Snapshot copy point to the same disk blocks. The Snapshot copy doesn't use extra disk space. 
 ![The space that is used when something changes after a snapshot copy was taken.]